Applying Archive Logs to a Secondary Server

[joeizbored]

Hello,

I have brought down the live Oracle 10.1.0.2 server, created an image using Acronis imaging software,then brought it back up to continue its work. I dropped the image on a secondary test server. Brought that up on its own separate network and its running great. However, how do I copy the archive logs from live and apply them to the test/disaster recovery/backup oracle server and catch it up?

Many thanks for your responses.

 

[SantaMufasa]

Joeiz,

Oracle calls the structure to which you refer, "Oracle Data Guard". You can read more about properly structuring your architecture at this Data Guard Overview and also Oracle's official words on the topic at Oracle9i Data Guard Concepts and Administration, which should still apply for Oracle 10g. (There is probably an official Oracle link to "Oracle 10g Data Guard" references, as well...I'll leave that detective work up to you.) If you Google for ["Oracle Data Guard" 10g], you'll receive about 41,900 hits.

In short answer to your original question, to create an "Oracle standby database" environment, the standby database is in continual "recovery" mode, in which it is constantly applying the redo log files from the original database. You set up a regularly running job that copies any recently completed, but-not-yet-applied redo log files from the original database environment over to the "Data Guard" (standby database) enviroment. The standby database then applies any newly arrived, but-not-yet-applied redo log files.

Let us know if any of these references give you the help for which you were looking.


Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]

 

[joeizbored]

SantaMufasa,

Thank you for the links and notes, but we are already using the Data Guard method. Our primary live Oracle server is called Alpha and the standy database server is Alpha2. This process is working great.

For disaster recovery purposes and training, I want to clone just Alpha for now and later on Alpha2. Right now, Alpha(Clone) is sitting in Phoenix, while Alpha(live) is in Houston. Alpha(Clone) every day is getting farther and farther behind on data since it's not doing anything. So using the archive logs from Alpha(live), I want to catch it up. This way, if Houston sinks into the sea, Alpha(Clone) will be the new live, but I still need to catch it up as much as possible using archive logs from tape or whatever.

Thanks for your help and tips.

 

[SantaMufasa]

we are already using the Data Guard method

...Then you are already familiar with the method of applying the logs from a source database to a standby/clone database, right? Can you not make "Alpha Phoenix (clone)" a standby/Data Guard database for "Alpha Houston (live)"?

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]

 

[joeizbored]

That would be the ideal method, but the disaster recovery plan we want to focus on is worst case scenario. If Alpha and Alpha2 are completely destroyed, I can bring up Alpha with the clone copy created last (lets say) May 31st and have a functional Oracle server.

But how do I catch it up to today or closer to today's date using archived logs created AFTER May 31st, which reside on tapes? This is all monetary transactional data, so I am sure people won't be happy seeing their balance for last May31st. They want to see it as real time as possible.

Once we figure this out, we can go live, then we can bring up the standby Alpha2 from its own cloned image, and its ready to apply the archive logs, received from the newly restored Alpha. The idea is to apply archive logs to catch up a cloned system just brought up.

We clone our servers at end of month, takes about 10 minutes longer than doing a cold backup so we do it anyway. This gives us the option of creating cloned database servers and testing other things. We have just never tested catching up a cloned server to current data using archived logs.

 

[SantaMufasa]

...the disaster recovery plan we want to focus on is worst case scenario. If Alpha and Alpha2 are completely destroyed, I can bring up Alpha with the clone copy created last (lets say) May 31st and have a functional Oracle server.

Okay, but if that scenario occurs, how have you been "protecting"/transferring the redo logs to your alternate site?


So, here is a scenario to try:

1) shutdown the clone instance
2) replace the clone instance's control files with the (up-to-the minute current) control files from the original instance.
3) make available to the clone instance the up-to-the-minute current redo log files from the original instance.
4) "startup mount"
5) recover database
6) "alter database open;"

This should bring the clone database from its May 31 state to the most recently committed transaction from the original instance.

Let us know your thoughts.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]

 

[joeizbored]

Didnt work.
After "alter database open" I got:

ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

So I did "alter database open resetlogs;" I got;

ORA-01190: control file or data file 1 is from before the last RESETLOGS

ORA-01110: data file 1 E:\oracle\ora10g\DBFPROD\system01.dbf

I shutdown the instance, copied over the system01.dbf and started over,

This time when I got to "recover database" i got:

ORA-01110: data file 2 E:\oracle\ora10g\DBFPROD\UNDOTBS01.dbf

 

[Beilstwh]

Did you follow Dave's instructions and replace ALL the control files on the clone machine with the control files from the active system before you did the recovery?

Bill
Oracle DBA/Developer
New York State, USA