The Basics About Oracle's 10gR2 Data Guard For Backup & Recovery

Advanced Technical Support, Americas
Oracle on Linux for System z Customer Workshop 2009
Oracles Data
Guard
for Backup & Recovery & Failover
Spencer Krueger, IBM

2009 IBM Corporation
skrueger@us.ibm.com
Oracles Data Guard

Basic Backup & Recovery Practices w/o Data Guard What is it? Configuration: Primary & Standby databases Functional Components Benefits Strategic Fit: HA & DR
Oracle on Linux for System z Customer Workshop
Basic: Elements of Backup and Recovery Strategies

Key structures to consider are:
Data Files Control files Online redo log files Archived redo log files Automatic Managed Undo (previously rollback segments, before commit)
Take frequent backups of physical Data Files and store them in a safe place, multiple copies if possible Maintain multiple concurrent backups of the Control Files Multiplex the Online Redo Logs Enable ARCHIVELOG mode, archive redo logs to locations that are different than the database files
3
Basic: Recovery Options

Two phases to a Recovery:
Oracle rolls forward by applying redo records to the corresponding data blocks Then, Oracle rolls back any transactions that were not committed
Example: If a user adds a row to a table, but the server crashes before it can save the change to disk, Oracle uses the redo record to update the data block to reflect the new row.
Database level; most current point-in-time is the default option Tablespace point-in-time recovery (TSPITR)
A user level recover of one or more tablespaces to a point-in-time that is different from the rest of the database
Change-based recovery or log sequence recovery

If O/S commands are used, change-based recovery recovers up to a specified system change number (SCN) in the redo record
4
Basic: Backup/Recovery Tools

Recovery Manager (RMAN): A utility which establishes a connection with a server process, then automates the movement of data for backup and recovery operations Oracle Enterprise Manager (OEM): A GUI interface used to invoke RMAN Oracle Data Pump: A utility to make logical backups by writing data from an Oracle database to a dump file
Very useful for development environments or restoring a single table
User Managed: The database is backed up manually using Linux file system commands or shell scripts
Data Guard
Data Guard: What is It?

Automate the management, monitoring, creation and maintenance of a standby database(s) to protect your Oracle production database
Data Guards primary objective is to ensure high availability, data protection, auto switch and disaster recovery of your Primary production database
Utilizes a set of services to create, maintain, manage, and monitor one or more standby databases to recover and restore from a disaster or data corruption Maintains standby databases as transaction-ally consistent copies of the production database
If the production database becomes unavailable, Data Guard can switch any standby database to the production role, minimizing outage downtime
DG is part of Oracles overall HA & DR Strategy

2009 IBM Corporation Oracle on Linux for System z Customer Workshop
7
Data Guard: Failover Protection

Physical or Logical Standby DB
Automatic Failover Production Database
Synchronous Redo Shipping
Data Guard
Comprehensive data protection e.g. data corruptions dont propagate Failover in seconds standby is already synchronized Zero data loss over large distances advantage over array-based mirroring technologies (mirroring by the storage system, not the database)
8
Data Guard: Typical Configuration
As changes (I,U,D) are applied to the Primary database, redo data is generated and written to the local redo log Data Guard transmits that local redo log data to Standby database(s)
9
Data Guard: Rules for a Primary & Standby database

Primary database: One, and only one database is designated as the Primary All others are Standby databases Associated with up to 9 Standby databases Single-instance or Oracle RAC database Data Guard requires Archive log mode enabled on Primary database
"ALTER DATABASE ARCHIVELOG"
Standby databases: Type of Standby determines sync method w/Primary Like a Primary; can be an Oracle single-instance or Oracle RAC database Physical: On-disk Byte-for-Byte exact copy of the primary database structure. Rowids stay the same in the Physical Standby. Logical: Same logical information as the production, but the physical organization and structure of the data can be different
10
Data Guard: Primary & Standby Role Changes

Switchover
Alternate Roles Planned maintenance of the primary system Transition/switch occurs without having to re-create either database
Failover
Standby database takes the primary role following a sudden outage Optional ways to execute failovers:
Configure Data Guard to automatically detect primary database failures and execute a failover to the standby database without manual intervention Manually
Once problem corrected, the failed primary can be quickly reinstated as a standby database for the new primary using a;
Oracle Flashback Database which provides database point in time recovery without requiring a backup of the database to first be restored
11
Data Guard: Creating & Synch of Standby Databases

Initially a backup copy of the Primary database is used to Create Standby
Standby databases may be geographically dispersed Oracle recommends you configure standby databases at remote locations
Data Guard automatically maintains the standby database from initial creation onward
Standby is a synchronized copy of the Primary database
Redo log records transmitted from primary, are then applied Synchronous or Asynchronous
Two methods to apply redo data to the Standby:

Redo Apply, used for physical standby databases SQL Apply, used for logical standby databases These two methods correspond to the two types of Standby databases
12
Data Guard: Types of APPLY

