A switchover is a planned role transition between the primary database and a standby database within the same Data Guard configuration. Switchover is used to reduce the downtime of production databases during any scheduled maintenance on the production server, to test the server capability or any changes at hardware level, or to check future role transitions. During switchover, there is no data loss and the role of each database changes from primary database to standby database and vice versa as shown in the following diagram:
Data Guard switchover is also a good way to move databases to new hardware. We can perform RMAN backup and restore the database to the new server, but the disadvantage of using RMAN is that we have to open the database with resetlogs. Another alternative would be shutting down the database and copying all files onto the new server. But this method will take a lot of time depending on the size of the database, and also it's not easy to perform this method in the ASM framework.
Then what is the alternate solution to move the database to another server without OPEN RESETLOGS or the option of COLD backup?
Data Guard is a good choice in this situation. The following steps can be performed to move a database to new servers using Data Guard:
- Implement Data Guard and create a standby database on the new hardware.
- Test the new hardware using the standby database read-only (Active Data Guard) or the standby database read-write (snapshot standby) option.
- Perform switchover in a planned maintenance window.
- Decommission the old primary server hardware.
We always initiate switchover from the primary database. As stated before, switchover can be performed using SQL*Plus, the Data Guard broker, or Enterprise Manager Cloud Control. Whenever we initiate switchover, redo generation will be stopped immediately and no other operations will be allowed to be performed and the current log sequence will be archived, which is also known as End of Redo (EOR). You can monitor the EOR status from v$archived_log. After switchover, we can see when and during which log sequence the switchover has been performed as seen in the following code:
SQL> select thread#,sequence#,END_OF_REDO,END_OF_REDO_TYPE from v$archived_log;
THREAD# SEQUENCE# END END_OF_RED
---------- ---------- --- ----------
1 337 NO
1 337 NO
1 338 YES SWITCHOVERIf it is an RAC database, redo will be archived from each of the active instances. Once again, the switchover process sends a flag to all of instances for the final redo to be generated by the log switch. If the Data Guard configuration has multiple standby databases, the primary database will be switched to one of the standby databases. In this case, the final online redo logs will be transferred from the primary database to all of the standby databases.
While the process of switchover is going on, restarting of primary and standby databases is expected behavior. Once switchover completes and it is properly configured, redo will automatically be transferred from the new primary database to the new standby database.
One last note about the change in switchover procedures of RAC databases in 11gR2:
- In versions before 11gR2, if the primary and standby were RAC databases, you had to shut down all of the primary instances except one and also shut down all of the standby instances except one. Once you perform switchover successfully, you can bring back the remaining cluster instances for both primary and standby databases.
- In the 11gR2 version, you still have to shut down all primary instances except one. However, it's not mandatory to close standby instances. We can perform switchover while all standby instances are in mount state.
Now we are going to perform switchover between the primary and standby databases. Performing the switchover operation is not a big deal if we have prepared the environment and verified our configuration. In order to do this, we must control the related initialization parameters on both the primary and standby databases and check the network bandwidth between primary and standby locations. If we are going to use the current standby as the future production database, we must check for the hardware resources of the server. The next exercise will show how we can prepare the Data Guard environment for a switchover.