Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Stanby under Windows - how to manage archive log files?

Re: Stanby under Windows - how to manage archive log files?

From: Paul Drake <drak0nian_at_yahoo.com>
Date: 27 Jan 2003 23:51:41 -0800
Message-ID: <1ac7c7b3.0301272351.55ef6678@posting.google.com>


konstantin_kudin_at_yahoo.com (Konstantin Kudin) wrote in message news:<ff88eb34.0301271300.4e1a873d_at_posting.google.com>...
> Hello,
>
> I am working on setting up a standby server. The OS is Windows NT
> SP6a and
> the Oracle is 8.1.7. I have no ability to change this combination.
>
> A question came up on how to ship files from primary to standby.
> While using
> an optional archive destination together with the Oracle 8i internal
> facility, some files do not get shipped to standby (this has been
> observed). For the mandatory setting an offline standby server will
> eventually stall the primary. Is there a way to ensure that primary
> operates regardless of what is happening to standby and that standby
> gets all the archive logs once it is back online?
>
> Also, what is the best scripting approach for managing the archive
> logs under Windows? I am interested in tasks such as removing some
> older logs and perhaps creating a delay in applying the logs to
> standby. Of course, such scripts could also ship log files from
> primary to standby without using the Oracle facility. Under Unices
> that would be trivial but what are the good tools for Windows? Is
> there any repository of DOS batch scripts that could do the job? I've
> tried to search the web on the issue and found no good answer.
>
> This is certainly a lot of questions in one e-mail. I would really
> appreciate an informative answer.
>
> Thanks in advance!
>
> Regards,
> Konstantin Kudin

you have already answered one of your questions:

> Of course, such scripts could also ship log files from
> primary to standby without using the Oracle facility. Under Unices
> that would be trivial but what are the good tools for Windows?

maybe some *nix tools such as Cygwin, Uwin or a third party Korn shell.
(whatever works for you as your favorite *nix shell)

> Is there a way to ensure that primary
> operates regardless of what is happening to standby and that standby
> gets all the archive logs once it is back online?

like syncing the directories with the replace.exe command? its available in w2K but not in NT4.
NT4 was due to go off of support this July. Microsoft extended support for that OS just late last week. NT4 sucks. Even your scripts that simply use xcopy.exe need to be fixed when (if) you upgrade to W2K. At least get them to upgrade to W2K before you start this project. And upgrade the oracle server software to at least 8.1.7.4.6. One more thing - check the de-support notice for Oracle Server 8i Release 3 on Metalink. this project will likely be repeated very early next year, when the database is moved to 9i.

> I am interested in tasks such as removing some
> older logs and perhaps creating a delay in applying the logs to
> standby.

one could force a log switch each time interval, and move files along from

accumulator (log_archive_dest)
loading dock (transfer area on primary)
receiving dock (transfer area on standby) holding_tank_1
holding_tank_n (increase retention_time by adding more tanks) showtime (log_archive_dest on standby)

So they want a standby database for what purpose? for quick failover? (business continuity) for recoverability from logical corruptions? remote disaster recovery?
their primary oracle server hardware, software or administration suck?

Have they taken basic steps w.r.t. increasing the availability and reliability of their production server, such as training staff, multiplexing redo logs, duplexing archived redo logs, testing backup/restore/recovery periodically?

do they keep backup sets on disk, including archived redo logs? are they using disaster recovery agents? are they using dbv.exe to check for corrupt blocks? do they monitor the alert log for errors? do they document their system configuration so that if Nimda comes thru and anihilates the OS, they will know how to reconfigure the server?

What business issue are you intending to solve with the standby database?
If there are multiple issues, you may need multiple standby databases, one that has logs applied immediately, and one configured with a lag in redo log application. In any event - you will want to get the logs off of the primary with minimal latency.

Here's an idea - examine what volume of redo they actually generate per day, and benchmark how long it takes to apply that redo on a suitable standby server.
Lets say that they generate 2 GB of redo an hour in production, and it takes 1 minute to apply 1 GB of redo. If you allow 16 GB of archived redo to accummulate, that would only be 16 minutes of recovery time, which _may_ be entirely acceptable in terms of a fail-over time. So you might just be able to dumb the entire project down to applying redo to the standby once a day, or more frequently if they require it.

For addressing logical corruptions, create dump files via export, compress them and move them offline. create hot backup sets compress them and move them offline. Have sufficient free space somewhere that you can open a hot backup set, open a db_link and compare them. You may find it easier to repair the damage in production than to run the full drill and fail over to the standby.

back in engineering school, one approach is to create a fault-tree analysis and perform a failure mode analysis. state all of the possible failure modes, assess probabilities to their individual occurrance, assess costs to their occurrance and then try to meet your objective.

what is your objective again?
to use a soon-to-be deprecated version of Oracle Server on a soon-to-be deprecated OS which lacks the tools for you to write the management scripts "that would be trivial" to write in *nix?

If the objective is no data loss, the standby is not your answer. If the objective is no downtime, the standby is not your answer. The standby database may be a part of your overall availability design, but I tend to think that if you're just planning this now on NT4 + 817, that the rest of the picture is mostly missing.

take some steps back and rethink this again.

Paul Received on Tue Jan 28 2003 - 01:51:41 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US