Oracle DataGuard

Data Guard

Oracle’s Standby Database feature has been upgraded and renamed to Data Guard in 9i. Data Guard allows you to set up a standby database (locally or at a remote site) and keep it either completely or approximately “in sync” with the primary database by automatically shipping and applying redo logs to the standby database. This provides for quick disaster and/or off-site recovery should the primary database be lost or destroyed. Data Guard components are:

• Data Guard Manager – The new administrative Data Guard GUI (part of OEM)
• Data Guard Command Line Interface (CLI) – For issuing commands
• Data Guard Monitor (DMON) – A monitor process that supports the Data Guard administration

Update the standby database by one of four Data Guard modes:

• Guaranteed – Keeps primary and standby totally in sync at all times. Primary transactions are not committed until verification that the change has been applied to the standby
• Instant – Ensures changes are shipped to the standby but does not require they immediately be applied and confirmed
• Rapid – Log Writer (LGWR) on the primary sends changes to the standby as soon as it can
• Delayed – the Archiver Process (ARCH) process on the primary send changes to the standby. You can specify a time lag prior to propagation (this can help avoid propagating errors)

Guaranteed mode is the most conservative and keeps the standby totally synchronized with the primary, but impacts primary performance the most. The other modes are progressively “looser” in the coupling between the primary and standby but cause less performance impact on the primary. You configure the mode (and other Data Guard attributes) by the initialization parameters LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_DEST_STATE_n.

Role Management Service (RMS) helps you to perform database transitions (switching the roles of the primary and standby databases). A switchover is a planned transition whereby you purposefully make the primary the standby, and vice versa. Among the commands you use during a switchover are these key ones:

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

ALTER DATABASE MOUNT STANDBY DATABASE;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL PRIMARY;

A switchback is the reverse of the switchover operation. It puts the two databases back to their original roles as primary and standby.

A graceful failover is performed when the primary becomes unavailable but you have its redo logs to apply to the standby. Apply any and all possible logs to the standby:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

then issue:

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL PRIMARY;

A forced failover occurs when the primary fails and redo logs are not all available. Some redo may be lost as you activate the standby. Key commands here include:

ALTER DATABASE SET STANDBY DATABASE UNPROTECTED;

ALTER DATABASE ACTIVATE STANDBY DATABASE;

An archive log gap occurs whenever a primary database archives the online redo log, but it is not also archived to the standby database. 9i automatically recovers archive log gaps for you. Set this up by initialization parameters that assign service names to the primary and standby databases:

FAL_CLIENT = ‘standby_name’

FAL_SERVER = ‘primary_name’

9i includes a Managed Recovery Process (MRP), a process that automatically applies archived redo logs on the standby database server to the standby database. Put a standby database into MRP mode by running:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;