Introduction to Data Guard

• Formerly called Standby Database
• Two versions
  • Physical standby
  • Logical standby (introduced in 9iR2)
• Both use redo logs to propagate changes to another database
• Physical standby applies redo directly
• Logical standby converts redo to SQL
• Significant enhancements for 10g R2

Physical Standby Concepts

• Begins as exact backup copy
• Mounted by new instance
• Receives and applies redo from primary efficiently
• Not available for user connections
• Can be opened in read-only mode if redo apply suspended

Physical Standby Configuration

Physical Standby: Continual Improvements

• Introduced in Oracle7 with few management tools
• Each release added improvements
• Now supports three protection modes
  • Maximum Protection
  • Maximum Availability
  • Maximum Performance
• Real-Time Apply added in Oracle10g

Physical Standby Modes...

• Maximum Protection mode
  • Log writer on primary transmits redo
  • Transaction does not commit unless redo is written to at least one standby
  • If such write not possible, primary will shut down to prevent generation of unprotected data
• Maximum Availability mode
  • As above, but no shutdown
  • Transitions to Maximum Performance mode if standby redo write is not completed

...Physical Standby Modes...

• Maximum Protection and Maximum Availability modes each require standby redo logs
  • Set up on standby DB like online redo logs
  • Redo information from primary written to these
  • Advantages
    • Can multiplex
    • Better performance because are pre-allocated, unlike copies of archived logs
    • Easier administration

...Physical Standby Modes

• Maximum Performance mode
  • Redo information transmitted asynchronously
  • Data can be lost
  • Redo can be transmitted by log writer or archiver
• Remote File Server
  • Runs on standby to receive and apply redo
• Network capacity must be adequate

Physical Standby – Transition and Requirements

• Role transition
  • Switchover: planned managed transition where primary and standby exchange roles
  • Failover: loss of primary; irreversible transition of standby to primary
• Platform requirements
  • Same OS and architecture
  • Identical Oracle Enterprise Edition releases

Introduction to Logical Standby...

• Based on LogMiner and Streams
• Logical standby database:
  • Need not be identical to primary
  • May contain different schemas and objects
  • May remain open for use while redo applied
  • Allows selective application of redo
  • Carries some restrictions as to data types and object types

...Introduction to Logical Standby

• Concepts
  • LogMiner reads redo logs, constructs SQL
  • Apply process executes SQL on standby
• Configuration
  • SQL can be filtered
    • Operations on a given object
    • Classes of DDL (e.g. CREATE TABLE)
  • Same log transport options as Physical Standby

Logical Standby: Configuration

Logical Standby: Setup Considerations

• Adequate network bandwidth
• Additional disk space for LogMiner dictionary
• Adequate CPU, as LogMiner and SQL Apply can be resource-intensive
• Performance may be a problem

New for 10g R1...

• Real-time apply
  • Redo information applied to standby database as it is received—no wait for standby redo log to be archived
• Recovery through OPEN RESETLOGS
  • Execution of OPEN DATABASE RESETLOGS on primary does not require re-creation of standby
• FLASHBACK DATABASE support
• Simplified configuration management

...New for 10g R1

• Use of Flash Recovery Area for archiving
• Archiver process supports remote standby redo logs
• Default archiver behavior is to archive locally before transmitting to standby
• Secure redo data transmission
• Better RAC support

R2 Fast-Start Failover

• Allows automatic transition to standby database
• Old primary database is automatically reconfigured as new standby database
  • once reconnected to the Data Guard configuration
• Eliminates downtime once required to allow notification of the DBA and subsequent execution of manual steps to effect the failover

R2 Flashback Database across Switchovers

• Primary and standby can be flashed back to an SCN or time prior to a role transition
• When used on physical standby, the database roles (primary and standby) are preserved
• When used on logical standby, the role of the standby is changed to what it was at the SCN or time

R2 MAX_CONNECTIONS

• MAX_CONNECTIONS attribute for the LOG_ARCHIVE_DEST_n parameter
  • Provides parallelization of redo transmission by archiver processes
  • Reduces redo transmission time

R2 Asynchronous Redo Transmission…

• Network server process (LNSn) retrieves and transmits redo directly from the primary database online redo logs
• No longer interacts with the log writer (LGWR) process
• Improves LGWR performance by allowing it to write data continuously to the online logs without waiting for completion of transmission to the standby

…R2 Asynchronous Redo Transmission

• Asynchronous Redo Transmission

Physical Standby: New for 10g R1

• New default behavior for STARTUP, MOUNT, and OPEN commands on standby
  • STARTUP starts, mounts, and opens a physical standby DB in read-only mode in a single step
  • ALTER DATABASE MOUNT no longer requires STANDBY DATABASE keywords
  • ALTER DATABASE OPEN no longer requires READ ONLY keywords

Physical Standby: New for 10g R2…

• Conversion of a physical standby database to a read/write reporting database
  • Activate as primary
  • Opened read/write
  • Flash back to previous point in time
  • Convert back to standby
  • Data Guard automatically synchronizes with the primary
  • Useful for cloning as well as read/write reporting

…Physical Standby: New for 10g R2…

• RMAN automatically re-creates tempfiles after recovery
  • Tempfiles are not saved or restored by RMAN
  • In previous releases, when an RMAN backup was used to create a physical standby database, tempfiles had to be created manually
  • Now, RMAN automatically recreates tempfiles that belong to a locally managed temporary tablespace

…Physical Standby: New for 10g R2

• Faster Redo Apply failover
  • Transition a standby to primary database role without a database restart
  • IF standby has not been opened read-only since last started
  • Better support for rolling upgrades
• New FORCE keyword on RECOVER MANAGED STANDBY DATABASE FINISH
  • Stops active Remote File Server processes on the target standby database
  • Failover will proceed immediately once logs have been applied

Logical Standby: New for 10g R1

• Instantiation with zero downtime
  • Uses online backup of primary
• Support for Maximum Protection mode
  • Using standby redo log files
• Support for additional datatypes
  • LONG, LONG RAW, NCLOB

Logical Standby: New for 10g R2…

• Faster SQL Apply failover
  • Failover no longer requires restart of SQL Apply
  • Better support for rolling upgrades
• Additional data type support for Index- Organized Tables
  • SQL Apply can use redo data generated by index-organized tables that contain LOB columns and overflow segments

…Logical Standby: New for 10g R2…

• Simplified creation of logical standby database
  • Creation of a specialized logical standby control file is no longer required
  • Logical standby databases can now be created easily from a physical standby database
• Management of archived redo log files
  • SQL Apply automatically deletes archived log files that have been applied on the logical standby database

…Logical Standby: New for 10g R2

• Management enhancements
  • New views
    • V$LOGSTDBY_PROCESS (replaces V$LOGSTDBY view)
    • V$LOGSTDBY_STATE
    • V$LOGSTDBY_PROGRESS
    • V$LOGSTDBY_TRANSACTION
    • V$DATAGUARD_STATS
  • DBMS_LOGSTDBY.REBUILD() subprogram in the DBMS_LOGSTDBY PL/SQL package
  • Tracing

Data Guard Summary

• Improved performance
• Less exposure to data loss
• Fewer manual operations
• Increased flexibility
• Increased manageability
• Reduced monitoring requirements