Agenda Data Guard Architecture & Features Data Guard Success Stories & Benefits

What is Oracle Data Guard? Oracle’s disaster recovery solution for Oracle data Feature of Oracle Database Enterprise Edition 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 Oracle Data Guard is the management, monitoring, and automation software that includes an Oracle production database and one or more Oracle standby databases to protect enterprise data from failures, disasters, errors, and corruptions that might otherwise take the database down. It protects critical data by automating the creation, management, and monitoring of the databases and other components in its configuration. It automates the otherwise manual process of maintaining a standby database that can be used if the production database is taken offline for routine maintenance or becomes damaged.

Oracle Data Guard Focus Data Failures & Site Disasters: All 3 are important! Data Protection Data Availability Data Recovery Data is the core asset of the enterprise! A recent Information Week survey demonstrated that data recovery is the top-most priority of today’s business managers, with almost 100% of 350 business/IT managers indicating that it is an essential element in their business continuity plans. Also addresses human errors & planned maintenances

Data Guard Overview Primary Standby Site Site Data Guard Broker Clients Clients Primary Site Standby Site Data Changes Oracle Data Guard consists of a production database (also known as the primary database) and one or more standby database(s), which are transactionally consistent copies of the production database. A standby database can either be a physical standby database, or a logical standby database. Later I will talk more about these two types of standby databases. The transactional consistency between primary and standby databases is maintained using Oracle online redo logs. As transactions change information stored in the primary database, the changes are also written to the online redo logs. These changes are transferred to the standby destinations by Log Transport Services and applied to the standby databases by Log Apply Services. Role Management Services work with Log Transport Services and Log Apply Services to reduce downtime of the primary database for planned outages and from unplanned failures by facilitating switchover and failover operations. Data Guard provides several management interfaces, including SQL statements, initialization parameters, a PL/SQL package, and the Oracle Data Guard Broker. The Broker is a distributed management framework that automates the creation and management of Data Guard configurations through the Data Guard Manager graphical user interface or its command-line interface. Data Guard Broker

Data Guard Configuration Standby Site A Primary Site Standby Site B Standby Database Primary Database Standby Database Managed as a single configuration Primary and standby databases can be Real Application Clusters or single-instance Oracle Up to nine standby databases supported in a single configuration

Oracle Data Guard Architecture Physical Standby Database Sync or Async Redo Shipping Backup Production Database Redo Apply Network Broker Logical Standby Database Transform Redo to SQL Open for Reports Oracle Data Guard consists of a production database (also known as the primary database) and one or more standby database(s), which are transactionally consistent copies of the production database. A standby database can either be a physical standby database, or a logical standby database. A physical standby database has on-disk database structures that are identical to the primary database on a block-by-block basis. A logical standby database is an independent database that contains the same data as the primary database. It is updated using SQL statements, and has the relative advantage that it can be used simultaneously for recovery and for other tasks such as reporting, and queries. The transactional consistency between primary and standby databases is maintained using Oracle online redo logs. As transactions change information stored in the primary database, the changes are also written to the online redo logs. These changes are transferred to the standby destinations by Log Transport Services and applied to the standby databases by Log Apply Services. Role Management Services work with Log Transport Services and Log Apply Services to reduce downtime of the primary database for planned outages and from unplanned failures by facilitating switchover and failover operations. Data Guard provides several management interfaces, including SQL statements, initialization parameters, a PL/SQL package, and the Oracle Data Guard Broker. The Broker aggregates the primary and standby databases into a single, unified grouping that can be centrally managed and monitored by the Broker as a whole. This obviates the need for discrete and complex sequences of commands that would otherwise be required to manage and monitor the primary and standby databases separately. SQL Apply Additional Indexes & MVs

