TWP DataGuard 10gR2[1]

8/13/2019 TWP DataGuard 10gR2[1]

1/34

Oracle Data Guard in

Oracle Database 10gRelease 2

Business Continuity for the Enterprise

An Oracle White PaperMay 2005


2/34

Oracle Data Guard

Business Continuity for the Enterprise

Executive Overview ...................................................................................................... 3

Impact Of Disasters ...................................................................................................... 3High Availability Challenges ................................................................................... 3

Oracle Data Guard ................................................................................................... 4

Oracle Database High Availability Solutions........................................................ 4

Overview Of Oracle Data Guard................................................................................ 5

What is Oracle Data Guard?................................................................................... 5

Data Guard Functionality........................................................................................ 6

New Features in Oracle Database 10gRelease 2 ................................................. 7

Benefits Of Data Guard .......................................................................................... 8

Data Guard Process Architecture ............................................................................... 9

Key Technology Components ................................................................................... 10

Data Guard Configuration .................................................................................... 10Protection Modes and Redo Transport ............................................................... 10

Maximum Protection......................................................................................... 11Maximum Availability ....................................................................................... 11Maximum Performance .................................................................................... 12Redo Transport Enhancements in Oracle Database 10g Release 2........... 12

Redo Apply And SQL Apply ................................................................................ 12Physical Standby Database Redo Apply...................................................... 13Logical Standby Database SQL Apply ........................................................15

Enterprise Manager & Data Guard Broker ........................................................18Management Enhancements in Oracle Database 10g Release 2 ................19

Role Transitions Switchover and Failover....................................................... 20Switchover...........................................................................................................20Types of Failover ...............................................................................................21Manual Failover.................................................................................................. 21Fast-Start Failover..............................................................................................22Restoring Old Primary As A New Standby................................................... 25Role Transition Events ..................................................................................... 25

Handling Communication Failures ...................................................................... 26

Protection from Data Corruptions Caused by Human Errors........................26

Rolling Database Upgrades ................................................................................... 27

Cascaded Redo Log Destinations......................................................................... 27

Data Guard And RAC ................................................................................................28

Maximum Availability Architecture ..........................................................................28Data Guard And Remote Mirroring Solutions .......................................................29

Data Guard Customers............................................................................................... 31

Conclusion ....................................................................................................................32

References .....................................................................................................................33

Oracle Data Guard Business Continuity for the Enterprise Page 2


3/34


4/34

Oracle Data Guard

Oracle Data Guard provides an extensive set of data protection and disasterrecovery (DR) capabilities to sustain business continuity when confronted withdisasters, human errors and corruptions that can adversely affect Oracledatabases.

This whitepaper provides an architectural and technology overview of the DataGuard feature of Oracle Database 10gRelease 2. For additional details on DataGuard, please refer to Oracle Data Guard documentation (ref. [1]).

Oracle Database High Availability Solutions

Data Guard is one component of Oracle Databases High Availability (HA)solution stack. The Oracle database comes with an integrated set of HAcapabilities that help organizations ensure business continuity by minimizing thevarious kinds of planned and unplanned downtime that can affect theirbusinesses. The following diagram shows the various HA features available withOracle Database 10g. For further details on each of these features, please referto [2] and [3].

System

Failures

Data

Failures

System

Changes

Data

Changes

Unplanned

Downtime

Planned

Downtime

Grid Clusters

Automatic Storage Management

Flashback

RMAN & Flash Recovery Area

H.A.R.D

Data Guard

Online Reconfiguration

Rolling Upgrades

Online Redefinition

The Oracle databasecomes with an integratedset of HA capabilitiesthat help organizationsminimize the variouskinds of planned andunplanned downtime

that can affect theirbusinesses.

Fig. 1: Integrated High Availability Features of Oracle Database 10g



5/34

OVERVIEW OF ORACLE DATA GUARD

What is Oracle Data Guard?

Oracle Data Guard is the management, monitoring, and automation softwareinfrastructure that creates, maintains, and monitors one or more standbydatabases to protect enterprise data from failures, disasters, errors, and datacorruptions.

Oracle Data Guardcreates, maintains, andmonitors one or morestandby databases toprotect enterprise datafrom failures, disasters,errors, and datacorruptions.

Data Guard maintains standby databases as transactionally consistent copies ofthe production database. These standby databases can be located at remotedisaster recovery sites thousands of miles away from the production data center,or they may be located in the same city, same campus, or even in the samebuilding. If the production database becomes unavailable because of a plannedor an unplanned outage, Data Guard can switch any standby database to theproduction role, thus minimizing the downtime associated with the outage, andpreventing any data loss.

Available as a feature of the Enterprise Edition of Oracle Database, Data Guardcan be used in combination with other Oracle High Availability solutions suchas Real Application Clusters (RAC) and Recovery Manager (RMAN), to providea high level of data protection and data availability that is unprecedented in theindustry.

The following diagram presents an overview of Data Guard.

Primary

SiteStandby

Site

Clients Clients

Data Changes

Data Guard BrokerPrimary

Database

Standby

Database

Fig. 2: Overview of Oracle Data Guard Architecture



6/34

Data Guard Functionality

A Data Guard configuration consists of aproduction database, also known as theprimary database, and up to nine standby database(s), which are transactionallyconsistent copies of the primary database. Data Guard maintains thistransactional consistency using redo data. As transactions occur in the primarydatabase, redo data is generated and written to the local redo log files. WithData Guard, this redo data is also transferred to the standby sites and applied to

the standby databases, keeping them synchronized with the primary database.Data Guard allows the administrator to choose whether this redo data is sentsynchronously or asynchronously to a standby site.

We are very impressed byData Guard 10g performance.We proved that Zero DataLoss, Disaster Recoveryrotection for an application

workload of 1 million businesstransactions/hour is achievablein our system and networkenvironment. ManoharMalayanur, Manager,Database SystemsManagement, Fannie Mae

The underlying technologies for standby databases are Data Guard Redo Apply(physical standby database), and Data Guard SQL Apply(logical standby database). Aphysical standby database has on-disk database structures that are identical tothe primary database on a block-for-block basis, and is updated using Oraclemedia recovery. A logical standby database is an independent database thatcontains the same data as the primary database. It is updated using SQLstatements, and has the advantage that it can be used concurrently for recovery

and for other tasks such as reporting and queries.

Data Guard enables role transitions between the primary database and a chosenstandby database, reducing overall downtime during planned outages andunplanned failures.

