dg_110wp

8/13/2019 dg_110wp

1/20

TECHNOLOGY Oracle 10g Database

Oracle OpenWorld 2005, Paper #S110 / Page 1

IIMMPPLLEEMMEENNTTIINNGGOORRAACCLLEE1100GGDDAATTAAGGUUAARRDDFFOORRHHIIGGHHEERRAAVVAAIILLAABBIILLIITTYYIIMMPPLLEEMMEENNTTIINNGGOORRAACCLLEE1100GGDDAA

Daniel T. Liu, Senior DBA

First American Real Estate Solutions

INTRODUCTION

One of the biggest responsibilities for a database administrator is provide high availability and reduce unplanneddowntime for a database. However, this has become a major challenge as our database size increased so dramaticallyover the years and our critical business information system requires 24x7 uptime. In an unplanned downtime when aterabyte database was corrupted, it may take hours, even days to restore such a database. To minimize downtime andavoid data loss, we need a standby database that can take the role of the primary database in a timely fashion.

Oracle 10g Data Guard technology meets such a challenge. Oracle version 7.3 was the first release to support standbydatabase, however, the process of transferring redo logs was manual. The standby database has no other use until ittakes the role of the primary database. Oracle8i introduced the concept of automatic shipping and application of redolog files from the primary site to the standby site. It also allows the standby database to be opened for read only whilethe recovering process is stopped. Oracle9i release 1 introduces the new concept of protection mode, preventing theprimary and the standby database from diverging. It also introduces Data Guard broker, an interface to manage theData guard environment. Oracle9i release 2 introduces the new concept of logical standby database. Oracle 10gintroduces many new enhancements: Real Time Apply, Integration with Flashback Database, Zero DowntimeInstantiation, Rolling Upgrades, Support for New Data Types, and RAC Support.

This paper provides an overview of Oracle 10g Data Guard technology. It offers an introduction to the basicconcepts and architectures of Data Guard. It discusses the selection of several of data protection mode, steps to setupa Data Guard environment, and steps to perform failover and switchover operations. It also provides tips for

implementing Data Guard.

GENERAL CONCEPTS ANDARCHITECTURE

Oracle 10g Data Guard is the management, monitoring, and automation software that work with a productiondatabase and one or more standby databases to protect data against failures, errors, and corruption that mightotherwise destroy your database.

DATA GUARD COMPONENTS

Oracle 10g Data Guard consists of the following components:

PRIMARY DATABASE:

A primary database is a production database. The primary database is used to create a standby database. Everystandby database is associated with one and only one primary database.

STANDBY DATABASE:

A physical or logical standby database is a database replica created from a backup of a primary database.

- A physical standby database is physically identical to the primary database on a block-for-block basis. It isupdated by performing recovery from redo logs generated from the primary database.

8/13/2019 dg_110wp

2/20



- A logical standby database is logically identical to the primary database. It is updated using SQL statements.

LOG TRANSPORT SERVICES:

Log transport services control the automated transfer of archived redo from the primary database to one or morestandby sites.

NETWORK CONFIGURATION:

The primary database is connected to one or more remote standby database via Oracle Net.

LOGAPPLY SERVICES:

Log apply services apply the archived redo logs to the standby database.

DATA GUARD BROKER:

Data Guard Broker is the management and monitoring component with which you configure, control, and monitor afault tolerant system consisting of a primary database protected by one or more standby database.

Primary

Database

Log

Transport

Services

Log

Apply

Services

OracleNet

Data

Guard

Broker

Data

Guard

Broker

CLI GUI

Standby

Database

Online

Redo

Logs

Local

Archived

Logs

Remote

Archived

Logs

DATA GUARD ROLES

A database can operate in one of the two mutually exclusive roles: primary or standby database.

FAILOVER

During a failover, one of the standby databases takes the primary database role.

SWITCHOVER

In Oracle9i and Oracle 10g, primary and standby database can continue to alternate roles. The primary database canswitch the role to a standby database; and one of the standby databases can switch roles to become the primary.

8/13/2019 dg_110wp

3/20



DATA GUARD INTERFACES

Oracle provides three ways to manage a Data Guard environment:

SQL*PLUS AND SQL STATEMENTS

Using SQL*Plus and SQL commands to manage Data Guard environment.

The following SQL statement initiates a switchover operation:SQL> alter database commit to switchover to physical standby;

DATA GUARD BROKER GUI INTERFACE (DATA GUARDMANAGER)

