for Backup & Recovery & Failover

Oracle s DataGuard 2009 for Backup & Recovery & Failover 2009 IBM Corporation Spencer Krueger, IBM skrueger@us.ibm.com

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 2009 IBM Corporation 2

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 Filesand store them in a safe place, multiple copies if possible Maintain multiple concurrent backups of the Control Files Multiplex the Online Redo Logs Enable ARCHIVELOGmode, archive redo logs to locations that are different than the database files 2009 IBM Corporation 3

Basic: Recovery Options Two phases to a Recovery: Oracle rolls forwardby 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 crashesbefore 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 2009 IBM Corporation 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 2009 IBM Corporation 5

Data Guard 2009 IBM Corporation 6

Data Guard: What is It? Automate the management, monitoring, creation and maintenance of a standby database(s) to protect your Oracle production database Data Guard s primary objectiveis to ensure high availability, data protection, auto switch and disaster recovery of your Primaryproduction database Utilizes a set of servicesto create, maintain, manage, and monitor one or more standby databasesto 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 Oracle s overall HA & DR Strategy 2009 IBM Corporation 7

Data Guard: Failover Protection Production Database Automatic Failover Synchronous Redo Shipping Physical or Logical Standby DB Data Guard 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 mirroring technologies (mirroring by the storage system, not the database) 2009 IBM Corporation 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) 2009 IBM Corporation 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-diskByte-for-Byteexact 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 2009 IBM Corporation 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 detectprimary 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 Databasewhich provides database point in time recovery without requiring a backup of the database to first be restored 2009 IBM Corporation 11

Data Guard: Creating & Synch of Standby Databases Initially a backup copyof 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 Synchronousor Asynchronous Two methods to apply redo data to the Standby: Redo Apply, used for physicalstandby databases SQL Apply, used for logicalstandby databases These two methods correspond to the two types of Standby databases 2009 IBM Corporation 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 switchedfrom Primary to Standby and vice versa. 2009 IBM Corporation 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??? 2009 IBM Corporation 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 limitationson the use of certain datatypes(long RAW, BFILE, ROWID, UROWID, NCLOB) 2009 IBM Corporation 15

Data Guard: Interfaces Three ways to manage a Data Guard environment: 1. SQL*Plus and native SQL Stmts(switchover operation) 2. Data Guard Broker Interface (Data Guard Manager) All operations can be managed Locally or Remotely: GUI version of Data Guard Brokerinterface that allows you to automate many of the tasks involved in configuring and monitoring 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 Through the broker s Data Guard OEM web interface 2009 IBM Corporation 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 2009 IBM Corporation 17

Data Guard: Broker Component Configuration Configuration object - is a named collection of database profiles. Database profileis a description of a database objectincluding 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 profileto manage and control the state of a single database on a given system. Removing a standbydatabase from Data Guard broker control does not delete the database Only removes the standby profile from the broker config file. continued 2009 IBM Corporation 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 fileacross the entire Data Guard configuration and gathering health statistics 2009 IBM Corporation 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 logfiles 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 gapsin 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 STANDBYredo log files at a standby database. 2009 IBM Corporation 20

Data Guard: Broker Protection Modes Setting up your Primarydatabase configuration for different levels of Data Protection Maximum Protection- Highest level of data protection Data is synchronouslytransmitted to the standby database from the primary database and transactions are not committed on the primary databaseunless 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 acknowledgecompleting write operations. 2009 IBM Corporation 21

Data Guard Functional & System Impact Considerations 2009 IBM Corporation 22

Data Guard: Network Performance ROT DG sperformance 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 2009 IBM Corporation 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 2009 IBM Corporation 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 2009 IBM Corporation 25

Data Guard: Benefits Synchronizes a standby database(s) with production database Standby databases can be located at remotedisaster recovery sites (long distances from the production data center) Automatically switches rolesbetween 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 standbydatabase in read-only mode to allow read-only queries so that server resources are not wasted. Logical standbyused 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. 2009 IBM Corporation 26

Data Guard: Strategic Fit with Other HA & DR Technologies Real Application Clusters (RAC) &Data Guardtogether 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 Guardare 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 2009 IBM Corporation 27

and that s a High-Level Overview of Oracle s Data Guard 2009 IBM Corporation 28

Additional Slides 2009 IBM Corporation 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 2009 IBM Corporation 30

Data Guard: Apply Process Architecture 2009 IBM Corporation 31