Two methods of APPLY based on two types of Standby databases:
Physical uses Direct/Redo Apply Logical uses SQL Apply
The role of a database can be switched from Primary to Standby and vice versa.
13
Data Guard: Direct Apply vs. SQL Apply Log Services

Direct/Redo Apply
Used for Physical Standby Data Guard uses Direct Redo Apply (standard Oracle recovery techniques, RMAN)
Redo log records from Primary database are applied directly to Physical Standby database(s) as redo transactions
RO access to Physical Standby
SQL Apply
Used for Logical Standby Primary database Redo log records are read and SQL statements are constructed, and then applied/executed against the Logical Standby database(s) RW access to Logical Standby
So, why would I use a Physical vs. Logical & vice-versa???

14
Data Guard: Why use a Logical vs. Physical Standby (vice-versa)?

Physical standbys offer:
Direct Redo Apply is faster and far more efficient An identical physical copy of the primary database Disaster recovery and high availability Data protection Reduction in primary database workload Performance
Logical standbys offer:

Upgrade Oracle software/ patch sets with almost no downtime Used concurrently for Recovery/Disaster Recovery and Reporting/Queries Efficient use of standby hardware resources Reduction in primary database workload (RMAN backup off-load) Some limitations on the use of certain datatypes (LONG RAW, BFILE, ROWID, UROWID, NCLOB)
15
Data Guard: Interfaces

Three ways to manage a Data Guard environment:
1. SQL*Plus and native SQL Stmts (switchover operation)
GUI version of Data Guard Broker interface that allows you to automate many of the tasks involved in configuring and monitoring
2. Data Guard Broker Interface (Data Guard Manager)
3. Data Guard Broker Command-Line Interface (CLI)

Alternative interface to using the Data Guard Manger. It is useful if you want to use the broker from batch programs or scripts Data Guard command-line interface (CLI) called DGMGRL
All operations can be managed Locally or Remotely:

Through the brokers Data Guard OEM web interface
16
Data Guard: Broker Component Configuration

Broker (OEM or Command-line) simplifies the management of a Data Guard environment
Configuration of databases A single database

Broker configuration consists of:
Configuration object Database object(s) Instance object(s)

Broker supports one or more Data Guard configurations, each includes a profile for the primary database and each standby database
continued
17
Data Guard: Broker Component Configuration

Configuration object - is a named collection of database profiles.
Database profile is a description of a database object including its current state, current status, and properties Broker treats a database as a collection of one or more named instances Database object(s) corresponds to a primary or standby database(s) The broker uses a database object profile to manage and control the state of a single database on a given system. Removing a standby database from Data Guard broker control does not delete the database Only removes the standby profile from the broker config file.
continued
18
Data Guard: Broker Component Configuration Client Side - Components of the Broker
The Data Guard Manager & Command Line Interface (DGMGRL) make up
the client side components of Data Guard Broker.
DGM is a graphical user interface integrated with OEM. It contains wizards to ease the management of a Data Guard configuration.
Server Side - Components of the Broker

Data Guard Monitor (DMON) process; Responsible for managing a consistent
copy of the configuration file across the entire Data Guard configuration and gathering health statistics
19
Data Guard: Log Transport Services

Transmit redo data from the primary system to the standby systems in the configuration Enforce protection modes. Configure log transport services to balance data protection and availability against performance Automatically detect missing/corrupted archived redo log files on a standby system and automatically retrieve replacement archived redo log files from the primary database or another standby database Manage the process of resolving any gaps in the archived redo log files due to a network failure
Example:
Transport Services archives redo data to the PRIMARY database while also transmitting to archived redo STANDBY redo log files at a standby database.
20
Data Guard: Broker Protection Modes

Setting up your Primary database configuration for different levels of Data Protection
Maximum Protection - Highest level of data protection
Data is synchronously transmitted to the standby database from the primary database and transactions are not committed on the primary database unless the redo data is available on at least one standby database.
Maximum Availability - Similar to the maximum protection mode, including zero data loss, however;
If a standby database becomes unavailable, processing continues on the primary database When the fault is corrected, the standby database is automatically resynchronized with the primary database.
Maximum Performance Lowest level of data protection, but higher available performance mode
The primary database processes transactions, redo data is asynchronously shipped to the standby database. The commit operation of the primary database does not wait for the standby database to acknowledge completing write operations.
21
Data Guard
Functional & System Impact Considerations
22
Data Guard: Network Performance ROT

DGs performance goal: Provide configurations that ship redo data to the remote disaster recovery site fast enough to meet recovery time and recovery point objectives Need AWR reports during normal and peak workload and determine the number of bytes per second of redo
General rule of thumb being 1-ms Real-Time Timer (RTT) latency per 33 miles
Configure DEFAULT_SDU_SIZE parameter in sqlnet.ora

DEFAULT_SDU_SIZE=32767
Set MTU size to Oracle Database Block Size

