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

8/6/2019 The Basics About Oracle's 10gR2 Data Guard for Backup & Recovery

http://slidepdf.com/reader/full/the-basics-about-oracles-10gr2-data-guard-for-backup-recovery 1/31

Advanced Technical Support, Americas

© 2009 IBM Corporation

Oracle on Linux for System z Customer Workshop2009

Oracle’s Data Guardfor Backup & Recovery & Failover

Spencer Krueger, [email protected]




© 2009 IBM Corporation 2Oracle on Linux for System z Customer Workshop

Oracle’s Data Guard

Basic Backup & Recovery Practices w/o Data Guard

What is it?

Configuration: Primary & Standby databases

Functional Components

Benefits

Strategic Fit: HA & DR





Basic: Elements of Backup and Recovery StrategiesKey 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 safeplace, 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 aredifferent than the database files





Two phases to a Recovery:

Oracle rolls forward by applying redo records to the corresponding datablocks

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 thechange to disk, Oracle uses the redo record to update the data block to reflect thenew 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 isdifferent 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 specifiedsystem change number (SCN) in the redo record

Basic: Recovery Options





Basic: Backup/Recovery Tools

Recovery Manager (RMAN): A utility which establishes aconnection with a server process, then automates the

movement of data for backup and recovery operationsOracle Enterprise Manager (OEM): A GUI interface used to

invoke RMAN

Oracle Data Pump: A utility to make logical backups bywriting data from an Oracle database to a dump file

Very useful for development environments or restoring asingle table

User Managed: The database is backed up manually usingLinux 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 productiondatabase

Data Guard’s primary objective is to ensure high availability, dataprotection, auto switch and disaster recovery of your Primary productiondatabase

Utilizes a set of services to create, maintain, manage, and monitor

one or more standby databases to recover and restore from adisaster or data corruption

Maintains standby databases as transaction-ally consistent copiesof the production database

If the production database becomes unavailable, Data Guard can switchany standby database to the production role, minimizing outage downtime

DG is part of Oracle’s overall HA & DR Strategy





Data Guard: Failover Protection

Comprehensive data protection – e.g. data corruptions don’t propagate

Failover in seconds – standby is already synchronized

Zero data loss over large distances – advantage over array-based mirroringtechnologies (mirroring by the storage system, not the database)

Data Guard

Production

DatabaseSynchronous

Redo Shipping

Automatic Failover

Physical

or Logical

Standby DB





Data Guard: Typical Configuration

As changes (I,U,D) are applied to the Primary database, redo data isgenerated and written to the local redo log

Data Guard transmits that local redo log data to Standby database(s)





Data Guard: Rules for a Primary & Standby databasePrimary 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 physicalorganization and structure of the data can be different





Data Guard: Primary & Standby Role ChangesSwitchover

– 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 andexecute a failover to the standby database without manual intervention

Manually

– Once problem corrected, the failed primary can be quickly reinstatedas a standby database for the new primary using a;

Oracle Flashback Database which provides database point in time recoverywithout requiring a backup of the database to first be restored





Data Guard: Creating & Synch of Standby Databases

Initially a backup copy of the Primary database is used to CreateStandby

Standby databases may be geographically dispersed Oracle recommends you configure standby databases at remote

locations

Data Guard automatically maintains the standby database from initialcreation 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





Data Guard: Types of APPLY

The “role” of a database can beswitched from Primary to Standbyand vice versa.

Two methods of APPLY based on two types of Standbydatabases:

Physical uses Direct/Redo Apply

Logical uses SQL Apply





Direct/Redo Apply

Used for Physical Standby

Data Guard uses “Direct” Redo Apply (standard Oracle recoverytechniques, RMAN)

– Redo log records from Primary database are applied directly to PhysicalStandby 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 areconstructed, and then applied/executed against the Logical Standby

database(s) RW access to Logical Standby

Data Guard: Direct Apply vs. SQL Apply Log Services

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





Physical standbys offer:

Direct Redo Apply is faster and far more efficient

An identical physical copy ofthe primary database

Disaster recovery and highavailability

Data protection

Reduction in primary database

workload

Performance

Logical standbys offer:

Upgrade Oracle software/ patchsets with almost no downtime