The primary and standby databases, as well as their various interactions, may bemanaged by using SQL*Plus. Data Guard also offers a distributed managementframework called the Data Guard Broker, which automates and centralizes thecreation, maintenance, and monitoring of a Data Guard configuration. Foreasier manageability, administrators may use either Oracle Enterprise Manageror the Brokers own specialized command-line interface (DGMGRL) to takeadvantage of the Brokers management capabilities.

The following diagram shows the Data Guard components.



7/34

NetworkBroker

ProductionDatabase

Logical StandbyDatabase Open for

Reports

SQLApply

TransformRedo to SQL

AdditionalIndexes & MVs

Physical StandbyDatabase

DIGITAL DATASTORAGE

DIGITAL DATASTORAGE

Backup

Redo Apply

Sync or AsyncRedo Shipping

Fig. 3: Data Guard Architectural Components

New Features in Oracle Database 10gRelease 2

Following is a summary of the new Data Guard features available in OracleDatabase 10gRelease 2. These are discussed in detail in subsequent sections.

Fast-Start Failover This capability allows Data Guard to automatically,and quickly fail over to a previously chosen, synchronized standby databasein the event of loss of the primary database, without requiring any manualsteps to invoke the failover, and without incurring any data loss. Following

a fast-start failover, once the old primary database is repaired, Data Guardautomatically reinstates it to be a standby database. This act restores highavailability to the Data Guard configuration.

Improved Redo Transmission Several enhancements have been madein the redo transmission architecture to make sure redo data generated onthe primary database can be transmitted as quickly and efficiently aspossible to the standby database(s).

Easy conversion of a physical standby database to a reportingdatabase A physical standby database can be activated as a primarydatabase, opened read/write for reporting purposes, and then flashed backto a point in the past to be easily converted back to a physical standby

database. At this point, Data Guard automatically synchronizes the standbydatabase with the primary database. This allows the physical standbydatabase to be utilized for read/write reporting and cloning activities.

Automatic deletion of applied archived redo log files in logicalstandby databases Archived logs, once they are applied on the logicalstandby database, are automatically deleted, reducing storage consumptionon the logical standby and improving Data Guard manageability. Physicalstandby databases have already had this functionality since Oracle Database10gRelease 1, with Flash Recovery Area [4].



8/34

Fine-grained monitoring of Data Guard configurations OracleEnterprise Manager has been enhanced to provide granular, up-to-datemonitoring of Data Guard configurations, so that administrators may makean informed and expedient decision regarding managing this configuration.

Benefits Of Data Guard

Data Guard offers the following benefits:

Disaster recovery and high availability Data Guard provides an efficient andcomprehensive disaster recovery and high availability solution. Automaticfailover and easy-to-manage switchover capabilities allow quick rolereversals between primary and standby databases, minimizing the downtimeof the primary database for planned and unplanned outages.

Data Guard automatesdisaster-recovery proceduresand reduces Fidelity'sexposure to data loss by anorder of magnitude compared

to previous approaches. onathan Schapiro, Vice

President, DataArchitecture & Services,Fidelity Investments

Complete data protection A standby database also provides an effectivesafeguard against data corruptions and user errors. Storage level physicalcorruptions on the primary database do not propagate to the standbydatabase. Similarly, logical corruptions or user errors that cause the primarydatabase to be permanently damaged can be resolved. Finally, the redo data

is validated at the time it is received at the standby database and furtherwhen applied to the standby database.

Efficient utilization of system resources A physical standby database can be usedfor backups and read-only reporting, thereby reducing the primary databaseworkload and saving valuable CPU and I/O cycles. In Oracle Database 10gRelease 2, a physical standby database can also be easily converted back andforth between being a physical standby database and an open read/writedatabase. A logical standby database allows its tables to be simultaneouslyavailable for read-only access while they are updated from the primarydatabase. A logical standby database also allows users to perform datamanipulation operations on tables that are not updated from the primarydatabase. Finally, additional indexes and materialized views can be created

in the logical standby database for better reporting performance.

Flexibility in data protection to balance availability against performance requirementsData Guard offers the Maximum Protection, Maximum Availability andMaximum Performance modes to help enterprises balance data protectionagainst system performance requirements.

Protection from communication failures If network connectivity is lost betweenthe primary and one or more standby databases, redo data cannot be sentfrom the primary to those standby databases. Once connectivity is re-established, the missing redo data is automatically detected by Data Guardand the necessary archive logs are automatically transmitted to the standbydatabases. The standby databases are resynchronized with the primary

database, with no manual intervention by the administrator. Centralized and simple management Data Guard Broker automates the

management and monitoring tasks across the multiple databases in a DataGuard configuration. Administrators may use either Oracle EnterpriseManager or the Brokers own specialized command-line interface(DGMGRL) to take advantage of this integrated management framework.

Integrated with Oracle database Data Guard is available as an integratedfeature of the Oracle Database (Enterprise Edition) at no extra cost.



9/34

DATA GUARD PROCESS ARCHITECTURE

As shown in the following figure, Data Guard uses several processes of theOracle database instance to achieve the automation necessary for disasterrecovery and high availability.

Online

Redo Logs

FAL

Oracle Net

Primary

Database

Transactions

Physical/Logical

Standby

Database

Backup /

Reports

LGWR RFS

Standby

Redo

Logs

Archived

Redo LogsARCH

MRP/ LSP

Transform Redo

to SQL forSQL Apply

Archived

Redo Logs

ARCH

LNS

sync

async

arch

Fig. 4: Data Guard Process Architecture in Oracle Database 10g Release 2

On the primary database, Data Guard uses the Log Writer (LGWR)process ormultipleArchiver (ARCH)processes to collect transaction redo data. In order toensure isolation from network disruptions, the Log Writer process usesspecialized background processes, called LogWriter Network Server (LNS)process, to synchronously or asynchronously transmit the redo data to thestandby database. The Archiver processes transmit the redo data to the standbydatabase directly. The primary database also has the Fetch Archive Log (FAL)processto provide a client-server mechanism for transmitting archived logs tothe standby following a communication loss between the primary andstandby(s), for automatic gap resolution and resynchronization.

On the standby database, Data Guard uses one or more Remote File Server (RFS)

processes to receive redo data from the primary database, theManaged RecoveryProcess (MRP)to apply redo data to the physical standby database, and the LogicalStandby Process (LSP)to apply SQL-translated redo data to the logical standbydatabase.

