Select Page

Switchover or Failover: Dual Databases at Work

Glenna Coultas | | September 12, 2019

These days, no company can afford to lose even one second of processing time, so maintaining a robust primary database is essential. However, to ensure that corporate functions are always available, having a robust primary database also often means managing an equally robust standby database. To ensure the optimal functionality of both, every company should know how to move from one to the other either intentionally – a ‘switchover’ – or in the event of a crash or crisis – a ‘failover.’

Switchover:

Sometimes, it is imperative to switch your databases from your primary to your standby and from standby to primary. This ‘switchover’ appoints the formerly secondary database to the dominant database role, and relegates the previously primary base to the secondary role. After the switch, there’s no change in the data, however, which remains consistent between the two.

Switchback:

A switchback reverses the process, shifting the new dominant and the new secondary roles back to their original state.

Failover:

A ‘failover’ responds to a catastrophic failure event when all RAC primary databases fail, and the secondary database becomes the dominant database in that emergency. Failovers occur only when there is no chance of quickly recovering the primary base and the enterprise has no choice but to transition over to the standby as its primary database. Because they are triggered by a catastrophe, there may be data loss during the failover transition, depending on the set level of protection mode that is in effect in the standby base at that time.

Failovers can be ‘complete’ or ‘immediate’:

  • Complete failover: Most systems default to a complete failover, which is also the recommended practice. During a complete failover, the process will recover as much data as possible from the original primary database, dependant on any protection barriers that may be in place. The programming also tries to encompass any standby databases that are not affected by the failure, and engage them again as backup databases to the new dominant database. This document discusses the most common ‘complete’ type of failover.
  • Immediate failover: For speed, some organizations choose an immediate failover, which moves faster than a complete failover. In this case, however, after invoking the failover, there is no additional data applied to the standby database. It also requires that the original primary database be re-enabled, as well as any other unaffected database that you intend to use as standby databases to the new primary database. This document doesn’t discuss the more unusual ‘immediate’ type of failover.

Failback:

In the event of a catastrophic failover, which may render the original dominant database unrecoverable, the new standby database must be recreated. You can use the switchback method if this is not the case.

(PBS NOTE: I have included these per chart column)

Column 1

Transitioning Database Roles

(Switch- or Failovers)

Switching over to a physical secondary database

Switching over to a logical secondary database

Failing over (complete) to a physical secondary database

Failing over (complete) to a logical secondary database

Failing over immediately to either a new physical database or a logical secondary database

Column 2

Reinstatement or Recreation of a Failed Dominant Database

No action needed.

No action needed.

During the transition, the broker disables the dominant database. It can be reinstated only if there is a sufficient number of flashback logs on the failed database and you had enabled the “Flashback Database” before the failover event occurred. Without these two circumstances, your only other option is to use a backup copy of the dominant database to recreate it again.

During the transition, the broker disables the dominant database. It can be reinstated only if there is a sufficient number of flashback logs on the failed database and you had enabled the “Flashback Database” before the failover event occurred. Without these two circumstances, your only other option is to use a copy of the primary database to recreate it again.

The broker disables all secondary databases that were not affected by the failover. They can be recreated using copies of the new dominant database.

Column 3

Recovering the Secondary Databases That Were Not Affected by the Role Transition

No action needed.

All physical secondary databases are disabled, then recreated from a copy of the new dominant database. There’s no need to disable logical secondary databases.

Disabled physical standby databases are recoverable if, before the failover, the Flashback Database was enabled and there is a sufficient number of logs on that physical secondary database. Otherwise, you must use a copy of the new dominant database to recreate the physical secondary databases as well as any logical secondary databases that were disabled during the failover.

The primary database is disabled by the broker during the failover transition. A copy of the new primary database informs all other databases.

All standby databases not affected by the failover are disabled by the broker during the process. All subsequent secondary databases are created from a copy of the new primary database.

Today’s databases are complex but remain the backbone of most corporate activities. Maintain the health of your primary and standby databases by knowing how to switchover or failover so your enterprise never loses touch with its foundation.

Subscribe to Our Blog

Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.

12c Upgrade Bug with SQL Tuning Advisor

This blog post outlines steps to take on Oracle upgrade 11.2 to 12.1 if you’re having performance problems. Oracle offers a patch and work around to BUG 20540751.

Megan Elphingstone | March 22, 2017

Tips for Upgrading From SQL 2008 to 2012 or 2014

It’s 2015 and you can now establish totally respectable MS SQL DBA credibility just by mentioning you have been in the game since SQL Server version 9. You may even get the same gasps of shock from some colleagues that used to be reserved for the version 6 veterans.

Andy McDermid | April 8, 2015

Best RAID For SQL Server | RAID 0, RAID 1, RAID 5, RAID 10

Which RAID should you use with SQL Server? Learn the differences between RAID 0, RAID 1, RAID 5, and RAID 10, along with best practices.

Eric Russo | June 8, 2015

Work with Us

Let’s have a conversation about what you need to succeed and how we can help get you there.

CONTACT US

Work for Us

Where do you want to take your career? Explore exciting opportunities to join our team.

EXPLORE JOBS