Data Guard Redo Apply Physical Standby Database Primary Database Data Guard Broker Redo Apply Backup Network Redo Shipment Standby Redo Logs 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 be used for backups, offloading production database A physical standby database is kept synchronized with the primary database by applying the redo log data received from the primary. It is physically identical to the primary database on a block-for-block basis, because the Oracle media recovery mechanism is used to apply changes to a physical data block address. The database schemas, including indexes, are the same, and the standby database can be opened read-only. While the standby database is in the read-only mode, the primary database continues to ship redo data to the standby site. Oracle Data Guard also offers the flexibility to enable the physical standby database to switch between recovery and read-only modes, e.g. a sequence could involve running in recovery mode, then opening in read-only mode to run reports, and then returning to recovery mode to apply outstanding redo data. A physical standby server can be either of two modes: Managed Recovery in which the MRP (Managed Recovery Process) applies logs allowing the standby to keep pace with changes applied to the primary database. Open for read only to enable query reporting access Oracle9i Recovery Manager is aware of the standby database concept so it can be used to offload backups from the primary database saving valuable CPU and I/O cycles.

Continuously Open for Reports Data Guard SQL Apply Additional Indexes & Materialized Views Logical Standby Database Primary Database Data Guard Broker Transform Redo to SQL and Apply Continuously Open for Reports Network Redo Shipment Standby Redo Logs 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 A logical standby database is kept synchronized with the primary database by transforming the redo log data received from the primary into SQL statements and then applying the SQL statements. It contains the same logical information (rows) as the production database, although physical organization and structure of the data can be very different. Because the logical standby database is updated using SQL statements, it can remain open in read-write mode, and the tables that are being updated from the primary database can be used simultaneously for other tasks such as reporting, summations, and queries. These tasks can also be optimized by creating additional indexes and materialized views on the maintained tables to those used on the primary database. A logical standby database can host multiple database schemas, and users can perform normal data manipulation operations on tables in schemas that are not updated from the primary database.

Protection from Human Errors and Data Corruptions Primary Site Standby Site Optional Delayed Apply Data Changes Application of changes received from the primary can be delayed at standby to allow for the detection of user errors and prevent standby to be affected Administrators may choose not to configure any delay – if both primary and standby are affected, then they can be simply flashed back [10g] The apply process also revalidates the log records to prevent application of any log corruptions When a primary database is open and active and transactions, are in progress, redo log data is generated and shipped to standby sites. It is possible to delay the application of redo data already received at one or more standby databases. The ability to delay the application of changes to standby databases enables not only the protection of production data from data center disasters, but also provides a window of protection from user errors or corruptions. Of course, the apply process also revalidates the log records to prevent application of log corruptions.   If operating under the maximum protection or the maximum availability mode, Data Guard will ensure zero data loss even with this delayed apply in effect.

Switchover and Failover Primary and Standby role transitions Switchover Planned role reversal No database reinstantiation required Used for maintenance of OS or hardware Failover Unplanned failure (e.g. disasters) of primary Primary database must be reinstantiated / flashed back [10g] Initiated using simple SQL / GUI interface Data Guard automates the processes involved Oracle Data Guard offers two easy-to-use methods to handle planned and unplanned outages of the production site. These methods are called Failover and Switchover, and they are easily initiated using SQL or through the Data Guard Broker interface. The switchover option is the planned role reversal of the primary and standby databases, to handle planned maintenance on the primary database. The main difference between a switchover operation and a failover operation is that switchover does not require re-instantiation of the database. This allows the primary database to resume its role as the standby database almost immediately. As a result, scheduled maintenance can be performed more frequently. For example, switchover may be used to perform an upgrade on the primary site by switching over all of the database clients to the standby site as hardware is upgraded on the primary site. Failover is the operation of taking the primary database offline on one site and bringing one of the standby databases online as the new primary database. A failover operation can be invoked when an unplanned catastrophic failure occurs on the primary database, and there is no possibility of recovering the primary database in a timely manner. The failover operation is invoked on the standby database that will assume the primary role. After a failover, the original primary database must be re-instantiated to resume its role as a standby database.   Both failover and switchover operations guarantee zero data loss if Data Guard was being run in the maximum protection mode or maximum availability mode at the time of the failover or switchover. Failover and switchover operations also work seamlessly when multiple standby databases are included in the configuration. For example, if multiple standby databases are configured and the primary database goes down, the administrator has the flexibility to choose one of the available standbys to become the primary. Data Guard fully automates the process of redirecting the other standby databases to use the new primary, including shipping any missing logs or incomplete logs.