Data Guard Manger is a GUI version of Data Guard broker interface that allows you to automate many of the tasksinvolved in configuring and monitoring a Data Guard environment.

DATA GUARD BROKER COMMAND-LINE INTERFACE (CLI)

It is an alternative interface to using the Data Guard Manger. It is useful if you want to use the broker from batchprograms or scripts. You can perform most of the activities required to manage and monitor the Data Guardenvironment using the CLI.

The following example lists the available commands:$ dgmgrlDGMGRL for Solaris: Version 9.2.0.1.0 - Production.

(c) Copyright 2002 Oracle Corporation. All rights reserved.

Welcome to DGMGRL, type "help" for information.DGMGRL> helpThe following commands are available:quit

exitshow See "help show" for syntaxenable See "help enable" for syntaxdisable See "help disable" for syntaxhelp []connect / [@]alter See "help alter" for syntaxcreate See "help create" for syntaxremove See "help remove" for syntaxswitchover See "help switchover" for syntaxfailover See "help failover" for syntaxstartup See "help startup" for syntaxshutdown See "help shutdown" for syntaxDGMGRL>

Note: The use of an SPFILE is required with Oracle9i Release 2 and Oracle 10g when using a Data Guard BrokerConfiguration.

8/13/2019 dg_110wp

4/20



PROCESSARCHITECTURE

PHYSICAL STANDBY PROCESSESARCHITECTURE

The log transport services and log apply services use the following processes to ship and apply redo logs to the

physical standby database:On the primary database site, the log writer process (LGWR)collects transactions from the log buffer and writes tothe online redo logs. The archiver process (ARCH)creates a copy of the online redo logs, and writes to the localarchive destination. Depending on the configuration, the archiver process or log writer process can also transmit redologs to standby database. When using the log writer process, you can specify synchronous or asynchronous networktransmission of redo logs to remote destinations. Data Guard achieves synchronousnetwork I/O using LGWRprocess. Data Guard achieves asynchronousnetwork I/O using LGWR network server process (LNS). Thesenetwork severs processes are deployed by LOG_ARCHIVE_DEST_n initialization parameter.

On the standby database site, the remote file server process (RFS)receives archived redo logs from the primarydatabase. The primary site launches the RFS process during the first log transfer. The redo logs information receivedby the RFS process can be stored as either standby redo logs or archived redo logs. Data Guard introduces theconcept of standby redo logs (separate pool of log file groups). Standby redo logs must be archived by theARCH

processto the standby archived destination before the managed recovery process (MRP)applies redo loginformation to the standby database.

The fetch archive log (FAL) clientis the MRP process. The fetch archive log (FAL) serveris a foregroundprocess that runs on the primary database and services the fetch archive log requests coming from the FAL client. Aseparate FAL server is created for each incoming FAL client.

When using Data Guard broker (dg_broker_start = true), the monitor agent process named Data Guard BrokerMonitor (DMON)is running on every site (primary and standby) and maintain a two-way communication.

Primary

Database

OracleNet

LGWR LNS

FAL

Server

ARCH

FAL

Client/

MRPARCH

DMON DMON

RFS

SYNC

ASYNC

Physical

standby

Database

Online

Redo

Logs

Local

Archived

Logs

Remote

Archived

Logs

Standby

Redo

Logs

8/13/2019 dg_110wp

5/20



LOGICAL STANDBY PROCESSESARCHITECTURE

The major difference between the logical and physical standby database architectures is in its log apply services.

The logical standby process (LSP)is the coordinator process for two groups ofparallel execution process (PX)that work concurrently to read, prepare, build, and apply completed SQL transactions from the archived redo logs sentfrom the primary database. The first group of PX processes read log files and extract the SQL statements by usingLogMiner technology; the second group of PX processes apply these extracted SQL transactions to the logical standbydatabase. The mining and applying process occurs in parallel. Logical standby database does not use standby onlineredo logs. Logical standby database does not have FAL capabilities in Oracle9i. All gaps are resolved by the proactivegap resolution mechanism running on the primary that polls the standby to see if they have a gap.

Primary

Database

OracleNet

LGWR LNS

ARCH

LSP0

DMON DMON

RFS

SYNC

ASYNC

Logical

Standby

Database

PX

PX

PX

PX

Mining

Group

Applying

Group

Online

Redo

Logs

Local

ArchivedLogs

Remote

Archived

Logs

