Basics of Oracle 12c’s Data Guard

By Chris Ruel, Michael Wessler

Data Guard is Oracle 12c’s true disaster protection technology. In it, you have a minimum of two databases, primary and standby. Data Guard has options for multiple standby sites as well as an active-active configuration.

By active-active, it means both/all sites are up, running, and accessible. This is opposed to sites that have one active location and the others must be started up when they are needed. This is an example of the general architectural layout.

image0.jpg

Data Guard architecture and Oracle 12c

Start a description with the primary database is easy because it differs very little from any other database you might have. The only difference is what it does with its archived redo logs.

The primary database writes one set of archive redo logs to a Flash Recovery Area or a local disk. However, you may configure one or more other destinations in a Data Guard environment.

The LOG_ARCHIVE_DEST_n parameter may look like this for the previous configuration:

LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST'
LOG_ARCHIVE_DEST_1='SERVICE=PHYSDBY1 ARCH'
LOG_ARCHIVE_DEST_2='SERVICE=LOGSDBY1 LGWR'
  • LOG_ARCHIVE_DEST_10 is configured to send archive redo logs to the local Flash Recovery Area. One local destination is required for all archive log mode databases.

  • LOG_ARCHIVE_DEST_1 is configured to ship the archive logs via the archiver process to a remote site PHYSDBY1. The service name for this remote site has an entry in the tnsnames.ora file on the primary server.

  • LOG_ARCHIVE_DEST_2 is configured to ship the archive logs via the LGWR process to a remote site named LOGSDBY1. The service name for this remote site has an entry in the tnsnames.ora file on the primary server as well.

Why the difference in ARCn versus LGWR shipping methods? That has something to do with protection modes. A Data Guard environment has three protection modes.

Maximum availability

The maximum availability protection mode compromises between performance and data availability. It works by using the LGWR to simultaneously write to redo logs on both the primary and standby sites. The performance degradation comes in the form of processes having to wait for redo log entries to be written at multiple locations.

Sessions issuing commits have to wait until all necessary information has been recorded in at least one standby database redo log. If one session hangs due to its inability to write redo information, the rest of the database keeps moving forward.

Maximum protection

The maximum protection mode is similar to maximum availability except that if a session can’t verify that redo is written on the remote site, the primary database shuts down.

Configure at least two standby sites for maximum protection mode. That way, one standby site becoming unavailable won’t disrupt service to the entire application.

This mode verifies that no data loss will occur in the event of a disaster at the cost of performance.

Maximum performance

The maximum performance protection mode detaches the log shipping process from the primary database by passing it to the archive log process (ARCn). By doing this, all operations on the primary site can continue without waiting for redo entries to be written to redo logs or redo shipping.

This is opposed to log shipping modes that use the log writer to transfer transactions. Using the log writer can slow the processing of the transaction because it can be affected by the network availability or performance.

Maximum performance provides the highest level of performance on the primary site at the expense of data divergence. Data divergence occurs when the two sites’ data starts to get out of sync. Archive redo data isn’t shipped until an entire archive redo log is full. In a worst case scenario, an entire site loss could result in the loss of an entire archive redo log’s worth of data.

Performing switchover and failover operations

You can switch processing to your standby site two ways:

  • Switchover is a planned switch that can occur if you want to do maintenance on the primary site that requires it to be unavailable. This operation may require a few minutes of downtime in the application, but if you have to do maintenance that lasts for an hour or more, the downtime could be worthwhile.

    This operation is called a graceful switchover because it turns the primary site into your standby and your standby site into your primary. Also, you can easily switch back to the original primary site without having to re-create it from scratch.

  • Failover occurs when the primary site has been compromised in some way. Perhaps it was a total site loss, or maybe you discovered physical corruption in a data file. Not always, but usually after a failover, you have to either completely re-create the primary site or recover it from a backup and re-instate it.

    You usually perform a failover only when you’ve determined that fixing the primary site will take long enough that you prefer not to have an application outage for the entire time.

To perform a switchover, follow these steps:

  1. On the current primary, log in to SQL*Plus and type the following:

    <alter database commit to switchover to physical standby;>

    You should see this:

    Database altered.
  2. Shut down the primary database:

    <shutdown immediate>

    You should see this:

    Database closed.
    Database dismounted.
    ORACLE instance shut down.
  3. Start the primary database in nomount mode:

    <startup nomount>

    You should see something like this:

    ORACLE instance started.
    Total System Global Area 789172224 bytes
    Fixed Size         2148552 bytes
    Variable Size       578815800 bytes
    Database Buffers     201326592 bytes
    Redo Buffers        6881280 bytes
  4. Mount the database as a standby:

    <alter database mount standby database;>

    You should see this:

    Database altered.
  5. Start recovery:

    <recover managed standby database disconnect;>

    You see this:

    Media recovery complete.
  6. Log in to SQL*Plus on the current standby and type the following:

    <alter database commit to switchover to physical primary;>

    You should see this:

    Database altered.
  7. Shut down the standby database:

    <shutdown immediate>

    You should see this:

    Database closed.
    Database dismounted.
    ORACLE instance shut down.
  8. Make sure all appropriate initialization parameters are set for this database to behave properly as a primary.

  9. Start it normally:

    <startup>

    You should see something like this:

    ORACLE instance started.
    Total System Global Area 789172224 bytes
    Fixed Size         2148552 bytes
    Variable Size       578815800 bytes
    Database Buffers     201326592 bytes
    Redo Buffers        6881280 bytes
    Database mounted.
    Database opened.
  10. Make sure the users and applications can connect to and use the new primary instance.