23
Data Guard: Reduced Network Bandwidth

An internal analysis by Oracle of their corporate e-mail system, showed that Data Guard utilized:
7 times less data transmitted over the network Required 27 times less I/O operations, than using a remote mirroring solution
24
Data Guard: General Operational Requirements

All databases must use the same edition of Oracle Enterprise Edition (OEM)
Both systems must match for Endian, chip set and headers
Use of the same Oracle software release Same type of operating system, but not necessarily the same version Same hardware and OS architecture (32-bit to 32-bit, etc.) User accounts on both databases must have SYSDBA privileges
Data Guard generally deployed between CECs
25
Data Guard: Benefits

Synchronizes a standby database(s) with production database Standby databases can be located at remote disaster recovery sites (long distances from the production data center) Automatically switches roles between a standby and production database, if the production database becomes unavailable Avoid backup process overhead from primary production systems Provide rolling:
Database upgrades and patching Hardware and operating system upgrades and system maintenance
In 10gR2, you can open a physical standby database in read-only mode to allow read-only queries so that server resources are not wasted.
Logical standby used in read/write mode for development, reporting, or testing purposes, and flashed back to a point in the past if need to get a table.
26
Data Guard: Strategic Fit with Other HA & DR Technologies

Real Application Clusters (RAC) & Data Guard together provide the benefits of both system-level, site-level, and data-level protection Flashback Database/Table/Drop/Query Versions/Transaction Query
Redundancy for key files such as the control and redo log files The ability to manage and delete backup files automatically Oracle Flashback Database and guaranteed restore points features
Recovery Manager (RMAN) & Data Guard are well integrated, and provide:
RMAN DUPLICATE; create a standby from primary database backup Take backups on a physical standby, rather than production database Manage archived redo log files by automatically deleting the archived redo log files used for input after performing a backup
27
and thats a High-Level Overview of Oracles Data Guard
28
Additional Slides
29
Data Guard: Service/Apply Process Components

Log Apply Services Redo Apply (Physical Standby) SQL Apply (Logical Standby)
Broker (DMON) Apply Process Architecture

Supporting processes
Log Transport Services

Protection level/modes
30
Data Guard: Apply Process Architecture
31

The Basics About Oracle's 10gR2 Data Guard For Backup & Recovery

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Basics About Oracle's 10gR2 Data Guard For Backup & Recovery

Uploaded by

Copyright:

Available Formats

Advanced Technical Support, Americas

Oracle on Linux for System z Customer Workshop 2009

for Backup & Recovery & Failover

Spencer Krueger, IBM

Advanced Technical Support, Americas

Oracles Data Guard

2009 IBM Corporation

Oracle on Linux for System z Customer Workshop

Advanced Technical Support, Americas

Basic: Elements of Backup and Recovery Strategies

Oracle on Linux for System z Customer Workshop

Advanced Technical Support, Americas

Basic: Recovery Options

Change-based recovery or log sequence recovery

Oracle on Linux for System z Customer Workshop

Advanced Technical Support, Americas

Basic: Backup/Recovery Tools

2009 IBM Corporation

Oracle on Linux for System z Customer Workshop

Advanced Technical Support, Americas

2009 IBM Corporation

Oracle on Linux for System z Customer Workshop

Advanced Technical Support, Americas

Data Guard: What is It?

DG is part of Oracles overall HA & DR Strategy

Advanced Technical Support, Americas

Data Guard: Failover Protection

Automatic Failover Production Database

Synchronous Redo Shipping

Advanced Technical Support, Americas

Data Guard: Typical Configuration

Advanced Technical Support, Americas

Data Guard: Rules for a Primary & Standby database

Advanced Technical Support, Americas

Data Guard: Primary & Standby Role Changes

Advanced Technical Support, Americas

Data Guard: Creating & Synch of Standby Databases

Two methods to apply redo data to the Standby:

2009 IBM Corporation

Oracle on Linux for System z Customer Workshop

Advanced Technical Support, Americas

Data Guard: Types of APPLY

Advanced Technical Support, Americas

Data Guard: Direct Apply vs. SQL Apply Log Services

RO access to Physical Standby

So, why would I use a Physical vs. Logical & vice-versa???

Advanced Technical Support, Americas

Data Guard: Why use a Logical vs. Physical Standby (vice-versa)?

Logical standbys offer:

2009 IBM Corporation

Oracle on Linux for System z Customer Workshop

Advanced Technical Support, Americas

Data Guard: Interfaces

2. Data Guard Broker Interface (Data Guard Manager)

3. Data Guard Broker Command-Line Interface (CLI)

All operations can be managed Locally or Remotely:

Advanced Technical Support, Americas

Data Guard: Broker Component Configuration

Configuration of databases A single database

Configuration object Database object(s) Instance object(s)

Advanced Technical Support, Americas

Data Guard: Broker Component Configuration