Go Back > Common DBA Misconceptions

User login

Frontpage Sponsor


How big is your Baan-DB (just Data AND Indexes)
0 - 200 GB
200 - 500 GB
500 - 800 GB
800 - 1200 GB
1200 - 1500 GB
1500 - 2000 GB
> 2000 GB
Total votes: 54

Baanboard at LinkedIn

Reference Content

Book Navigation

Redo & Rollback: After activating a standby rhe primary requires recopying to become the standby
By patvdv at 23 Feb 2008 - 23:29

When switching to a standby database, there are two basic scenarios. In one scenario, the switchover is undertaken in an emergency, and due to the unavailability of the primary host or the storage, the final one or two redologs are not available, and therefore cannot be applied to the standby. In such a case, the standby must be activated after incomplete recovery, without applying the last changes from the primary. This scenario is extremely rare.


The second, and much more likely scenario, is that the switchover is undertaken as a planned event, to perform maintenance on the primary host, or in an emergency event that does not preclude access to the most recent couple redologs. In such a scenario, complete recovery of the standby up to the point that the primary was stopped is both possible and advisable. By opening the standby without resetlogs as of that point in time, it is possible to immediately press the primary database into service as a standby without re-copying the database.


When you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby. People who use incremental checkpoints (FAST_START_MTTR_TARGET in 9i, FAST_START_IO_TARGET in 8i) must do a create controlfile reuse database noresetlogs at this point. Other people don't have to.


Finally, you recover database to get the last one or two online logs and open the standby noresetogs. The standby just picks up the chain of SCNs where the primary left off.


The old primary can be immediately pressed into service as a standby. Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database.


You can go back and forth in this way as many times as you want. One database just picks up the chain of SCNs where the last one left off. You never get a divergence of changes between the two.


It is worth noting that in 9i, they have an "automated" graceful failover mechanism for standby databases. I have not yet tested this feature to determine if it is any different from the method described here.


No votes yet

All times are GMT +2. The time now is 19:57.

©2001-2018 - -