Switchover And Failover

In today’s article we will talk about Switchover And Failover.

Databases in Data Guard Environment can be in Primary and Standby (Physical, Logical & Snapshot) roles. With Role Management Services we can dynamically switch between these roles.

We can change roles in two ways. One is Switchover and the other is Failover.

Switchover

1.There is a planned change. For example, we use it when we do an operating system or hardware maintenance on the servers in the Primary Database.

2.After Switchover, Primary Database Standby becomes Primary in Standby Database.

3.We call the relevant command from the Primary Database.

4.We do not need to re-create databases after switchover. The reason is that the online redo logs of the new primary database have not been reset.

5.After a successful switchover, there is no data difference between the original and new primary database.

6.Since the Primary Database is in read-write mode at the start of the switchover process, we need to close it and restart it, but we cannot close it during the Physical Standby Database Switchover.

7.If the Physical Standby Database is Active DataGuard, then we close it for the role change and open it after the role change. There is no need to turn off the Logical Standby Database. The reason is that it is already in read-write mode.

8.When we switchover the Primary Database’s Instances to Logical Standby, there is no shutdown. This provides support for Oracle to use this structure as a seamless Upgrade solution.

9.When we switchover to the Logical Standby Database, the Physical and Snapshot Standby Databases in the Data Guard Environment are disabled and become invalid.

Other Logical Standbys in the Environment become the Standbys of the New Primary Logical Standby Database.

10.Since Data Guard cannot automatically switch open sessions from Primary to Standby, open sessions will need to be reconnected to the new Primary Database.

Although this process can be done automatically with Client Connectivity, it is not generally used due to the fact that there will be a lot of processing at both the application and database level.

Switchover is not allowed in 3 cases.
1. If the archive Redo Log files cannot be accessed,
2.If you need Point-in-time recovery,
3.Primary database is not open or cannot be opened.

Failover

1. There is an unplanned change.

2. We should use it in cases where the recovery of the problem in the Primary Database will take a long time.

3. According to the Data Protection mode we choose, we will lose data. For example, while there is no data loss in Maximum Protection, there is data loss in Maximum Performance.

4. We can enable the Fast-Start Failover feature to automate the failover process. With this feature, when the broker detects a failover situation, it automatically performs the failover process without the need for manual intervention of the DBA.

5.Related commands are called from Standby Database.

6. During the failover process, we DISABLE the Primary Database Data Guard Environment.

7.Failover is a one-way operation, so we cannot return it to the previous role, Standby Database, as in Switchover.

Because the old Primary database is no longer usable. Either by reinstate or by re-creation, a new Standby Database becomes a database.

There are two types of Failovers.
Manual

Complete:It tries to minimize data loss by processing all available redos in the Standby Database. It is the default and recommended method.

Immediate:Does not apply any redo on Standby Database. Instantly makes the database available.

Fast-Start Failover

It is performed automatically by the Data Guard Broker.
Physical Standby Database, if available, is preferred before failover. Then the most up-to-date data is preferred.