If the Data Guard Broker is enabled, Data Guard also uses the Data GuardBroker Monitor (DMON)process to manage and monitor the primary andstandby databases as a unified configuration.



10/34

KEY TECHNOLOGY COMPONENTS

Data Guard Configuration

A Data Guard configuration consists of one primary database and up to ninestandby databases. The primary and standby databases can run on a single nodeor in a RAC environment. The standby databases are connected to the primarydatabase over standard TCP/IP-based networks (e.g. a Local Area Network(LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN))using Oracle Net Services. There are no restrictions on where the databases arelocated, provided that they can communicate with each other. However, fordisaster recovery, it is recommended that the standby databases be hosted atsites that are geographically separated from the primary site.

Data Guard requires the operating system architecture on the primary andstandby systems to be the same. Thus if the primary database is running theLinux operating system on an Intel architecture, all its standby databases must

also be running Linux on Intel they cannot be Windows systems, for example.In addition, the same release of Oracle Database Enterprise Edition must beinstalled on the primary database and all standby databases, except duringrolling database upgrades using logical standby databases (ref. section RollingDatabase Upgrades for details of this capability).

Protection Modes and Redo Transport

Data Guard provides three high-level modes of data protection to balance cost,availability, performance, and transaction protection. These modes can be seteasily using any of the available management interfaces, e.g. using the followingis simple SQL statement on the primary database:

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE{PROTECTION | AVAILABILITY | PERFORMANCE};

To determine the appropriate data protection mode, enterprises need to weightheir business requirements for data protection against user demands for systemresponse time. The following table outlines the suitability of each mode from arisk of data loss perspective.

Protection

Mode

Risk of Data Loss In the Event of a

Disaster

Redo Transport

Mechanism

Maximum

Protection

Zero data loss Synchronous (LGWR

SYNC)

Maximum

Availability

Zero data loss Synchronous (LGWR

SYNC)

Maximum

Performance

Minimal data loss usually few seconds Asynchronous (LGWR

ASYNC)or ARCH

Data Guard has noinherent distancelimitation regardingwhere the standbydatabases may belocated with respect tothe primary database.



11/34

The following sections describe these protection modes in more detail.

Maximum Protection

Maximum Protection mode offers the highest level of data protection for the

primary database, ensuring a comprehensive zero-data loss disaster recoverysolution. When operating in Maximum Protection mode, redo records aresynchronously transmitted by the LGWR process (through the LNS process)from the primary database to the standby database(s), and a transaction is notcommitted on the primary database until it has been confirmed that thetransaction data is available on disk on at least one standby server. It is stronglyrecommended that this mode be configured with at least two standby databases.If the last participating standby database becomes unavailable, processing stopson the primary database. This ensures that no transactions are lost should theprimary database fail after it loses contact with all of its standby databases.

Because of the synchronous nature of redo transmission, this Maximum

Protection mode can potentially impact primary database response time. Thisimpact can be minimized by configuring a low latency network with sufficientbandwidth for peak transaction load. Stock exchanges, currency exchanges, andfinancial institutions are examples of businesses that may require this MaximumProtection mode.

Maximum Availability

Maximum Availability mode has the next higher level of data availability for theprimary database. As with the Maximum Protection mode, redo data issynchronously transmitted by LGWR from the primary database to the standby

database, and the transaction is not committed on the primary database until ithas been confirmed that the transaction data is available on disk on at least onestandby server. However, in this mode, unlike the Maximum Protection mode,if the last participating standby database becomes unavailable e.g. because ofnetwork connectivity problems, processing continues on the primary database.The standby database may temporarily fall behind compared to the primarydatabase, but when it is available again, the databases will automaticallysynchronize with no data loss, using accumulated archived logs on the primary.

Because of synchronous redo transmission, this protection mode can potentiallyimpact response time and throughput. This impact can be minimized byconfiguring a low latency network with sufficient bandwidth for peak

transaction load.

The Maximum Availability mode is suitable for businesses that want theassurance of zero data loss protection, but do not want the production databaseto be impacted by network/standby server failures. These businesses will acceptthe possibility of data loss should a second failure subsequently affect theproduction database before the initial network/standby failure is resolved.



12/34

Maximum Performance

Maximum Performance mode is the default protection mode. It offers slightlyless primary database data protection, but higher performance, than MaximumAvailability mode. In this mode, as the primary database processes transactions,redo data is asynchronously shipped to the standby database by the LGWRprocess. Alternatively, the Archiver process(es) (ARCH) on the primarydatabase may also be configured to transmit the redo data in this mode. In any

case, the commit operation of the primary database does not wait for thestandby to acknowledge receipt before completing the write on the primary. Ifany standby destination becomes unavailable, processing continues on theprimary database and there is little or no effect on performance.

In the case of a failure of the primary database, redo data which had not yetbeen sent to the standby database is lost. However, if the network has sufficientthroughput to keep up with peaks in redo traffic and the LGWR process is usedto transmit redo to the standby server, the number of lost transactions will bevery small or zero.

The Maximum Performance mode should be used when availability andperformance on the primary database are more important than the risk of losinga small amount of data. This mode is also suitable for Data Guard deploymentsover a WAN, where the inherent latencies of the network may limit thesuitability of synchronous redo transmission.

Redo Transport Enhancements in Oracle Database 10g Release 2

There have been some key enhancements in the redo transport architecture inOracle Database 10gRelease 2. During asynchronous redo transmission usingthe Log Writer process (LGWR ASYNC), the network server (LNSn) process

serving each standby database transmits redo data out of the online redo logfiles on the primary database, instead of using an ASYNC buffer, as is the casein Oracle Database 10gRelease 1 or earlier. This allows asynchronous redotransmission using LGWR not to be constrained by the size of the ASYNCbuffer. The maximum network transmission size is also increased from 1 MB to10 MB thereby greatly improving network utilization under heavy load.

For ARCH-based transport, it is now possible to have multiple Archiverprocesses transmit redo data in parallel from a single archived redo log file to astandby destination. This is specified through the new MAX_CONNECTIONSattribute on the LOG_ARCHIVE_DEST_nparameter. The allowable maximumnumber of ARCH processes (specified through the

LOG_ARCHIVE_MAX_PROCESSESinitialization parameter) has also beenincreased from 10 to 30. These enhancements enable the expedient transfer ofarchived redo data to standby destinations during high peak activity, e.g. duringbatch uploads.

