Brief Information About the Oracle Data Guard

Hello Friends,

In this article, I will write about Oracle’s disaster recovery (disaster recovery) solution. I will give the basic terminology in a short brief information about the Data Guard .

First, let’s try to understand the word “Disaster”. We can see some of the disasters occurred in many parts of the world by television, radio, newspapers, etc. through the media . Some of them lived in the past such as Tsunami in Indonesia , hurricanes and hoses in America , close to the 1999 earthquake in Turkey. Such events is called as disaster. As a result of natural disasters, If we lose our data center, I’m sure it will be very high cost to us. Our data is very valuable for us to say that even the company’s treasury. Not only natural disasters, instantaneous power failure, disk failures and user errors can give rise to events such as losing our data.

As data managers, we are obligated to take necessary actions before these disasters occur. Also need to consider taking the necessary actions which are very important. These are;

RPO (Recovery Point Objective) – How much data can you afford to lose?

RTO (Recovery Time Objective) – Without data access what time can you stand?

According to the answers of these questions We must establish the backup system. Not satisfied with just setting up our system, and we must monitor our system.

Now, let’s learn Oracle’s beautiful solution “Oracle Data Guard”.

Oracle Data Guard is the disaster recovery solution. Protects our production database from disasters, reducing the work load on it and more effective use it. Technology, first introduced by setting the standby database manually with Oracle 7. Appeared as a Data Guard with Oracle 8i. If we examine a Data Guard features from past to present;

ORACLE 8i

Read-Only Standby Database

Managed recovery

Remote archiving redo log files

ORALCE 9i

“Zero Data Loss” Integration

Data Guard Broker and Data Guard Manager GUI

Swithcover and Failover operations

Automatical synchronous

Logical Standby Database

Maximum Protection

ORACLE 10g

Real-Time Apply

Forced support for Oracle RAC

Fast-Start Failover

Asynchronous redo transfer

Flashback Database

ORACLE 11g

Active Standby Database (Active Data Guard)

Snapshot Standby

Heterogeneous platform support (Production –Linux, Standby – Windows)

Characteristics and evolved over time as it stands today.

DATA GUARD 11g SYNCHRONOUS REDO TRANSFER PROCESS ARCHITECTURE (SYNC)-ZERO DATA LOSS

Process flow;

1 – The user initiates a transaction. This transaction is written to a redo buffer. When the user commit the transaction then the LGWR process writes it redo log file.

2 – LNS (logwriter Network Service) reports to RFS (Remote File Service) committed redo. RFS writes to standby redo log file. If we use physical standby, the MRP (Managed Recovery Process) will apply to standby database . In Logical Standby this is made by LSP (Logical Standby Process) .

3 – RFS sends information to LNS that data is processed successfully. LNS transmits this information to LGWR . Finally, commit information is send to the user that initiated the transaction (transaction) .

Data transfer is ensured by the synchronous redo transfer. But there is a disadvantage. If a network failure occurs between production database (Primary) and the standby database or Primary database can not access to the standby database then the primary database will hang until standby response. In other words, the primary database can not serve. To avoid such situation, I think the most logical one to use “NET_TIMEOUT” parameter. With this parameter you can determine the timeout period. In case of an outage, Primary waits until the timeout period and will continue to serve when timeout period expires. Default value of this parameter in 10g is 180s and in 11g is 30s.

DATA GUARD 11g ASYNCHRONOUS REDO TRANSFER PROCESS ARCHITECTURE (ASYNC)

Asynchronous reod transfer flow;

1 – The user initiates a transaction. This transaction is written to a redo buffer. When the user commit the transaction then the LGWR process writes it redo log file.

3 – Once Redo Buffer is recycled, LNS automatically reads redo log files and begins to send redo from log files.

RFS doesn’t send information to LNS that data is processed successfully.

The most common used process architecture. Asynchronous redo transfer does not guarantee zero data loss. The system has recovered with minimal data loss.

DATA GUARD PROTECTION MODES

There are 3 protection modes. Summarized in the table below.

Mode	The risk of data loss	Transfer method	Primary status
Maximum Protection	Zero data loss – two-sided protection	SYNC	primary waits for the receipt of information. if it doesn’t respond to primary, primary hangs
Maximum Availability	Zero data loss – single-sided protection	SYNC	primary waits for the receipt of information. if it doesn’t respond to primary, primary waits until the timeout parameter . (NET_TIMEOUT)
Maximum Performance	least data loss	ASYNC	primary never waits for the receipt of information

PHYSICAL STANDBY – REDO APPLY

Physical Standby Database is block by block copy of production database. It uses database recovery function to apply the changes. When redo apply is active, it can be opened for reporting and querying in read-only mode (a feature that comes with the Active Data Guard-11g). Also it can be used for backup operations. For opening in Read-Write mode, you must enable Flashback log . Onece Flashback log enabled you can open it in read-write mode after creating restore point. And again you can revert to standby. I have explained above, with one of the desired modes you can transfer redo. I’ll write the next article on Creating Standby Database with RMAN Active Database Duplication in 11gR2

In some cases, you may want to c reate a time lag between the time when redo data is received from the primary site and when it is applied to the standby database. If you enabled the delayed apply, then real-time apply will be disabled. Real-time apply can be activated as follows.

SQL>alter database recover managed standby database using current logfile disconnect;

If the real-time apply feature is enabled as shown above , log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins. As the remote file server (RFS) process writes the redo data to standby redo log files on the standby database, log apply services can recover redo from standby redo log files as they are being filled.

Delayed apply can be activated;

SQL> alter database recover managed standby database delay 10;

SNAPSHOT STANDBY(11g)

A snapshot standby database is a fully updatable standby database that is created by converting a physical standby database into a snapshot standby database. Snapshot standby is a feature that comes with 11g. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database. When it is converted back into a physical standby database, it discars all local updates. You can do test, patch, etc. by opening it in Read-write mode the test.

LOGICAL STANDBY – SQL APPLY

Logical Standby Databases are logically identical to primary databases although the physical organization and structure of the data can be different. Logical Standby Databases are updated using SQL statements. Logical standby database can be used for recovery and reporting simultaneously. Determine if the primary database contains tables and datatypes that were not supported by a logical stand by database. If the primary database contains tables that were unsupported, log apply services will exclude the tables applying to the logical stand by database. Run the following queries to see unsupported tables.

 select * from DBA_LOGSTDBY_UNSUPPORTED;

 select * from LOGSTDBY_UNSUPPORTED_TABLES;

ACTIVE DATA GUARD (11g)

Thanks to this feature that comes with 11g standby database can be open in read-only mode while redo apply (Read-Only with Apply). Therefore, the database is called the Active Standby. If we look at in terms of benefits to us of the Active Data Guard; We can make our real-time reporting (while continuing to apply redo),backup operations through the active standby database.Thus, we will reduce the processing load of production. Production database will serve our customers more effectively.

The other beauty that comes with 11g R2 is standby database count. Prior to 11g R2, you can use 9 standby database at the same time. With 11g R2 you can use 32 standby database at the same time.

SWITCHOVER & FAILOVER

Finally, I want to mention briefly the terms of switchover and failover.Switchover is the planned role change. It does not require re-installation of a new database. It can be used to test interoperability of standby database, OS and hardware maintenance. The failover is the deformation of the production (primary) database and activating standby database as the primary. It is not reversible. When enabled, re-create the standby database.

Pictures that I used from sources:

http://download.oracle.com/docs/cd/E11882_01/server.112/e17022/toc.htm

Oracle Data Guard 11g Handbook – Charles Kim

Talip Hakan Öztürk