Data Guard

(Source: Oracle 10gR2 Concept and Admin Guide)

 

Data Guard Protection Modes

Maximum Protection

  • No data loss
  • Redo has to be written to both Primary redo logs and standby redo logs (of atleast one standby database) before transaction commits
  • Primary database shuts down if redo stream is prevented to write at standby redo logs of atleast one standby database
  • Configure standby redo logs on at least one standby database
  • Attribute to use in log_archive_dest_n : LGWR, SYNC and AFFIRM for at least one standby DB

Maximum Availability

  • Redo has to be written to both Primary redo logs and standby redo logs (of atleast one standby database) before transaction commits
  • If redo stream is prevented to write at standby redo logs of at least one standby database then Primary database does not shuts down unlike Maximum protection mode, instead primary database operates in Maximum Performance mode.
  • Primary database automatically resumes to operate in maximum availability mode once all gaps are resolved.
  • Configure standby redo logs on at least one standby database
  • Attribute to use in log_archive_dest_n : LGWR, SYNC and AFFIRM for at least one standby DB

Maximum Performance

  • Default mode
  • Asynchronous redo data is written to at least one standby database
  • Attributes on log_archive_dest_n to set either LGWR and ASYNC  or  ARCH for standby DB destination

Minimum Requirements for Data Protection Modes (Ref:10g R2 DG concept & admin guide)

Maximum Protection Maximum Availability Maximum Performance
Redo Archival process LGWR LGWR LGWR or ARCH
Network Transmission Mode SYNC SYNC ASYNC when using LGWR process.SYNC when using ARCH process
Disk write option AFFIRM AFFIRM AFFIRM or NOAFFIRM
Standby Redo log required YES YES NO, but its recommended

REDO Apply

By default, the redo data is applied from archived redo log files.

When performing Redo Apply, a physical standby database can use the real-time apply feature to apply redo directly from the standby redo log files as they are being written by the RFS process without waiting for the current standby redo log file to be archived.

Note that log apply services cannot apply redo data to a physical standby database when it is opened in read-only mode.

For a no data loss environment, you should use a fully configured standby database using the LGWR, SYNC, and AFFIRM transport settings in a Data Guard configuration and running in either maximum protection mode or maximum availability mode.

AFFIRM and NOAFFIRM

When you specify the LGWR and AFFIRM attributes, the log writer process synchronously writes the redo data to disk, control is not returned to the user until the disk I/O completes, and online redo log files on the primary database might not be reusable until archiving is complete.

When you specify the ARCH and AFFIRM attributes, ARCn processes synchronously write the redo data to disk, the archival operation might take longer, and online redo log files on the primary database might not be reusable until archiving is complete.

The NOAFFIRM attribute specifies that all disk I/O to archived redo log files and standby redo log files is performed asynchronously; the log writer process on the primary database does not wait until the disk I/O completes before continuing.

The AFFIRM and NOAFFIRM attributes apply only to archived redo log files and standby redo log files on remote standby destinations and have no effect on disk I/O for the primary database’s online redo log files.

These attributes can be specified with either the LOCATION attribute for local destinations or with the SERVICE attribute for remote destinations.

VALID_FOR

VALID_FOR = (redo_log_type,database_role):

  • redo_log_type = online_logfiles OR standby_logfiles OR all_logfiles

This destination is valid only when archiving online redo logfiles OR standy logfiles OR either of them

  • database-role = primary_role OR standby_role OR all_roles

This destination is valid only when database is running in primary role OR standby role OR either of them

Eg: log_archive_dest_1=’LOCATION=/app/oracle/ORCL/arch/ MANDATORY

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

DB_UNIQUE_NAME=ORCL_PDB’

When this database is running in either PRIMARY or STANDBY role, destination 1 archives all log files to the /app/oracle/ORCL/arch/

REOPEN

REOPEN attribute of LOG_ARCHIVE_DEST_n parameter specifies minimum number of seconds must elapse following an error before ARCn or LGWR process will try again to access the failed destination.

Default value is 300 Seconds

How REDO data is SEND

REDO data is send either through ARCn process or LGWR process.

Using ARCn process

  • This is default and supports only maximum performance.
  • log_archive_max_processes init parameter specifies the max number of ARC process to be invoked when primary db is started. Default value is 4 and it is dynamic parameter can be adjusted with ALTER SYSTEM
  • On primary database, after ARC0 successfully archives online redo logfile to local destination, the ARC1 process transmits redo from local destination to the remote standby destination.
  • On standby database, RFS process will write redo data to archived redo logfiles.

Using LGWR SYNC

LGWR SYNC for log_archive_dest_n parameter specifies:

  • On primary database, LGWR submits redo data to one or more network server processes (LNSn), which then initiates the network IO in parallel to multiple destinations. Transaction will not commit on primary until necessary redo data is transmitted to all standby destinations.
  • On Standby site, RFS (remote file server) receives the redo data from the LGWR and writes redo to standby redo logfiles. In real time apply, redo data is applied to standby database directly from current standby redo logfiles as its been filled by RFS process.

Using LGWR ASYNC

LGWR ASYNC for log_archive_dest_n parameter specifies:

LGWR writes redo data to online redo logfiles, while LNSn (network server process) asynchronously transmits the redo data to all remote destinations. LGWR process continues to processing next request without waiting for LNS network IO to complete.

Data Guard Useful Links:

 

Switchover and Failover with TIME Delay

 

Cheers !!!

Raheel

One Response to Data Guard

  1. Raj B says:

    Hi Sir , I’m an new Oracle DBA aspirant…… your blog really aspiring me …. it is very useful n helpful for all … tq for maintaining this blog…….

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s