Redo Apply And SQL Apply

A standby database is initially created from a backup copy of the primary



13/34

database. Once created, Data Guard automatically maintains the standbydatabase as a transactionally consistent copy of the primary database bytransmitting primary database redo data to the standby system and thenapplying the redo data to the standby database.

Data Guard provides two methods to apply this redo data to the standbydatabase and keep it transactionally consistent with the primary, and these

methods correspond to the two types of standby databases supported by DataGuard:

Redo Apply, used for physical standby databases

SQL Apply, used for logical standby databases

Note that as Fig. 4 indicates, there is no distinction between these two types ofstandby databases as far as redo data transmission from the primary isconcerned. Once this redo data reaches the standby server, it is how the redodata is applied on the standby database that distinguishes these two types ofstandby databases.

Physical Standby Database Redo Apply

A physical standby database is kept synchronized with the primary database byapplying the redo data received from the primary using Oracle media recovery.It is physically identical to the primary database on a block-for-block basis, andthus, the database schemas, including indexes, are the same.

How Redo Apply Works

Data Guard Redo Apply uses a specialized process, called the ManagedRecovery Process (MRP). MRP reads incoming redo data directly from Standby

Redo Logs(SRLs) as they are written by the RFS process, and then applies themto the physical standby database. MRP is started on the physical standbydatabase by mounting the database and using the following command:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USINGCURRENT LOGFILE DISCONNECT FROM SESSION;

MRP may also transparently switch to reading from a standby archived log ifthe SRL is archived before MRP could complete reading of the SRL (a situationwhich may occur when the primary database has a very high redo generationrate).

MRP can be run in parallel for the best performance of Data Guard RedoApply. In releases prior to Oracle Database 10g, this required the use of aPARALLELclause in the above RECOVER MANAGED STANDBYDATABASEcommand. In Oracle Database 10g, MRP can automaticallydetermine the optimal number of parallel recovery processes at the time it starts(without requiring the PARALLELclause), and this number is based on thenumber of CPUs available on the standby server [5].



14/34

The physical standby database can be opened read-only, and queries can be runagainst the physical standby database at that time. The physical standby databasecannot run recovery at the same time it is opened read-only. Redo data that areshipped to the standby while it is opened read-only are accumulated at thestandby site, and are not applied. However, recovery operations can be resumedon the physical standby at any time, and the accumulated redo data willautomatically get applied. This allows the physical standby database to run in a

sequence that could involve running in recovery for a while, then being openedread-only to run reports, and then returning to running recovery to applyoutstanding redo data.

The physical standbydatabase can be openedread-only, and queriescan be run against thephysical standbydatabase at that time.

To open the physical standby read-only, recovery needs to be canceled on thestandby using the following command:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

and then the database can be opened read-only:

ALTER DATABASE OPEN;

To change the standby database back to being a physical standby databaseperforming redo apply, active user sessions need to be terminated and MRPrestarted with the ALTER DATABASE RECOVER MANAGED STANDBYDATABASE command.

Redo Apply Enhancements in Oracle Database 10g Release 2

In Oracle Database 10gRelease 2, using a combination of Data Guard andFlashback Database, a physical standby database can be opened temporarily inread/write mode for development, reporting, or testing purposes, and then

flashed back to a point in the past to be reverted back to a physical standbydatabase. After the database is flashed back, Data Guard automaticallysynchronizes the standby database with the primary database, without the needto re-create the physical standby database from a backup copy of the primarydatabase.

Through SQL*Plus, the commands do this are as simple as the following:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> CREATE RESTORE POINT t1 GUARANTEE FLASHBACK DATABASE;

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

SQL> FLASHBACK DATABASE TO RESTORE POINT t1;

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Note that during the time that the physical standby database is openedread/write, it will not receive or apply redo data from the primary database andcannot provide disaster protection. To ensure continuous disaster protection inthis case, a second standby database is required.



15/34

Benefits of Physical Standby

A physical standby database provides the following benefits:

Disaster recovery and high availability A physical standby database enables arobust and efficient disaster recovery and high availability solution. Easy-to-

manage switchover and failover capabilities allow simple role reversalsbetween primary and physical standby databases, minimizing the downtimeof the primary database for planned and unplanned outages.The things that impress me the

most about Data Guard are itsmanageability, reliability, andease of use. It is amazing howeasily we could implement asolid Disaster Recovery / High

vailability solution withOracle Data Guard withoutrequiring additional resources tosupport it. Darl Kuhn,Staff Engineer, Database

Services , Sun ServicesGlobal Engineering, SunMicrosystems

Data protection Using a physical standby database, Data Guard can ensureno data loss, even in the face of unforeseen disasters. A physical standbydatabase supports all datatypes, and DDL and DML operations that theprimary can support. It also provides a safeguard against data corruptionsand user errors. Storage level physical corruptions on the primary databasedo not propagate to the standby database. Similarly, logical corruptions oruser errors that cause the primary database to be permanently damaged canbe resolved. Finally, the redo data is validated when it is received at andapplied to the standby database.

Reduction in primary database workload The physical standby database can beopened read-only for reporting and queries, and easily converted back-and-forth between being a read-write active database and a physical standbydatabase. Besides, using Recovery Manager (RMAN), the physical standbydatabase can be utilized to create backups for the production database,thereby saving valuable CPU and I/O cycles from the production system.RMAN can perform this backup while the physical standby database isperforming recovery, or when it is opened read-only.

Performance The redo apply technology used by the physical standbydatabase applies changes using low-level recovery mechanisms, whichbypass all SQL level code layers and therefore is the most efficientmechanism for applying changes. This makes the redo apply technology a

highly efficient mechanism to maintain transactionally consistent copies ofthe primary database.

Logical Standby Database SQL Apply

A logical standby database contains the same logical information as the primarydatabase, although the physical organization and structure of the data can bedifferent. The SQL Apply technology keeps the logical standby databasesynchronized with the primary database by transforming the redo data receivedfrom the primary database into SQL statements and then executing the SQLstatements on the standby database. This makes it possible for the logical

standby database to be accessed for queries and reporting purposes at the sametime the SQL is being applied to it.

Because the logical standby database is updated using SQL statements, itremains open in read-write mode, and the tables that are being updated fromthe primary database can be used simultaneously for other tasks such asreporting, summations, and queries. These tasks can also be optimized bycreating additional indexes and materialized views on the maintained tables. Alogical standby database can host multiple database schemas, and users can