Flexible Data Protection Modes Risk of Data Loss Redo Shipment Maximum Protection Zero Data Loss Double Failure Protection Synchronous redo shipping to 2 sites Maximum Availability Single Failure Protection Synchronous redo shipping Maximum Performance Minimal data loss – usually 0 to few seconds Asynchronous redo shipping Oracle Data Guard provides three high-level modes of data protection to balance cost, availability, performance, and transaction protection. Using a simple SQL statement on the primary database, the Data Guard environment can be configured to maximize data protection, availability, or performance:   ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}; To determine the appropriate data protection mode to use, enterprises need to weigh their business requirements for data availability against user demands for response time and performance. The following slides talk about the details of each mode. Balance cost, availability, performance, and transaction protection

Automatic Resynchronization Network connectivity problems may occur Data Guard automatically resynchronizes standbys after network connectivity restored Implicit ARCH process idling away on the primary ‘pings’ all standbys on a regular basis to see if they are missing any redo data If so it sends them the missing redo data Explicit Gap discovered during apply process in physical standby Based on FAL_SERVER and FAL_CLIENT settings, primary notified, and it sends missing redo data

Data Guard Broker Distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations Management operations can be performed locally or remotely through easy-to-use interfaces: Oracle Enterprise Manager Data Guard Broker’s command-line interface Data Guard broker is the management and monitoring component that helps you create, control, and monitor a primary database protected by one or more physical standby databases as a single standby database configuration. The broker automates the previously manual process of configuration. Once it has created the Data Guard configuration, the broker monitors the activity, health, and availability for all systems in the Data Guard configuration. All management operations can be performed locally or remotely through the Broker's easy-to-use interfaces: Oracle Data Guard Manager, which is the Broker's graphical user interface (GUI) and the Data Guard command-line interface (CLI).

Real Time Apply Redo data is applied to the standby database as soon as it is received from the primary database Without this support, apply has to wait till an archivelog is created on the standby database Enables real-time reporting, faster switchovers/failovers For Redo Apply: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE For SQL Apply: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE When real time apply is enabled, RECOVERY_MODE column in V$ARCHIVE_DEST_STATUS displays “MANAGED REAL TIME APPLY”

Real Time Apply Architecture An up-to-date Physical/Logical Standby Database Oracle Net Transactions LGWR MRP/ LSP RFS Standby Redo Logs Online Redo Logs Real Time Apply Primary Database ARCH ARCH Archived Redo Logs Archived Redo Logs 7

SQL Apply: Zero Downtime Instantiation Logical standby database can now be created from an online backup of the primary database, without shutting down or quiescing the primary database No shutdown implies no downtime of production system No quiesce implies no wait on quiesce and no dependence on Resource Manager

Example – Ease of Use Switchover using Enterprise Manager is now literally two mouse clicks

Switched!

Agenda Data Guard Architecture & Features Data Guard Success Stories & Benefits

Data Guard Customers Transportation Telecom Utilities Financial/ Insurance Government Manufacturing Health Care Other Industries e-Commerce

Usage Examples Example B Example A Chicago Dallas Standby Site Primary Database Chicago Dallas Standby Maximize primary and standby resources Standby Site Primary Database Site A Site B Site C Standby Standby machine must be powerful enough to support multiple production instances after switchover / failover Example A

Data Guard Usage Examples Standby Site A Synchronous transport LAN attached Used to offload backups First choice for switchover candidate Primary Site Standby Site B Synchronous transport LAN attached Used to offload reporting Standby Site C Example C Asynchronous transport WAN attached Delayed apply Provides DR and data protection

What Fidelity Says “Data Guard automates disaster-recovery procedures and reduces Fidelity's exposure to data loss by an order of magnitude compared to previous approaches.” Jonathan Schapiro Vice President Data Architecture & Services Global Equity Trading & Technology

Q & Q U E S T I O N S A N S W E R S A