Note: Logical Standby database is an Oracle9i Release 2 and Oracle 10g feature. In 9.2, the LGWR SYNC actuallydoes use the LNS as well. Only SYNC=NOPARALLEL goes directly from the LGWR. The default SYNC mode isSYNC=PARALLEL.

8/13/2019 dg_110wp

6/20



DATA PROTECTION MODES

Depending on the business requirement, you can set Data Guard in different protection modes.

ORACLE9I RELEASE 1 HAS FOUR DATA PROTECTION MODES:

Guaranteed protection:The standby database cannot diverge from the primary database and no data can be lost. Atransaction is not committed on the primary database until it has been confirmed that the transaction data is availableon at least one standby database. When operating in this mode, it provides the highest degree of data availability.However, it could adversely affect primary database performance.

Instant protection:The standby database could temporarily diverge from the primary database. However, thestandby database will be synchronized after the failover process, no data will be lost.

Rapid protection:The log writer process transmits redo logs to the standby site. The primary database continues itsoperation without regard to the database availability on the standby database. There is risk to lose a small amount of

data.Delayed protection: The archiver process transmits the redo logs to the standby sites. This is the only option inOracle8i standby database.

Mode Log WritingProcess

Network TransMode

Disk WriteOption

Redo LogReceptionOption

FailureResolutionOption

Guaranteed LGWR SYNC AFFIRM Standby redologs

Protect

Instant LGWR SYNC AFFIRM Standby redologs

Unprotect

Rapid LGWR ASYNC NOAFFIRM Standby redologs

Unprotect

Delayed ARCH ASYNC NOAFFIRM Archived redologs

Unprotect

Note: Oracle recommends Standby Redo Logs on all of the top three modes.

8/13/2019 dg_110wp

7/20



ORACLE9I RELEASE 2AND ORACLE 10G PROVIDE THREE DATA PROTECTION MODES:

Maximum Protection:It offers the highest level of data availability for the primary database. Redo records aresynchronouslytransmitted from the primary database to the standby database using LGWR process. Transaction isnot committedon the primary database until it has been confirmedthat the transaction data is available on at least

one standby database. This mode is usually configured with at least two standby databases. If all standby databasesbecome unavailable, it may result in primary instance shutdown. This ensures that no data is lost when the primarydatabase loses contact with all the standby databases. Standby online redo logs are required in this mode. Therefore,logical standby database cannot participate in a maximum protection configuration. This mode is similar to 9iR1sguaranteed mode.

Maximum Availability:It offers the next highest level of data availability for the primary database. Redo records aresynchronouslytransmitted from the primary database to the standby database using LGWR process. The transactionis not completeon the primary database until it has been confirmed that the transaction data is available on thestandby database. If standby database becomes unavailable, it will not shut down the primary database. Instead, theprotection mode is temporarily switched to maximum performance mode until the fault has been corrected and thestandby database will re-synchronize with the primary database. This protection mode supports both physical and

logical standby databases, and only available in Oracle9i release 2 and Oracle 10g Data Guard.

Maximum Performance:It is the defaultprotection mode. It offers slightly less primary database protection thanmaximum availability mode but with higher performance. Redo logs are asynchronouslyshipped from the primarydatabase to the standby database using either LGWR or ARCH process. When operating in this mode, the primarydatabase continues its transaction processing without regard to data availability on any standby databases and there islittle or no effect on performance. This protection mode is similar to the combination of 9iR1s Instance, Rapid, andDelay modes. It supports both physical and logical standby databases.

Mode Log WritingProcess Network TransMode Disk WriteOption Redo LogReceptionOption

Supported on

MaximumProtection

LGWR SYNC AFFIRM Standby redologs are required

Physical standbydatabases

MaximumAvailability

LGWR SYNC AFFIRM Standby redologs

Physical andlogical standbydatabases

MaximumPerformance

LGWR orARCH

ASYNC ifLGWR

NOAFFIRM Standby redologs

Physical andlogical standbydatabases

8/13/2019 dg_110wp

8/20



DATA GUARD IMPLEMENTATION

There are two ways to configure a Data Guard environment.

1. Using Oracle9i Data Guard broker.

2. Manual configuration of a Data Guard environment.The best way to understand Data Guard implementation is to setup one manually.

For simple illustration, a hypothetical Data Guard environment is given (see table below).

The following shows how to set up Data Guard in this given environment:

1. The production database name isprod.

2. One primary database instance calledprod_01on host server_01; one physical standby database instancecalledprod_02on host server_02.