16/34

perform normal data manipulation operations on tables in schemas that are notupdated from the primary database.

A logical standby database has some restrictions on datatypes, types of tables,and types of DDL and DML operations. Please refer to [1] for a list of theseunsupported datatypes and storage attributes.

How SQL Apply Works

SQL Apply uses a collection of parallel execution servers and backgroundprocesses that perform the task of applying changes from the primary databaseto the logical standby database. The following diagram shows the flow ofinformation and the role that each process performs.

Redo Data

from

Primary

Database

Reader Preparer

Redo

RecordsLCR

LCR

:

Shared

Pool

Builder

Analyzer

Transaction

groups

Coordinator

Transactions

sorted in

dependency order

ApplierDatafiles

Log Mining

Apply Processing

Logical Change Records not

grouped into transactions

Transactions

to be applied

Fig. 5: Data Guard SQL Apply Process Architecture

Following is a summary of the functionalities of each of the processes:

The Readerprocess reads incoming redo records from standby redologs, or from standby archive logs.

The Preparerprocesses convert the block changes into table changes, or

logical change records (LCRs). At this point, the LCRs do not representspecific transactions.

The Builderprocess assembles completed transactions from theindividual LCRs.

TheAnalyzerprocess examines the completed transactions, identifyingdependencies between the different transactions.

The Coordinator process (also known as the Logical Standby Process, orLSP), assigns transactions to the apply processes, monitors



17/34

dependencies between transactions, and authorizes the commit ofchanges to the logical standby database.

TheApplierprocesses apply the LCRs for the assigned transaction tothe database and commit the transactions when instructed to do so bythe Coordinator.

These various SQL Apply processes can be started by entering this simple SQLcommand on the logical standby database:

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Since the logical standby database can be open read/write while SQL Apply isrunning, synchronous redo transport to the logical standby and application ofredo data directly from SRLs makes it possible to use the logical standbydatabase as a real-time reporting solution. This demonstrates yet another wayData Guard may be leveraged for additional business use beyond disasterprotection.

Automatic Archived Log Deletion in Oracle Database 10g Release 2

The logical standby database in Oracle Database 10gRelease 2 automaticallydeletes archived redo log files that have been applied by SQL Apply. Thisenhances space management on the logical standby database.

The DBA_LOGMNR_PURGED_LOGview displays the archived redo log files thatare no longer needed, and hence are candidates for deletion. If administratorswant control over this deletion process, they may override the default auto-deletion behavior by setting the logical standby parameter LOG_AUTO_DELETEto FALSE.

A logical standby

database can remainopen at the same time itstables are updated fromthe primary database,and those tablessimultaneously availablefor read access.

are

Benefits of Logical Standby

A logical standby database provides similar disaster recovery, high availability,and data protection benefits as a physical standby database. It also provides thefollowing specialized benefits:

Efficient use of standby hardware resources A logical standby database can beused for other business purposes in addition to disaster recoveryrequirements. It can host additional database schemas beyond the ones thatare protected in a Data Guard configuration, and users can perform DDLor DML operations on those schemas any time. Because the logical standby

tables that are protected by Data Guard can be stored in a different physicallayout than on the primary database, additional indexes and materializedviews can be created to improve query performance and suit specificbusiness requirements.

Reduction in primary database workload A logical standby database can remainopen at the same time its tables are updated from the primary database, andthose tables are simultaneously available for read access. This enables thelogical standby database to be used concurrently for data protection andreporting, thereby off-loading the primary database from those reporting



18/34

and query tasks, and saving valuable CPU and I/O cycles.

Enterprise Manager & Data Guard Broker

Data Guard Broker is a distributed management framework that automates andcentralizes the creation, maintenance, and monitoring of Data Guardconfigurations. All management operations can be performed either throughOracle Enterprise Manager, which uses the Broker, or through the Brokersspecialized command-line interface (DGMGRL). The following screenshotshows the Data Guard home page of the Enterprise Manager.

Fig. 6: Data Guard Configuration through Oracle Enterprise Manager

The following list describes some of the operations that the Broker automatesand simplifies:

Creating and enabling Data Guard configurations, which include a primarydatabase and up to nine standby (physical or logical) databases all or a mixof these databases may be RAC clusters.

Managing an entire Data Guard configuration from any site in the

configuration.

Implementing switchover or failover operations (including Fast-StartFailover) that involve complex role changes across all systems in theconfiguration.

Monitoring apply rates, capturing diagnostic information, and detectingproblems quickly with centralized monitoring, and event notification.



19/34

The Broker's easy-to-use interfaces and centralized management andmonitoring of the Data Guard configuration make Data Guard an enhancedhigh availability and data protection solution for the enterprise.

Management Enhancements in Oracle Database 10g Release 2

In Oracle Database 10gRelease 2, Data Guard offers various enhanced views tomonitor the run-time performance of the Data Guard configuration in agranular fashion. These can be accessed through SQL*Plus, DGMGRL orEnterprise Manager.

Enterprise Manager offers the additional benefit of providing historical trendanalysis on the Data Guard metrics that it monitors for example, how themetrics performance has been in the last 24 hrs, or last 5 days, etc. Also,through Enterprise Manager, it is possible to set up notification-alarms suchthat administrators may be notified in case the metric crosses the configuredthreshold value.

Some of the Data Guard metrics monitored by Enterprise Manager are:

Estimated Failover Time The approximate number of seconds it wouldrequire to failover to this standby database.

Apply Lag Shows how far the standby is behind the primary.

Redo Apply Rate The rate at which redo is applied on the standby.

Redo Generation Rate The rate at which redo is generated on theprimary.

Transport Lag The approximate number of seconds of redo not yetavailable on this standby database. This may be because the redo has not

yet been shipped or there may be a gap. Data Guard Status Shows the status of each database in the Data Guard

configuration.

Fast-Start Failover Occurred When fast-start failover is enabled, thismetric will generate a critical alert on the new primary database (oldstandby) if a fast-start failover occurs (ref. section Fast-Start Failover fordetails on fast-start failover).

Fast-Start Failover Time When fast-start failover is enabled, this metricwill generate a critical alert on the new primary database (old standby) iffast-start failover occurs, indicating the time stamp of the occurrence.



20/34

Role Transitions Switchover and Failover

