Re: poor man's standby

Basically you made a clone of your production database, mounted it, and left it in recovery mode. Every time the prod database archived a log, you copied it to the standby database and applied the log, just as if you were recovering your production database. It never came out of recovery mode unless you needed to activate it. It's really not all that much different than a standby database in 8i or 9i except you had to script everything yourself. One difference I remember though was not having the log_file_name_convert and db_file_name_convert parameters. You had to ensure that the directory structure was the same on both servers.

--
Chuck

LeKaido <kaidol_at_bluff.ee> wrote in news:3ee6f7ff$1_1_at_news.estpak.ee:

> 
> I cant help wondering how you managed to keep copies of your online
> redo logs and control files up to date on the other machine.
> 
> Correct me if I'm wrong but to perform a full media recovery you'd
> need all of the following 1) control files 2) online redo logs 3) 
> archived redo logs (if any have been archived between the last startup
> and the crash)
> 
> K.L.
> 
> Chuck wrote:
>> LeKaido <kaidol_at_bluff.ee> wrote in news:3ee47fd3$1_1_at_news.estpak.ee:
>> 
>> 


>>>Hello,

>>>

>>>Is there a way to make something similar to DataGuard ( Standby )

>>>work on two installations of Oracle Standard ?

>>>

>>>What I need is one database being the "main" server and the second

>>>one as up-to-date as possible ( through applying archived redos for 

>>>example ) and recoverable and able to function as the main database

>>>in minutes.

>>>

>>>The closest thing I've gotten to work this far is:

>>>

>>>( Linux RedHat AS 2.1 , Oracle Standard v. 9.2.0.1 )

>>>

>>>Database D1 operates on machine M1. The logs and control files are 

>>>multiplexed over nfs mount to M2. D2 is a copy of D1.

>>>D1 is stopped. D2 'startup mount' -ed and 'recover'-ed ( with all the

>>>ctl-s and logs in their proper places ).

>>>

>>>This works fine, but what I'd need to do is to incrementally apply

>>>the new archived redo logs (as they are generated by D1) to the

>>>previously already recovered database to minimize the recovery time

>>>when D2 would actually be needed as the main DB.

>>>

>>>I'd really appreciate your advice on this one.

>>>

>>>thank you,

>>>

>>>K.L.

>>>

>> 
>> 
>> I used to do something similar back in version 7. In my case I did
>> not use NFS to copy the files. I used FTP instead. I periodically ran
>> a job (through cron) that would query D1's v$loghist view to see if
>> any new archived logs existed. If so it would FTP them to M2 and
>> apply them to D2 which was constantly in a state of recovery. I do
>> not have the scripts I used to do this any more as it was done over 5
>> years ago for a previous employer. The scripts should not be that
>> difficult to write is you are using unix. 
> 
>