Professional Documents
Culture Documents
Oracles disaster recovery solution for Oracle data; Feature of Oracle Database Enterprise Edition (EE);
Automates the creation and maintenance of one or more transactionally consistent copies (standby) of the production (or primary) database;
If the primary database becomes unavailable (disasters, maintenance), a standby database can be activated and assume the primary role.
SIMPLY PUT
Data Guard helps you protect your Data.
Takes your data and automatically puts it elsewhere Makes it available for Failover in case of failure.
ARCHITECTURE
Transactions
Oracle Net
LGWR
Primary Database
FAL
Backu p/ Report s
ARCH ARCH
Archived Redo Logs Archived Redo Logs
ARCHITECTURE CONTINUES
Primary Database: A Data Guard configuration contains one production database, also referred to as the primary database that functions in the primary role.
The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters database. LGWR / ARCH Process
Fetch Archive Log (FAL) Process Provides client-server mechanism for shipping archived logs to the Standby. For automatic gap resolution and resynchronization.
ARCHITECTURE CONTINUES
Standby Database: A standby database is a transactionally consistent copy of the primary database.
Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database.
Redo changes transported from primary to standby applied on standby (Redo Apply)
Can switch operations to standby Failover time deplaned (switchover / switchback) Unplanned (failover)
pendent on various factors Rate of redo generation / size of redo logs Redo transport / apply configuration
ARCHITECTURE CONTINUES
Logical standby database
Introduced in Oracle 9.2 Subset of database objects Redo copied from primary to standby Changes converted into logical change records (LCR) Logical change records applied on standby (SQL Apply) Standby database can be opened for updates Can modify propagated objects Can create new indexes for propagated objects
May need larger system for logical standby LCR apply can be less efficient than redo apply Array updates on primary become single row updates on
standby
ARCHITECTURE CONTINUES
Processes Involved in Standby Recovery phase: Remote File Server (RFS)
LSP Continues
SQL Apply uses a collection of parallel execution servers and background processes.
Preparer process Covert the block changes into table changes, Logical Change Records (LCRs);
Analyzer Process Examines the completed transactions, identifying dependencies between the different transactions.
Coordinator Process Assigns transactions to the Applier process, monitor dependencies between the transactions and authorize the commit of changes to the logical standby database.
Applier Process Apply the changes into the database and commit the transactions.
PROTECTION LEVELS
The Protection Levels define how the Primary functions in the standby configuration. They are:
PROTECTION MODES
Protection Mode Maximum Protection Zero Data Loss Failure Protection Protects Against Primary and Network Failure Redo Shipping LGWR using SYNC and SRL
Maximum Performance
Data Loss! ; Highest Level of Protection; Configuration: LGWR SYNC, SRLs; Enforces protection of every transaction; If last standby is unavailable, processing stops at primary; Good for financial systems where no data loss is acceptable;
Data Loss! as long as the network stays up!; Configuration: LGWR SYNC, SRLs; Enforces protection of every transaction; If last standby is unavailable, processing continues at primary; When the standby becomes available again, synchronization with the primary is automatic ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;
Level of Performance; Configuration: LGWR ASYNC or ARCH; Protects from failure of any single component; Least impact on production system; Useful for applications that can tolerate some data loss.
Failover
Failover is performed only in the event of a catastrophic failure of the primary database, and the failover results in a transition of a standby database to the primary.
HIGH LEVEL
Broader perspective, Data Guard comprises of two parts: REDO APPLY (DR) Maintains a physical, block for block copy of the Production (also called Primary) database.
Backup
Physical Standby Database is a block-for-block copy of the primary database Uses the database recovery functionality to apply changes Can be opened in read-only mode for reporting/queries Can also perform backup, offloading production database The best solution for DR
Logical Standby Database is an open, independent, active database Contains the same logical information (rows) as the production database Physical organization and structure can be very different Can host multiple schemas Can be queried for reports while logs are being applied via SQL Can create additional indexes and materialized views for better query performance Not all Data Types supported (See the manual for a list)
By default, redo transport services use ARCn processes to archive the online redo log files on the primary database.
ARCn archival processing supports only the maximum performance level of data protection in Data Guard configurations.
LGWR process would be used to transmit redo data to standby locations that operate in other data protection modes.
Primary Database
LGWR
RFS
MRP LSP
Standby Database
ARC0 LOG_ARCHIVE_DEST_1
ARC1
ARCn
Primary Database
LGWR
RFS
MRP LSP
Standby Database
LNSn
ARCn
Primary Database
LGWR
LNSn
RFS
MRP LSP
Standby Database
ARCn
Planned failover to standby database Original primary becomes new standby Original standby becomes new primary No data loss switchback at any time
Can
Failover
Unplanned failover to standby database Original standby becomes new primary Original primary may need to be rebuilt Possible data loss
Database
Database
Database
Database
Primary Database
Standby Database
Standby Database
Primary Database
Instance
Database
Database
Database
Database Database
Primary Database
Standby Database
Unavailable
Databas
SQL Apply Maintains a logical, transaction-for-transaction copy of the primary. Allows creation of additional objects, modification of objects. Possible to skip apply on certain objects. Can be used as a good reporting solution supports real-time reporting in 10g. Has data type restrictions.
At role transition, offers the assurance that the standby database chosen to be the new primary has not been changed compared to the old primary.
Step 1 - Prepare the Primary for Standby Step 2 - Copy the necessary files to standby system Step 3 - Configure the Standby Parameters Step 4 - Configure OracleNet Step 5 - Startup the Standby Site Step 6 - Begin Shipping and Applying Redo
CONFIGURATION
Attached the document which has Step-by-Step configuration of Physical Standby Database.
Step 1 - Prepare the Primary for Standby Step 2 - Copy the necessary files to standby system Step 3 - Configure the Standby Parameters Step 4 - Configure OracleNet Step 5 - Startup the Standby Site Step 6 - Begin Shipping and Applying Redo
CONFIGURATION
Attached the document which has Step-by-Step configuration of Logical Standby Database.
Step 1 Resolve the archived log Gaps. Step 2 Verify the status of the databases to Switchover. Step 3 Adjust the initialization parameters. Step 4 Perform the switchover.
Step 1 Resolve the archived log Gaps. Step 2 Verify the status of the databases to Switchover. Step 3 Adjust the initialization parameters. Step 4 Perform the switchover.
Step 1 Resolve the archived log Gaps. Step 2 Adjust the initialization parameters. Step 3 Initiate the Failover. Step 4 Covert the Database Roles. Step 5 Backup the new Primary Database. Step 6 Optionally, Restore the failed Primary Database.
PHYSICAL .
Attached the document which has Step-by-Step configuration to perform failover with Physical Standby Database.
Step 1 Resolve the archived log Gaps. Step 2 Adjust the initialization parameters. Step 3 Initiate the Failover. Step 4 Covert the Database Roles. Step 5 Recover the other Standby Databases. Step 6 Backup the new Primary Database. Step 7 Optionally, Restore the failed Primary Database.
LOGICAL STANDBY
Attached the document which has Step-by-Step configuration to perform failover with Logical Standby Database.
SUMMARY.!!!
Data Guard provides an automated standby database which can essentially eliminate downtime of your production data.
Setup is easy and fairly straightforward. Maintenance is minimal. Switchovers and failovers can be done within a few minutes.
Reporting can be offloaded to the standby to ease the workload on the primary. And It's Free! (Included with Enterprise Edition)