Data Guard offers two easy-to-use methods to handle planned and unplannedoutages of the production site. The goal of both these methods is to transition adesignated standby database to a production role as quickly as possible. Thesemethods are called switchoverandfailover, corresponding respectively to howplanned and unplanned outages are handled.Data Guard offers

two easy-to-usemethods to handleplanned andunplanned outages ofthe production site.

Switchover

A switchover is typically used to reduce primary database downtime duringplanned outages, such as operating system or hardware upgrades, or rollingupgrades of the Oracle database software and patch sets. A switchover may alsobe used by a business to test disaster recovery preparedness.

A switchover operation requires all user sessions to be disconnected from theprimary database. Following that, the primary database is transitioned to thestandby role, after which the standby database is transitioned to the primary

role.

A switchover is initiated by the administrator using the Oracle EnterpriseManager GUI interface, the Data Guard Brokers command line interface, ordirectly through SQL.

For example the following single Data Guard Broker CLI (DGMGRL)command initiates and completes the switchover to the standby databaseStandbyChicago:

DGMGRL> SWITCHOVER TO StandbyChicago;

As seen above, the administrator needs to specify a target standby database atthe time of the switchover. Once initiated, Data Guard automates the actualrole transition processes. No data is lost in the process.

If the switchover target is a logical standby database, a switchover operationdoes not require a restart of the old or new primary databases following aswitchover. Also, there is no need to shut down and restart any other logicalstandby databases that are in the Data Guard configuration they will continueto function normally after a switchover completes. All existing physical standbydatabases, however, are rendered unable to participate in the Data Guardconfiguration after the switchover, and must be recreated from a backup of thenew primary database, in order to serve as its physical standby.

If the switchover target is a physical standby database, a switchover operationrequires the old primary database to be restarted and mounted (as a newstandby) following the switchover. In Oracle Database 10gRelease 2, the oldstandby database does not need to be restarted if it has never been open read-only while being a physical standby. Otherwise, it needs to be shutdown and



21/34

restarted to be opened read/write as the new primary database. There is noneed to shut down and restart other standby databases in the configuration whether physical or logical.

At times, the term switchbackmay also be used within the scope of Data Guardrole management. A switchback operation is simply a subsequent switchoveroperation to return databases to their original roles.

A switchbackoperation is simply asubsequentswitchover operationto return databases totheir original roles.

Types of Failover

Failover is the operation of bringing one of the standby databases online as thenew primary database when an unplanned catastrophic failure occurs on theprimary database, and there is no possibility of recovering the primary databasein a timely manner.

For Data Guard in Oracle Database 10gRelease 2, there are two kinds offailover operations manual failover, andfast-start failover. A manual failover isinitiated by the administrator using the Oracle Enterprise Manager GUIinterface, the Data Guard Brokers command line interface, or directly throughSQL*Plus. With fast-start failover, Data Guard automatically fails over to apreviously designated standby database when the primary database isunavailable, provided there is no a chance of data loss at the time of thefailover. Fast-start failover allows the administrator to increase availability withno need for manual intervention, thereby reducing management costs as well asdowntime. Manual failover gives administrators more control over the failoverprocess for example, an administrator may want to invoke a manual failovereven where there is a chance of a data loss.

Manual Failover

A manual failover operation is initiated on the standby database that will assumethe primary role. For example the following single Data Guard Broker CLI(DGMGRL) command initiates and completes the failover to the standbydatabase StandbyChicago:

DGMGRL> FAILOVER TO StandbyChicago;

If the failover target is a logical standby database, a failover operation does notrequire a restart of the new primary database following a failover. Other logicalstandby databases in the Data Guard configuration will have to flashed back

and synchronized, or recreated from a backup of the new primary. Otherphysical standby databases in that configuration will no longer be compatible,and hence they need to be recreated from a backup of the new primary.

If the failover target is a physical standby database, this standby database (i.e.the new primary database) does not need to be restarted if it has never beenopen read-only since the last time it was started. Otherwise, it needs to beshutdown and restarted to be opened read/write as the new primary database.There is no need to shut down and restart other standby databases in the



22/34

configuration whether physical or logical, provided they were nottransactionally ahead of the target standby at the time of the failover.Otherwise they will have to flashed back and synchronized, or recreated from abackup of the new primary.

The manual failover operation ensures zero data loss if Data Guard was beingrun in the Maximum Protection mode or Maximum Availability mode and the

target standby database was synchronized at the time of the failover. InMaximum Performance mode, if there were still some redo data in the primarydatabase that had not yet been sent to the standby at the time of failover thatdata may be lost.

The following figure shows the result of a failover operation from a primarydatabase in San Francisco to a physical standby database in Boston.

Fig. 7: Failover to a Standby Database

Fast-Start Failover

Fast-start failover allows Data Guard to automatically fail over to a previouslychosen, synchronized standby database in the event of loss of the primarydatabase, without requiring any manual steps to invoke the failover. Further,upon return of the failed primary, it will automatically be reinstated into theconfiguration as a standby of the new primary database. Fast-start failover canbe used only in a Data Guard Broker configuration and can be configured onlythrough DGMGRL or Enterprise Manager.

Fast-start failoverautomatically fails

over to a designatedstandby databasewithout requiring anymanual intervention.

The fast-start failover configuration is monitored by a separate Observerprocess, which is a lightweight process integrated in the DGMGRL client-sidecomponent. It should be run on a different computer from the primary or



23/34

standby databases. It continuously monitors the fast-start failover environmentto ensure the primary database is available. If both the Observer and thestandby database lose connectivity to the primary database, the Observerattempts to reconnect to the primary database for a configurable amount oftime before initiating a fast-start failover.

Prerequisites & Administration

Fast-start failover requires Data Guard Broker to be enabled for theconfiguration. It also requires Flashback Database to be enabled and FlashRecovery Area to be configured in the primary and the designated standbydatabase. Configuring Flashback Database and Flash Recovery Area isrecommended for other standby databases in the configuration as well. It alsorequires Data Guard protection mode to be Maximum Availability, therebyensuring that a failover can occur without any data loss. The Observer processneeds network connectivity between the Observer machine and primary andstandby servers to be able to monitor the configuration.

To enable fast-start failover, a standby database needs to be designated as thetarget for the failover. This can be done using the Broker property,FastStartFailoverTarget, or through Enterprise Manager. Secondly,administrators need to configure how long the Observer should try toreconnect to the current primary database before initiating a fast-start failover.This can be done specifying the time (in seconds) through theFastStartFailoverThresholdBroker property, or through EnterpriseManager. Finally, fast-start failover needs to be enabled for the configuration,which can be done through Enterprise Manager, or through DGMGRL:

