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

I would like to thank everybody who replied. Also, I got some comments below.

drak0nian_at_yahoo.com (Paul Drake) wrote in message news:<1ac7c7b3.0301272351.55ef6678_at_posting.google.com>...
> konstantin_kudin_at_yahoo.com (Konstantin Kudin) wrote in message news:<ff88eb34.0301271300.4e1a873d_at_posting.google.com>...
>
> 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.

 Thanks a lot for the suggestion with replace.exe! It is actually available
for NT and I made it do periodic checks on the standby and copy the missing files from primary. That is reasonably good for me. It seems like 8.1.7 is desupported only around 2007, and NT's life got extended, so I guess this will do for now ... NT seems to have most of the things that 2000 has, although not as convenient.
In any event, doing the actual work is easy, it's the learning part that is difficult. Playing with DataGuard would be nice but 8i for Windows does not have it.  

 <snipped>

> 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.

 These are extremely good points. If it was within my powers I would definitely do what you suggest. As is, however, I'll just have to get the standby working and test the switch over a couple of times ...

 Thanks again!

 Regards,
 Konstantin Kudin Received on Tue Jan 28 2003 - 17:25:30 CST