Used concurrently for Recovery/Disaster Recovery andReporting/Queries

Efficient use of standby hardwareresources

Reduction in primary database

workload (RMAN backup off-load) Some limitations on the use of

certain datatypes (LONG RAW,BFILE, ROWID, UROWID, NCLOB)

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





Data Guard: Interfaces Three ways to manage a Data Guard environment:

All operations can be managed Locally or Remotely:

Through the “broker’s” Data Guard OEM web interface

1. SQL*Plus and native SQL Stmts (switchover operation)

2. Data Guard Broker Interface (Data Guard Manager)

– GUI version of Data Guard Broker interface that allows you toautomate many of the tasks involved in configuring andmonitoring

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

– Alternative interface to using the Data Guard Manger. It is usefulif you want to use the broker from batch programs or scripts

– Data Guard command-line interface (CLI) called DGMGRL





Data Guard: Broker Component ConfigurationBroker (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 aprofile for the primary database and each standby database

continued…





Data Guard: Broker Component ConfigurationConfiguration “object” - is a named collection of database profiles.

Database profile is a description of a database object including itscurrent state, current status, and properties

Broker treats a database as a collection of one or more named instances

continued…

Database “object(s)” – correspondsto a primary or standby database(s)

The broker uses a database objectprofile to manage and control thestate of a single database on agiven system.

Removing a standby database fromData Guard broker control does notdelete the database

Only removes the standby profilefrom the broker config file.





Client Side - Components of the Broker

The Data Guard Manager & Command Line Interface (DGMGRL) make upthe client side components of Data Guard Broker.

– DGM is a graphical user interface integrated with OEM. It contains wizards to ease themanagement of a Data Guard configuration.

Server Side - Components of the Broker

Data Guard Monitor (DMON) process; Responsible for managing a consistentcopy of the configuration file across the entire Data Guard configuration and gatheringhealth statistics

Data Guard: Broker Component Configuration





Data Guard: Log Transport Services Transmit redo data from the primary system to the standby systems in theconfiguration

Enforce protection modes. Configure log transport services to balance data protectionand availability against performance

Automatically detect missing/corrupted archived redo log files on a standby systemand automatically retrieve replacement archived redo log files from the primarydatabase or another standby database

Manage the process of resolving any gaps in the archived redo log files due to anetwork failure

Example:

Transport Services archivesredo data to the PRIMARY

database while alsotransmitting to archived redoSTANDBY redo log files at astandby database.





Data Guard: Broker Protection ModesSetting 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 primarydatabase and transactions are not committed on the primary database unlessthe 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 theprimary database

– When the fault is corrected, the standby database is automaticallyresynchronized 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 primarydatabase does not wait for the standby database to acknowledge completingwrite operations.





Data GuardFunctional & System Impact Considerations





Data Guard: Network Performance ROT

DG’s performance goal: Provide configurations that shipredo data to the remote disaster recovery site fast

enough to meet recovery time and recovery pointobjectives

Need AWR reports during normal and peak workload anddetermine 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





Data Guard: Reduced Network Bandwidth

An internal analysis byOracle of their corporate

e-mail system, showedthat Data Guard utilized:

7 times less data

transmitted over thenetwork

Required 27 times less I/Ooperations, than using a

remote mirroring solution





Data Guard: General Operational Requirements

All databases must use the same edition of Oracle EnterpriseEdition (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 thesame version

Same hardware and OS architecture (32-bit to 32-bit, etc.)

User accounts on both databases must have SYSDBAprivileges

Data Guard generally deployed between CECs





Data Guard: BenefitsSynchronizes 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 productiondatabase, 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-onlymode 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 inthe past if need to get a table.





Data Guard: Strategic Fit with Other HA & DR TechnologiesReal 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, andprovide:

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 archivedredo log files used for input after performing a backup





…and that’s a

High-Level Overview

of

Oracle’s Data Guard…







Data Guard: Service/Apply Process Components Log Apply Services

Redo Apply (Physical Standby)

SQL Apply (Logical Standby)

Broker (DMON)

Apply ProcessArchitecture

Supporting processes

Log Transport Services Protection level/modes





Data Guard: Apply Process Architecture

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

Documents