3. Listener listener_prod_01is on host server_01, and pointed by TNS entryprod_01.

4. Listener listener_prod_02is on host server_02, and pointed by TNS entryprod_02.

5. The purpose of TNS entryprod_01andprod_02are used for LGWR/ARCH process to ship redo logsto the standby site, and for FAL process to fetch redo logs from the primary site.

6. Since Data Guard broker is not used here, we set dg_broker_start to false.

7. The protection mode is set to best performance. Therefore, only local archive destination(log_archive_dest_1) is set to mandatory; the standby archive destination (log_archive_dest_2) is set tooptional for LGWR process, with network transmission method of asynchronous and disk write optionof no affirm.

8. The standby site is not using standby online redo logs. Therefore, the redo log reception option isarchived logs.

Sect

ion1:

Site

Primary Site:

Database Name:prod

Primary Server: server_01

Primary Instance Name:prod_01

Primary Listener: listener_prod_01

Standby Site:

Database Name:prod

Standby Server: server_02

Standby Instance name:prod_02

Standby Listener: listener_prod_02

Section2

:

Oratab

/var/opt/oracle/oratab entry:

prod_01:/u01/app/oracle/product/9.2.0:N

/var/opt/oracle/oratab entry:

prod_02:/u01/app/oracle/product/9.2.0:N

8/13/2019 dg_110wp

9/20



Section3:

Parameterfile

Primary init.ora file:

db_name = prod

#drs_start = false # for 9.0.1

dg_broker_start = false # for 9.2.0

#fal_server = prod_02

#fal_client = prod_01

log_archive_dest_1 = location=/u02/arch/prod/mandatory

log_archive_format = prod_%s.arc

log_archive_start= true

standby_archive_dest = /u02/arch/prod

log_archive_dest_2 = service=prod_02optionalrepoen=60 lgwr async noaffirm

log_archive_dest_state_2 = enable

Standby init.ora file:

db_name = prod

#drs_start = false # for 9.0.1

dg_broker_start = false # for 9.2.0

fal_server = prod_01

fal_client = prod_02

log_archive_dest_1 = location=/u02/arch/prod/mandatory

log_archive_format = prod_%s.arc

log_archive_start= true

standby_archive_dest = /u02/arch/prod

#log_archive_dest_2 = service=prod_01optionalrepoen=60 lgwr async noaffirm

#log_archive_dest_state_2 = enableSection4:

Listener.orafile

Primary listener.ora file:

Listener_prod_01

(address_list =

(address = (protocol = tcp)

(host = server_01)

(port = 1522)

)

)

sid_list_listener_prod_01

(sid_list =

(sid_desc =

(oracle_home=/u01/app/oracle/product/9.2)

(sid_name =prod_01)

)

)

Standby listener.ora file:

Listener_prod_02

(address_list =


(host = server_02)

(port = 1522)

)

)

sid_list_listener_prod_02

(sid_list =

(sid_desc =

(oracle_home=/u01/app/oracle/product/9.2)

(sid_name =prod_02)

)

)

8/13/2019 dg_110wp

10/20



Section5:Tnsn

ames.orafile

Primary tnsnames.ora file:

Prod=

(description =


(host = server_01)

(port = 1522)

(connect_data = (sid =prod_01)))

Prod_01=