DGMGRL> ENABLE FAST_START FAILOVER;

The Observer process can now be started at the Observer machine, either usingEnterprise Manager, or with the simple DGMGRL command, and it will startmonitoring the fast-start failover configuration:

DGMGRL> START OBSERVER;

The following diagram shows the relationships between the primary database,target standby database, and the Observer during fast-start failover:



24/34

Fig. 8: Interaction among the Observer, Primary Database & Standby Database

Before Fast-Start Failover:Data Guard is operating in a steady state, with theprimary database transmitting redo data to the target standby database and

the Observer monitoring the state of the entire configuration. FastStartFailover Ensues:Disaster strikes the primary database and its

network connections to both the Observer and the target standby databaseare lost. Upon detecting the break in communication, the Observerattempts to reestablish a connection with the primary database for theamount of time defined by the FastStartFailoverThresholdproperty before initiating a fast-start failover. If the Observer is unable toregain a connection to the primary database within the specified time, andthe target standby database is ready for fast-start failover, then fast-startfailover ensues.

After Fast-Start Failover:The fast-start failover has completed and the targetstandby database is running in the primary database role. After the former

primary database has been repaired, the Observer reestablishes itsconnection to that database and reinstates it as a new standby database. Thenew primary database starts transmitting redo data to the new standbydatabase.

The elegantarchitecture of fast-start failover makes itan excellent candidateto be used in lights-outhigh availabilitysituations where dataprotection is alsoimportant.

The status of the fast-start failover configuration can be monitored any timethrough Enterprise Manager or through the FS_FAILOVER_STATUScolumnin the V$DATABASEview. For example, if the primary database, while inMaximum Availability mode, gets disconnected from the standby database butremains connected to the Observer, the standby will no longer be synchronizedwith the primary. This will be reflected by the value UNSYNCHRONIZED inthe FS_FAILOVER_STATUScolumn. Since fast-start failover always ensures nodata loss, fast-start failover will not be possible in this case and a manualfailover will be required.

Fast-start failover has been designed to ensure that out of the three fast-startfailover members the primary, the standby and the Observer, at least twomembers agree to major state transitions, thus avoiding conditions such as split-brain scenarios in which there may be two divergent primary databases servingproduction workload. The simple, yet elegant architecture of fast-start failover



25/34


26/34

database that is operating in the new primary database role on behalf of the oldprimary. This is a FAN event to notify OCI clients, who are subscribers of thisevent that the database that used to be operating in the primary role is nowdown or unavailable. This allows applications to connect to the new primarysoon after getting the notification instead of having to wait for a TCP timeoutperiod, as would be the case if it were a site failure.

Handling Communication Failures

Data Guard can smoothly handle network connectivity problems thattemporarily disconnect the standby (physical or logical) database from theprimary database. The exact behavior is dictated by the Data Guard protectionmode.

When the standby database becomes unavailable and this standby database isthe last available standby in the Maximum Protection mode, the primarydatabase will be shut down. For all other cases, transactions are captured locallyat the primary database. When connectivity to the standby is re-established, the

accumulated archive logs are automatically shipped and applied to the standby,until the standby has resynchronized with the primary. This process does notrequire any administrative intervention. Oracle recommends that networkcapacity be sufficient to handle such resynchronizations if network outages arecommon in the vicinity of the primary site.

Protection from Data Corruptions Caused by HumanErrors

When a primary database is open and active, and transactions are in progress,redo data is generated and transmitted to standby sites. Considering that humanerror is the leading cause of system downtime, it may be possible that this redo

data contains critical logical user-errors, such as dropping of an important table,or other logical data corruptions, and this might have already logically corruptedthe primary database.

Data Guard provides several easy-to-use means to avoid such user errors. Theadministrator may decide to use the Flashback Databasefeature of OracleDatabase 10gon both the primary and standby databases to quickly revert thedatabases to an earlier point-in-time to back out such user errors. Alternatively,if the administrator decides to failover to a standby database, but those user-errors were already applied to the standby database, the administrator maysimply flashback the standby database to a safe point in time (assuming theflashback functionality was already enabled on the standby database). Finally,the administrator has the added option to delay the application of redo data onthose standby databases by a configurable amount of time, which provides awindow of protection from such user errors or corruptions.

Irrespective of the option chosen, the apply process on the standby databasealways revalidates the log records to prevent application of physical redo datacorruptions on the standby database.



27/34

Rolling Database Upgrades

Oracle Database 10gsupports database software upgrades for major release andpatchset upgrades (from Oracle Database 10gonwards) in a rolling fashion with near zero database downtime, by using Data Guard SQL Apply. The stepsinvolve upgrading the logical standby database to the next release, running in a

mixed mode to test and validate the upgrade, doing a role reversal by switchingover to the upgraded database, and then finally upgrading the old primarydatabase. While running in a mixed mode for testing purposes, the upgrade canbe aborted and the software downgraded, without data loss. For additional dataprotection during these steps, a second standby database may be used.

The following diagram shows the sequence of events in a rolling upgradeprocess.

Major

Release

Upgrades

Patch Set

Upgrades

Cluster

Software &

Hardware

Upgrades

Initial SQL Apply Config

ClientsRedo

Version X Version X

1

BA

Switchover to B, upgrade A

Redo

4

Upgrade

X+1X+1

BA

Run in mixed mode to test

Redo

3

X+1X

A B

Upgrade node B to X+1

Upgrade

Logs

Queue

X

2

X+1

A B

Data Guard supportsdatabase softwareupgrades for majorrelease and patchsetupgrades in a rollingfashion with near zerodatabase downtime

Fig. 9: Rolling Database Upgrades Using SQL Apply

By supporting rolling upgrades with minimal downtimes, Data Guard reducesthe large maintenance windows typical of many administrative tasks, andenables the 24x7 operation of the business.

Cascaded Redo Log Destinations

Data Guard provides many flexible configuration options. Using CascadedRedo Log Destinations, a standby database receives its redo data from anotherstandby database and not from the original primary database. Since the primarydatabase sends redo data to only a subset of the standby databases, this featurereduces the load on the primary system, and also reduces network traffic anduse of valuable network resources at the primary site. This is also valuable in



28/34

cases where multiple standby databases are deployed, to serve a variety ofdisaster recovery and reporting requirements.

DATA GUARD AND RAC

Data Guard and RAC are complementary to each other. RAC addresses systemor instance failures. It provides rapid and automatic recovery from failures thatdo not affect data such as node failures, or instance crashes. It also providesincreased scalability for an application. Data Guard, on the other hand, providesdata protection through the use of transactionally consistent primary andstandby databases, which neither share disks nor run in lock step. This enablesrecovery from site disasters or data corruptions.

Data Guard is also natively integrated with RAC e.g., some or all of theprimary/standby (physical or logical) databases can be RAC databases, and theycan be managed using Enterprise Manager or the Brokers command-lineinterface, or directly using SQL. Customers should use a combination of DataGuard and RAC to maximize both high availability and disaster recovery

benefits.

MAXIMUM AVAILABILITY ARCHITECTURE

As more system capabilities become available, IT managers, architects andadministrators often find it difficult to integrate a suitable set of features tobuild one unified high availability (HA) solution that fits all of their businessrequirements. Oracle Maximum Availability Architecture (MAA) is Oracle'sbest-practices blueprint based on proven Oracle high availability technologiesand recommendations. The goal of MAA is to remove the complexity indesigning the optimal high availability architecture, and maximize systemsavailability.

Oracle Maximum AvailabilityArchitecture is based onproven Oracle highavailability technologies andreal-world customerdeployment experiences, withthe goal of removing thecomplexity in designing theoptimal high availabilityarchitecture, and maximizingsystems availability.

MAA provides the following benefits:

MAA reduces the implementation costs for a highly available Oracle systemby providing detailed configuration guidelines. The results of performance-impact studies for different configurations are highlighted to ensure that thechosen highly available architecture can perform and scale according tobusiness needs.

MAA provides best practices and recovery steps to eliminate or minimizedowntime that could occur because of scheduled and unscheduled outagessuch as human errors, system faults and crashes, maintenance, data failures,corruptions, and disasters.

MAA gives the ability to control the length of time to recover from anoutage and the amount of acceptable data loss under disaster conditionsthus allowing mean time to recovery (MTTR) to be tailored to specificbusiness requirements.

Data Guard is an essential component of MAA, and the MAA guidelinesinclude best practice recommendations (ref. [7]) on various Data Guard



29/34


30/34

Remote mirroring can be very useful for non-database files, but fordatabase data the combination of better protection and lower costprovide compelling reasons to use Data Guard. An internal analysis ofOracle's corporate e-mail systems, as shown in the following graph,demonstrated that 7 times more data was transmitted over the network and27 times more I/O operations were performed using a remote mirroring

solution, compared to using Data Guard.

0 5 10 15 20 25 30

Network I/Os

Network

Bandwidth

Data Guard

Remote Mirroring

Fig. 10: Network Performance: Data Guard vs. Remote Mirroring

Better suited for WANs

Remote-mirroring solutions based on storage systems often have a distancelimitation due to the underlying communication technology (Fibre,

ESCON) used by the storage systems. This distance can be extended byusing specialized devices from third party vendors. These devices convertESCON/fibre to the appropriate IP, ATM or SONET networks. Theproblem is that with each such device, latency is introduced in the system,impacting the production database performance, and making such aconfiguration unsuitable for synchronous transport necessary for the zerodata loss capability. This problem may be mitigated by introducingintermediate storage boxes in the communication path, but that only addsto the overall cost. The other solution is to use variations of synchronoustransmission however, depending on the remote mirroring solution,anything other than synchronous transmission of data may not preservewrite-ordering across all mirrored volumes that the database resides on.

This means such configurations cannot guarantee data consistency at alltimes, making them unsuitable as a data protection / disaster recoverysolution for OLTP data.

Since Data Guard transmits only redo data to the standby sites, using astandard IP network, and preserves transactional consistency across all theprotection modes (i.e. whether using synchronous or asynchronous modeof transport), and does not need expensive interim storage boxes, it is amuch better DR and data protection solution for a WAN.



31/34


32/34

These success stories about Data Guard in action at some of the best names invarious industries around the world is a tribute to Data Guards comprehensivecapabilities in the area of business continuity.

CONCLUSION

Oracle Data Guard is a comprehensive data protection, disaster recovery andhigh availability solution for the enterprise. It offers a flexible and easy-to-manage framework that addresses both planned and unplanned outages.Physical and logical standby databases complement each other and can bemaintained simultaneously, providing high-value data protection, whileoffloading overhead from primary databases. The various data protectionmodes provide flexibility to adapt to various protection, performance andinfrastructure requirements. The Data Guard Broker in combination withOracle Enterprise Manager provides an easy-to-use configuration andmanagement framework.

We needed to consider thesafe-keeping of our data, butwe also needed to look at cost.Oracle Data Guard provideseverything for a highavailability solution at a lowercost than other alternatives.Ann Collins,Technical DireFirst American Real

Estate Sol

ctor,

utions A modern global enterprise cannot provide mission-critical service to itscustomers without the kind of technology discussed in this paper. It has to becomplete, integrated, easy-to-manage, serve multiple purposes and protect allenterprise data. At the same time, such data protection and disaster recoverytechnology should not be expensive, nor unduly impact performance, andshould enable businesses to extract additional value out of their DRinvestments. Oracle Data Guard is the only solution available today that meetsall these needs.



33/34


34/34

Oracle Data Guard in Oracle Database 10gRelease 2 Business Continuity for the Enterprise

May 2005

Author: Ashish RayContributing Author: Joseph Meeks

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

www.oracle.com

Copyright 2005, Oracle. All rights reserved.

This document is provided for information purposes only and the

contents hereof are subject to change without notice.This document is not warranted to be error-free, nor subject to any

other warranties or conditions, whether expressed orally or implied

in law, including implied warranties and conditions of merchantability

or fitness for a particular purpose. We specifically disclaim any

liability with respect to this document and no contractual obligations

are formed either directly or indirectly by this document. This document

may not be reproduced or transmitted in any form or by any means,

electronic or mechanical, for any purpose, without our prior written permission.

Oracle, JD Edwards, and PeopleSoft are registered trademarks of

Oracle Corporation and/or its affiliates. Other names may be trademarks

f th i ti

TWP DataGuard 10gR2[1]

Documents

Transcript of TWP DataGuard 10gR2[1]