(description =


(host = server_01)

(port = 1522)


Prod_02=

(description =


(host = server_02)

(port = 1522)


Standby tnsnames.ora file:

Prod=

(description =


(host = server_01)

(port = 1522)


Prod_01=

(description =


(host = server_01)

(port = 1522)


Prod_02=

(description =


(host = server_02)

(port = 1522)


STEPS TO SET UP A DATA GUARD ENVIRONMENT

The following eight steps show how to set up a Data Guard environment:

STEP 1: THE PREPARATION

Plan the Data Guard environment.

- Understand the business requirements and demands

- Decide the number of standby databases (logical/physical)

- Decide file system layout for standby (If feasible, prefer identical layout of primary database)

- Ensure primary database is in ARCHIVELOG mode

- Choose the proper redo log size and groups

- Choose the proper protection mode

Setup the init.ora file for both primary and standby databases.

Setup the listener.ora file for both primary and standby databases.

Setup tnsnames.ora file for both primary and standby sites.

8/13/2019 dg_110wp

11/20



STEP 2: BACKUP THE PRIMARY DATABASE DATAFILES

Shut down the primary database.

Backup the primary database datafiles.$ cp /u02/oradata/prod/* /u03/backup/prod/

Startup the primary database with the modified p-file.

STEP 3: CREATE THE PHYSICAL STANDBY DATABASE CONTROL FILE

Ensure the primary database is in ARCHIVELOG mode and automatic archiving is enabled.

Issue the following command to create the standby control file:SQL> alter database create standby controlfile as/u01/app/oracle/admin/prod/ctl/stbycf.ctl

STEP 4: TRANSFER THE DATAFILES AND CONTROL FILE TO THE STANDBY SITE

Transfer the datafiles.$ rcp /u03/backup/prod/* server_02:/u02/oradata/prod

Transfer the standby control file$ rcp /u01/app/oracle/admin/prod/ctl/stbycf.ctlserver_02:/u01/app/oracle/admin/prod/ctl/control01.ctl

STEP 5: START THE LISTENERS ON BOTH PRIMARY AND STANDBY SITE

Start the primary database listener.$ lsnrctl start listener_prod_01

Start the standby database listener.$ lsnrctl start listener_prod_02

STEP 6: START THE STANDBY DATABASE

Set the correct Oracle environment.

Connect as sysdba.SQL> connect /as sysdba;

Bring the database in nomount mode first.SQL> startup nomount;

Mount the standby database.SQL> alter database mount standby database;

STEP 7: PLACE THE STANDBY DATABASE INMANAGED RECOVERYMODE

Issue the following command to bring the standby database in managed recover mode.SQL> alter database recover managed standby database disconnect from session;

8/13/2019 dg_110wp

12/20



STEP 8: MONITOR THE LOG TRANSPORT SERVICES AND LOGAPPLY SERVICES

Issue a few log switches on the primary database.SQL> alter system switch logfile;

Confirm the log files received on the standby archive destination.

Check the standby alert log file to see if the new logs have applied to the standby database.Media Recovery Log /u02/arch/prod/prod_1482.arc

Monitor the managed recovery.SQL> select process, status, thread#, sequence#, block#, blocks

from v$managed_standby;

FAILOVER STEPS

Failover is only performed as a result of an unplanned outage of the primary database. During a failover, the standbydatabase (prod_02) becomes the new primary database. It is possible to have data loss.

In 9.0.1, since you do not have Standby Redo Log files, you issue the following command on the standby site toactivate the new primary database:SQL> alter database activate standby database;

The ACTIVATE STANDBY DATABASE clause automatically creates online redo logs. It also performed a resetlogs operation. New logs generated from the new primary database (prod_02) cannot be applied to the old primarydatabase (prod_01).

In 9.2.0, you can gracefully Failover even without standby redo log files. Issue the following command on the standbysite to Failover to a new primary database.SQL> alter database recover managed standby database skip standby logfiles;

This will apply all available redo and make the standby available to become a Primary. Complete the operation byswitching the standby over to the primary role with the following command:SQL> alter database commit to switchover to primary;

The old primary (prod_01) has to be discarded and can not be used as the new standby database. You need to createa new standby database by backing up the new primary and restore it on host server_01. The time to create a newstandby database exposes the risk of having no standby database for protection.

After failover operation, you need to modify TNS entry for prod to point to the new instance and host name (seenext section: Switchover Step 7).

SWITCHOVER STEPS

Unlike failover, a switchover operation is a planned operation. All the archive logs required bringing the standby tothe primarys point in time need to be available. The primary databases online redo logs also must be available andintact. During switchover operation, primary and standby databases switch roles. The old standby database(prod_02) becomes the new primary, and the old primary (prod_01) becomes the new standby database.

The following are steps for switchover operation:

8/13/2019 dg_110wp

13/20



STEP 1: SWITCHOVER PREPARATION FOR FORMAL PRIMARY DATABASE

End all activities on the primary and standby database

Check primary database switchover statusSQL> select database_role, switchover_status from v$database;

DATABASE_ROLE SWITCHOVER_STATUS------------------------- -----------------------------------PRIMARY TO STANDBY

Initiate the switchover operation on the primary databaseSQL> alter database commit to switchover to physical standby;

STEP 2: SHUTDOWN THE PRIMARY DATABASE AND BRING UP AS THE NEW STANDBY DATABASE

Shutdown the primary database normallySQL> shutdown normal;

Modify the former primary databases initialization file

- Add the following two parameters. These two parameters can also be set on the primary database aheadof time for future switchover operation.

- fal_server = prod_02

- fal_client = prod_01

- Remove parameters log_archive_dest_2 and log_archive_dest_state_2. Or, just defer it is you like

Bring the former primary database in mount modeSQL> startup nomount;SQL> alter database mount standby database;

STEP 3: SWITCHOVER PREPARATION FOR THE FORMER STANDBY DATABASE

Check standby database switchover status

SQL> select database_role, switchover_status from v$database;

DATABASE_ROLE SWITCHOVER_STATUS------------------------- -----------------------------------

PHYSICAL STANDBY TO PRIMARY

Initiate the switchover operation on the standby databaseSQL> alter database commit to switchover to physical primary;

STEP 4: SHUTDOWN THE STANDBY DATABASE AND BRING UP AS THE NEW PRIMARY DATABASE

Shutdown the standby databaseSQL> shutdown normal;

Modify the former standby databases initialization file

- fal_server = prod_01

- fal_client = prod_02

- Add parameters log_archive_dest_2 and log_archive_dest_state_2

Bring up the former standby database as the new primary databaseSQL> startup;

8/13/2019 dg_110wp

14/20



STEP 5: ADD TEMP TABLESPACE

Issue the following command to add TEMP tablespaceSQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/u02/oradata/prod/temp01.dbf'

SIZE 3072M reuse AUTOEXTEND OFF;

STEP 6: PUT THE NEW STANDBY DATABASE IN MANAGED RECOVERY MODE

Issue the following command on the new standby database.SQL> alter database recover managed standby database disconnect;

STEP 7: CHANGE TNS ENTRY FOR THENEW PRIMARY DATABASE

Change the TNS entry on all application hosts to point to the new primary

Prod=

(description =

(address = (protocol = tcp) (host = server_02) (port = 1522)

(connect_data = (sid =prod_02))

)

8/13/2019 dg_110wp

15/20



IMPLEMENTATIONTIPS

Here are several tips for implementing Data Guard:

TIP #1: PRIMARY ONLINE REDO LOGSThe number of redo groups and the size of redo logs are two key factors in configuring online redo logs. In general,you try to create the fewest groups possible without hampering the log writer processs ability to write redo loginformation. In a Data Guard environment, LGWR process may take longer to write to the remote standby sites, youmay need to add additional groups to guarantee that a recycled group is always available to the log writer process.Otherwise, you may receive incomplete logs on the standby sites. The size of redo log is determined by the amount oftransaction needed to be applied to a standby database during database failover operation. A small size of redo willminimize the standby database lag time; however, it may cause more frequent log switches and require more redogroups for log switches to occur smoothly. On the other hand, large size redo logs may require few groups and lesslog switches, but it may increase standby database lag time and potential for more data loss. The best way todetermine if the current configuration is satisfactory is to examine the contents of the log writer processs trace fileand the databases alert log.

For example, the following message from the alert log may indicate a need for more log groups.ORA-00394: online log reused while attempting to archive it

TIP #2: STANDBY ONLINE REDO LOGS VS. STANDBYARCHIVED REDO LOGS

Online redo logs transferred from the primary database are stored as either standby redo logs or archived redo logs.Which redo log reception option should we choose? Here is the comparison chart:

Standby Online Redo Logs Standby Archived Redo Logs

Advantages - Pre-allocated files

- Can place on raw devices

- Can be duplexed for more protection- Improve redo data availability

- No Data Loss capable

- No extra ARCH process

- Reduce lag time

TIP #3: ENFORCE LOGGING

Enforce Logging is a new feature in Oracle9i Release 2, it is recommended that you set the FORCE LOGGINGclause to force redo log to be generated for individual database objects set to NOLOGGING. This is required for ano data loss strategy.

Here is the SQL command to set FORCE LOGGING:SQL> select force_logging from v$database;

FORCE_LOGGING--------------NO

SQL> alter database force logging;

8/13/2019 dg_110wp

16/20



TIP #4: RMAN BACKUP

A failover operation reset logs for the new primary. If you use RMAN to backup your database, you need to create anew incarnation of the target database. Otherwise, your RMAN backup will fail.RMAN> reset database;

TIP #5: DISABLE LOGTRANSPORT SERVICESWHEN STANDBY DATABASE IS DOWNWhen a standby database or host is down for maintenance, it is advisable to temporarily disable the log transportservices for that site. Especially during a heavily transaction period, one behavior observed in Oracle9i R1 is thatwhen one of the standby database is down for maintenance, it can temporarily freeze the primary database even thedata protection mode is set to rapid mode. To avoid such problem, you can issue this command on the primarydatabase before bring down the standby database:SQL> alter system set log_archive_dest_state_2 = defer;

When the standby database is up again, issue:SQL> alter system set log_archive_dest_state_2 = enable;

TIP #6: STANDBY DATABASE UPGRADE

Steps to upgrade standby database to newer database version:Step 1: Shutdown both primary and standby databases

Step 2: Install Oracle9i software on both primary and standby hosts

Step 3: Upgrade the primary database

Step 4: Rebuild standby database from the upgraded primary

TIP #7: DATA GUARD BROKER

Oracle9i Release 1 broker configuration supported only one primary site and one physical standby site. The firstrelease of broker is not so user friendly with limited features.

Oracle9i Release 2 broker has made great improvements. The new configuration now support up to nine standbysites (including logical standby database). Both Data Guard Manager and CLI support switchover and failoveroperations. You must upgrade to Oracle Enterprise Manager Release 9.2 to managed broker configuration runningData Guard Release 2.

TIP #8: USING DELAY OPTION TO PROTECT LOGICAL/PHYSICAL CORRUPTIONS

You may utilize the delay option (if you have multiple standby sites) to prevent physical/logical corruption of yourprimary. For instance, your standby #1 may not have Delay on to be your disaster recovery standby database.However, you may opt to implement a delay of minutes or hours on your standby #2 to allow recover from a possiblephysical or logical corruption on your primary database.SQL> alter database recover managed standby database delay 5 disconnect;

8/13/2019 dg_110wp

17/20



TIP #9: ALWAYS MONITOR LOG APPLY SERVICES AND CHECKALERT. LOG FILE FOR ERRORS.

If you are not using Data Guard broker, here is a script to help you to monitor your standby database recover process:

$ cat ckalertlog.sh####################################################################

## ckalertlog.sh #######################################################################!/bin/kshexport EDITOR=viexport ORACLE_BASE=/u01/app/oracleexport ORACLE_HOME=$ORACLE_BASE/product/9.2.0export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/libexport TNS_ADMIN=/var/opt/oracleexport ORATAB=/var/opt/oracle/oratabPATH=$PATH:$ORACLE_HOME:$ORACLE_HOME/bin:/usr/ccs/bin:/bin:/usr/bin:/usr/sbin:/sbin:/usr/openwin/bin:/opt/bin:.; export PATHDBALIST="[email protected],[email protected]";export

for SID in `cat $ORACLE_HOME/sidlist`do

cd $ORACLE_BASE/admin/$SID/bdumpif [ -f alert_${SID}.log ]then

mv alert_${SID}.log alert_work.logtouch alert_${SID}.logcat alert_work.log >> alert_${SID}.histgrep ORA- alert_work.log > alert.err

fiif [ `cat alert.err|wc -l` -gt 0 ]then

mailx -s "${SID} ORACLE ALERT ERRORS" $DBALIST < alert.errfirm -f alert.errrm -f alert_work.log

done

Place the script in a crontab:########################################################## Check Standby log file#########################################################9,19,29,39,49,59 7-17 * * 1-5 /dba/scripts/ckalertlog.sh

8/13/2019 dg_110wp

18/20



DATA GUARD 10G ENHANCEMENT

Here are a list of Oracle 10g Data Guard Enhancement:

REALTIMEAPPLYThe Real Time Apply feature allows standby databases to be closely synchronized with the primary database, enablingup-to-date and real-time reporting (especially for Data Guard SQL Apply). This also enables faster switchover andfailover times, which in turn reduces planned and unplanned downtime for the business.

INTEGRATION WITH FLASHBACK DATABASE

One such benefit is human error protection. In Oracle9i, administrators may configure Data Guard with an applydelay to protect standby databases from possible logical data corruptions that occurred on the primary database. Theside-effects of such delays are that any reporting that gets done on the standby database is done on old data, andswitchover/failover gets delayed because the accumulated logs have to be applied first.

INTEGRATION WITH FLASHBACK DATABASE

In Data Guard 10g, with the Real Time Apply feature, such delayed-reporting or delayed-switchover/failover issues donot exist. If logical corruptions do land up affecting both the primary and standby databases, the administrator maydecide to use Flashback Database on both the primary and standby databases to quickly revert the databases to anearlier point-in-time to back out such user errors.

Another benefit that such integration provides is during failovers. Prior to 10g, following any failover operation, theold primary database must be recreated (as a new standby database) from a backup of the new primary database, if theadministrator intends to bring it back in the Data Guard configuration. This may be an issue when the database sizesare fairly large, and the primary/standby databases are hundreds/thousands of miles away.

However, in Data Guard 10g, after the primary server fault is repaired, the primary database may simply be brought up

in mounted mode, "flashed back" (using flashback database) to the SCN at which the failover occurred, and thenbrought back as a standby database in the Data Guard configuration. No reinstantiation is required.

ZERO DOWNTIME INSTANTIATION

Logical standby database can now be created from an online backup of the primary database, without shutting downor quiescing the primary database, as was the case in prior releases. No shutdown of the primary system impliesproduction downtime is eliminated, and no quiesce implies no waiting for quiescing to take effect and no dependenceon Resource Manager.

ROLLING UPGRADES

Oracle Database 10g supports database software upgrades (from Oracle Database 10g Patchset 1 onwards) in a rolling

fashion, with near zero database downtime, by using Data Guard SQL Apply.

The steps involve upgrading the logical standby database to the next release, running in a mixed mode to test andvalidate the upgrade, doing a role reversal by switching over to the upgraded database, and then finally upgrading theold primary database.

While running in a mixed mode for testing purpose, the upgrade can be aborted and the software downgraded,without data loss. For additional data protection during these steps, a second standby database may be used.

8/13/2019 dg_110wp

19/20



RAC SUPPORT

It is now possible to use the Data Guard Broker, and the Broker's Command Line Interface (DGMGRL), as well asEnterprise Manager, to create and manage Data Guard configurations that contain RAC primary and RAC standbydatabases.

In Oracle9i, such administration is possible only through SQL*Plus.

In Data Guard 10g, Data Guard Broker interfaces with Oracle Clusterware so that it has control over criticaloperations during specific Data Guard state transitions, such as Switchovers, failovers, protection mode changes andstate changes.

8/13/2019 dg_110wp

20/20


O l O W ld 200 P #S110 / P 20

CONCLUSION

This paper provides an overview of Oracle 10g Data Guard technology. The paper offers an introduction to the basicconcepts and architectures of Data Guard. It reviews different data protection modes. It discusses the followingimplementation steps: planning for higher availability, creating the standby database environment, setting up the log

transport services, managing the log apply services, and administrating the Data Guard environment. It also showssteps to perform switchover and failover operations, along with some implementation tips. By implementing OracleData Guard technology, organizations will achieve higher availability and no data loss.

ABOUT THEAUTHOR

Daniel Liu is a Senior Technical Consultant at First American Real Estate Solutions in Anaheim, CA and co-author ofOracle Database 10g New Features - Advanced Tuning & Administration by Rampant TechPress. His expertiseincludes Oracle database administration, performance tuning, Oracle networking, and Oracle Application Server. Asan Oracle Certified Professional, he taught Oracle certified DBA classes and IOUG University Seminars. Daniel haspublished articles with DBAzine, Oracle Internals, Oracle Technology Network, and SELECT Journal. Daniel has

received SELECT Editorial Award for Best Article in 2001, and has been named Architect of the Week by the OracleTechnology Network in 2004. He has also given presentations at IOUG-A Live, LAOUG, OCOUG, NoCOUG,TOUG, OOUG, Oracle Open World and Oracle World. Daniel has served as panelist on Oracles of Oracle at OracleWorld and IOUG-Live. Daniel holds a Master of Science degree in computer science from Northern IllinoisUniversity. Daniel can be reached at (714)-701-3346 or by email at [email protected] [email protected].

REFERENCES

Oracle Data Guard, Concepts and Administration, 10g Release 1 (10.1);

Oracle9i, Data Guard Concepts and Administration. Release 1 (9.0.1);

Oracle9i, Data Guard Concepts and Administration. Release 2 (9.2);

Oracle9i, Data Guard Broker. Release 2 (9.2);Oracle Metalink Support;

Top DBA Shell Scripts for Monitoring Database, Daniel T. Liu; DBAZine;

I would also like to acknowledge the assistance of Bob Polak of the Allants Groups, Larry Barry, Ann Collins,Archana Sharma and Husam Tomeh of FARES, and Larry Carpenter, Joseph Meeks of Oracle Corporation.

All companies and product names are trademarks or registered trademarks of the respective owners. Please reporterrors in this article to the author. Neither FARES nor the author warrants that this document is error-free.

dg_110wp

Documents