STAND BY YOUR DATA GUARD

Darl Kuhn, Sun Microsystems Introduction
Today’s business environment often requires that data be highly available. Oracle Data Guard is a built-in component of Oracle9i that protects your database from disasters, corruption, and user errors. In addition, it also reduces planned downtime. Previously known as the standby option, this feature has long been a dependable and efficent method for achieving high availability and disaster recovery protection. The reason for its reliability and economic appeal is that standby is underpinned by a simple and yet powerful architecture that: 1. 2. Takes a backup of your primary database and moves it to a standby location Periodically copies the primary archived redo logs and applies them to the standby

With Oracle8i, standby was improved with automated log copy and apply services and the ability to open a standby database in read-only mode for reporting. Additionally, in release 8.1.7, standby database technology was introduced as Oracle Data Guard. Starting with Oracle9i, Oracle Data Guard adds many new features such as: • • • • • • • Data Guard SQL Apply (version 9.2 only) Guaranteed no-data-loss Archive gap management Propagation of datafile operations User error protection Database switchover Data Guard Broker

Each of these improvements adds substantial functionality over what was available prior to Oracle9 i. These new features give you advanced levels of high availability and robust methods for managing the creation, maintenance, switchover, and failover operations of your databases.

Data Guard SQL Apply
Before Oracle9i release 2, the only type of standby database was a physical standby. One feature of a physical standby is that it can be placed in either recovery mode or read-only mode. The recovery mode and read-only modes are mutually exclusive. New with the Data Guard SQL Apply feature of Oracle9i release 2, you can now implement a logical standby database. A logical standby database is continuously available for reporting while simultaneously applying transactions from the primary. A logical standby database would be appropriate if you have business needs of a near real-time copy of your production database that is also 24x7 available for querying. A logical standby database differs architecturally from a physical standby. A physical standby database is identical to the primary database down to the block level. This is because the Oracle uses redo information received from the primary to apply those redo changes to the data blocks on disk.

www.rmoug.org

RMOUG Training Days 2003

and urowid. since LGWR is synchronously shipping redo information to the standby. Once enabled. if the standby is unavailable for any reason. Note: The following datatypes are not supported in a logical standby database: long. Guaranteed No-Data-Loss Prior to Oracle9i. the primary will also become unavailable. do the following: • • • • Enable primary LGWR to write transactions synchronously Create standby redo logs on your physical standby databases Set standby log archive destination Alter primary database into standby database protected mode The Maximum Protection mode has several key architectural implications. One noteworthy feature is that the log writer (LGWR) becomes the process for propagating transactions to the standby. On your primary database you enable the feature as follows: SQL> alter system set log_archive_dest_2='SERVICE=standby1 LGWR SYNC AFFIRM'. If you use your logical standby for querying. This ensures zero data loss for the Data Guard configuration. rowid. When enabled. nclob. you get a wide variety of data protection levels when configuring archive destinations and transaction completion requirements. not the archiver (ARC0) process. long raw. Enabling Maximum Protection mode should be a well-planned activity. you can further enhance it by creating indexes and materialized views independent of the primary. a logical standby uses LogMiner technology to transform the redo data received from the primary into SQL statements and then applies those SQL statements to the logical standby. Additionally. www. You can configure your standby environment to use both logical and physical standby databases. In Maximum Protection mode. LGWR must be enabled with a log transport setting of SYNC and the disk write setting of AFFIRM. For example.org RMOUG Training Days 2003 . The best places for setup directions are the version 2 Oracle Data Guard Concepts and Administration manual and Oracle MetaLink note 186150. it is logically identical to the primary. LGWR must be able to successfully write transactions synchronously to both the primary and the standby. To change your physical standby to the Maximum Protection mode that guarantees zero data loss. meaning it has the same objects. With Oracle9i. the potential existed with a physical standby that you could lose transactions in the primary database redo logs before they had a chance to be transported and applied to the standby. You can query DBA_LOGSTDBY_UNSUPPORTED in your primary database to determine if you have unsupported data types. the Maximum Protection mode guarantees that transactions are not committed on the primary until the redo needed to recover those transactions has been written to disk on at least one standby database.1.rmoug. but it is not physically identical at the disk level. this could potentially impact your primary database performance. a logical standby database can take the role of the primary if there is some sort of disaster. Therefore.Stand By Your Data Guard Kuhn In contrast with a physical standby. Just like a physical standby. bfile. Setting up a logical standby involves dozens of steps.

SQL> recover managed standby database disconnect.------------. affirm from v$archive_dest where target='STANDBY' and status='VALID'. SQL> alter database open.log') size 20M. offering more reliability These files can exist on raw devices. TARGET STATUS STANDBY VALID PROCESS LGWR TRANSMIT_MOD AFF SYNCHRONOUS YES ------------. you create the logs as follows: SQL> alter database mount standby database. transmit_mode.-----------------------. Another important architectural aspect of the Maximum Protection mode is that the standby must use standby redo logs. on your primary select the new Oracle9 i database role and mode columns now available in the v$database view: www. SQL> alter database add standby logfile ('/ora1/oradata/BRDSTN/sb_redo_01. status.----- To verify the role and protection mode. standby redo logs are special redo logs that are required when you enable higher levels of data protection. offering possible performance benefits The standby redo logs must be of the same size as the primary online redo logs.Stand By Your Data Guard Kuhn Note: The impact on performance can be minimized by configuring a network with sufficient bandwidth for peak transaction load and with low round trip latency. On the standby. and must have at least two groups.log') size 20M. When you use standby redo logs. you get some interesting side benefits: • • Standby redo logs can setup with multiple members.---------. New with Oracle9i. SQL> alter database add standby logfile ('/ora1/oradata/BRDSTN/sb_redo_02. process. SQL> alter database set standby database protected. The last step involved in deploying Maximum Protection mode protection is to alter your primary database into protected mode: SQL> startup mount.org RMOUG Training Days 2003 . on your primary query the v$archive_dest view: SQL> select target. In your standby environment. To give you that fuzzy and warm feeling that you've set things up correctly. you must set your log_archive_dest_1 parameter to point to the directory where the standby redo logs are archived and then put the standby back in managed recovery mode: SQL> alter system set log_archive_dest_1='LOCATION=/ora1/oradata/BRDSTN/sb_redo'.rmoug.

manually perform the following tasks on your standby: • • • • • Determine which archived redo logs are part of the gap Manually copy the archived redo gap logs to standby Take the standby database out of managed recovery mode Issue the RECOVER STANDBY DATABASE command Alter the standby database back into managed recovery mode In Oracle9i. you had the responsibility of monitoring for gaps. standby_mode from v$database. if the primary log transport mechanism is not able to ship the redo data from the primary database to the physical standby database. Once a gap is noticed. and then disaster strikes. you get nice improvements in the method that archive gaps are discovered and resolved. Archive Gap Management In a managed recovery configuration. An untimely gap resolution mechanism compromises the availability of data in the standby environment. Using two new Oracle9i initialization parameters on your standby database enables the second method for automatic archive gap resolution: SQL> alter system set FAL_SERVER = primary1. This situation will likely arise if there is a network problem or if the standby database is down for any reason. For example. Data Guard has two methods for automatically detecting and resolving archive gaps. Discovering and resolving archive log gaps is critical to enabling high availability. this will most likely result in a loss of data after you failover to your standby database. Previously in Oracle8 i. SQL> alter system set FAL_CLIENT = standby1. The first method for gap resolution is via a periodic background communication between the primary database and all of its standby databases. if you have an undetected gap. then you have a gap between what archive logs have been generated by the primary and what have been applied to the physical standby. and once discovered. DATABASE_ROLE -----------------------PRIMARY STANDBY_MODE ----------------------PROTECTED From this point on you are guaranteed that transactions will be committed simultaneously in both your primary and the standby database. This method is automatic and does not need any special configuration.org RMOUG Training Days 2003 . the missing archive log files are sent to the appropriate standbys. Data Guard compares log files created on the primary with log files received on the standby databases to detect the gaps.Stand By Your Data Guard Kuhn SQL> select database_role.rmoug. In Oracle9i. www.

log file shows that a gap has been discovered and the action taken to synchronize the primary and standby databases: ARC0: Begin FAL archive (thread 1 sequence 153 dest standby1) ARC0: Complete FAL archive (thread 1 sequence 153 dest standby1) ARC0: Begin FAL archive (thread 1 sequence 154 dest standby1) ARC0: Complete FAL archive (thread 1 sequence 154 dest standby1) In the standby alert. The FAL client process runs in the physical standby environment and is responsible for requesting primary archived redo logs when it detects a gap on the standby.log file. Propagation of Datafile Operations One advantage that the physical standby database feature has always had over other high availability paradigms is that all datatypes and DML operations are supported. For example. CREATE PACKAGE. www. For example. any CREATE USER. the network was temporarily down. we see that the two archive redo logs that comprise the gap have been applied and now the managed recovery process is waiting for the next archived redo log file to arrive: Media Recovery Log /ora1/oradata/BRDSTN/ar/arch_0001_000153. one shortcoming of Oracle8i is that tablespace and datafile add/drop operations are not propagated in an automated fashion.Stand By Your Data Guard Kuhn Once these initialization parameters are enabled on the standby database. However. In the next example. in Oralce8i. In this scenario. the managed recovery process on the physical standby will automatically check and resolve gaps at the time archive redo is applied. The FAL server process runs on the primary database server and services requests from the FAL client. The FAL processes use these parameters to determine the location of the physical standby and primary databases. CREATE TABLE.arc Media Recovery Log /ora1/oradata/BRDSTN/ar/arch_0001_000154.arc Media Recovery Waiting for thread 1 seq# 155 Note: The FAL parameters are also used by the managed recovery process to re-ship an archive redo log if corruption is detected or if the log file has been removed after previously being shipped. etc. Again. timely gap resolution is critical to maintaining a high availability. Data Guard automatically determined there was a gap and transmitted and applied the appropriate archived redo logs. statements are automatically applied to the standby without DBA intervention. Another advantage is that most DDL statements are supported. you may add a datafile to your primary database: SQL> alter tablespace GOBR add datafile '/ora1/oradata/BRDSTN8/gobr02. standby1 is the Oracle Net name of the standby database and primary1 is the Oracle Net name of the primary database. Data Guard now automates a previously manual task.dbf' size 5M. The primary database alert.org RMOUG Training Days 2003 . and during the down time the primary generated two archived redo logs numbered 153 and 154..rmoug. With automatic gap detection and resolution. After the network came back up. The new Fetch Archive Log (FAL) processes manage this automated gap detection and resolution.

The logic in the script would check the date stamp on the archive redo log file and would not apply any files that weren't older than the specified time criterion.dbf' as '/ora1/oradata/BRDSTN8/gobr02. www. In your standby database issue the following command: SQL> alter system set standby_file_management = auto.org RMOUG Training Days 2003 . In Oracle8i you were required to manually enable this delay by writing an OS script that would manage the transport and apply of archived redo logs. tablespace and datafile add/drop operations can be setup to be automatically propagated to the standby database. For example.dbf'. your standby database recovery session will automatically be canceled and remain in limbo until you manually add the datafile to the standby as follows: SQL> alter database create datafile '/ora1/oradata/BRDSTN8/gobr02. it is something you must be aware of and have manual procedures in place to ensure that tablespace and datafile add/drop operations do not terminate your standby recovery process. the SHOLAY tablespace will be dropped and the datafiles will be removed from disk. you now get many robust options for configuring your managed recovery environment. if somebody accidentally drops a table you will notice the problem before it has had time to make it to the physical standby database.Stand By Your Data Guard Kuhn If you don't manually intervene before that statement is propagated to the standby. User Error Protection Many businesses use Oracle Data Guard to provide protection from user errors such as accidentally dropped tables and erroneous update/delete/insert statements. the following command instructs the managed recovery process to wait 60 minutes from the time the archive redo log was generated to the time it is applied to the physical standby. tablespace and datafile add/drop commands are automatically propagated to the standby environment. While this isn't a huge inconvenience. One such option automates the delay in the application of archived redo logs to the physical standby. when enabling managed recovery mode.rmoug. The STANDBY_FILE_MANAGEMENT initialization parameter has no effect on datafile rename commands. Note: If you rename a datafile in Oracle9i. When that command is propagated to the standby. New with Oracle9i. All you have to do is set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO. From that point forward. if you issue the following command on your primary: SQL> drop tablespace SHOLAY including contents and datafiles. you still must manually intervene. This relieves you from having to manually intervene with these critical physical DBA tasks. For example. The idea being that with a delay. Protection from user errors is achieved by introducing a delay between the time a primary archive redo log is generated and the time that it is applied to the physical standby. With Oracle9i.

a database either has the role of a primary database or a standby database. These roles are mutually exclusive. After the hardware maintenance is finished. This relieves you from having to script. mounting it.rmoug. you would switchover the primary to a standby role and switch the standby to the primary role. This will make it easier to ensure that parameters like CONTROL_FILES and DB_FILE_NAME_CONVERT are used correctly depending on the database role. If problems arise (and they will) you'll need to know some of the inner workings of www.ora) for each database. say for hardware maintenance. Performing a switchover should be a well-planned and practiced activity. one for when it's in a primary role and one for when it's in a standby role. shutting it down. but are not applied until 60 minutes later. You would only initiate a failover if your primary database was lost beyond hope. reverse (sometimes called a switchback) the database roles back to the original configuration. Kuhn In this scenario the archive redo logs are immediately copied to the standby location as they become available. Database Switchover In Data Guard. DATABASE_ROLE -----------------------PRIMARY A database switchover is a Data Guard feature that allows you to switch the role of a database. To view the current role of your database: SQL> select database_role from v$database. In a scenario like this. The Oracle9i switchover feature is useful when you need to take your primary database out of service.org RMOUG Training Days 2003 .Stand By Your Data Guard SQL> recover managed standby database delay 60 disconnect. The last thing you want to see when you issue the switchover command is: ERROR at line 1: ORA-16139: media recovery required :-( I recommend having two versions of spfiles (or init. and thus the only way to put it back would be from a backup. and then altering it to activate it as the primary. You can now take a primary database and make it a standby or take a standby database and transition its role to primary. Note: Switchover should not be confused with database failover. A failover is taking a standby database. and maintain a manual delay process. Ensure that you refer to the Oracle Data Guard Concepts and Administration documentation for full details when performing a switchover. Data Guard Broker I'm old school and believe that when it comes to database availability you should know how to manually implement and maintain critical data protection features. monitor.

Refer to the Oracle Data Guard Broker documentation for full implementation details. When getting started with Oracle Data Guard. Thus. Data Guard Manager will be easy for you to use. Data Guard Broker is a comprehensive set of tools that you can use to create. manage. monitor. it's easier to implement if you: • • • Set up Oracle Data Guard with two different servers. It is available in both Oracle9i and Oracle9i version 2. I recommend becoming familiar with manually implementing and maintaining an environment before using automated tools. In a Unix environment the tail command is particularly helpful in this regard: www. wizard driven tool invoked from Oracle Enterprise Manager (OEM). lay it onto your standby server without having to modify parameters in your spfile (or init. If you are familiar with OEM tools. Getting Started If you're just getting started with Oracle Data Guard. allowing you to perform tasks such as: • • • • • • Create physical and logical standby databases Perform switchovers and failovers Toggle physical standby from recovery mode to read-only mode Change the protection mode for a primary/standby configuration Monitor log transport and log apply services Configure event driven reporting/e-mailing/paging You can literally point-and-click your way through many potentially complex manual tasks.Stand By Your Data Guard Kuhn your Data Guard environment. The advantage of using this tool is that from one central console you can automate complex tasks throughout a distributed Data Guard environment that would otherwise have to be done manually. I've found that concepts jell more quickly and issues are resolved more rapidly when I simultaneously monitor the contents of both the standby and primary alert. one for the primary and one for the standby Ensure that the mount points are named the same between the two servers Make the database name the same for the primary and standby This way all you have to do is take a backup of your primary. here are three practical tips from the trenches that will help you move forward with this data protection technology: Start Out Simple Don't start out trying to implement the most complex architecture. The OEM Oracle9i version 2 edition of Data Guard Manager is particularly feature-rich.org RMOUG Training Days 2003 .log files. and automate tasks in your greater Data Guard environment. Data Guard Manager is a screen-based. Use Alert Logs As you deploy your Oracle Data Guard environment and perform maintenance operations. Having said that.ora) that handle file name conversions. The most visible component of the broker is Data Guard Manager.rmoug. pertinent messages are often written to the primary and standby alert. You can use Data Guard Manager to automate many tasks in your Data Guard environment. maintain.log files.

Placing physical standby in read-only alter database recover managed standby database cancel. Pin these up on your cube wall so that you can concentrate on concepts rather than digging through manuals looking for syntax. MANAGED recover managed standby database [disconnect|cancel]. recover managed standby database. alter database mount standby database. standby_mode from v$database.rmoug.status. Failover alter database mount standby database. Read-only to managed recovery mode alter database close.Stand By Your Data Guard $ tail -f alert_BRDSTN. nor does it show all options. archiver. alter database open read only. Recovering standby MANUAL recover standby database. www.affirm.type from v$archive_dest. Starting standby startup nomount. but I've found it makes a good quick reference: Creating standby controlfile alter database create standby controlfile as '<path>/<filename>'.async_blocks.transmit_mode.org RMOUG Training Days 2003 . process. This list is not comprehensive. Viewing database role and mode select database_role. Viewing transaction protection level select target.log Kuhn List of Often Used Commands It is also handy is to keep a list of commonly used SQL commands in an Oracle Data Guard environment. alter database activate standby database.

Stand By Your Data Guard Kuhn Conclusion Oracle Data Guard is a fully integrated feature of Oralce9i that enables you to build highly available database solutions. www.rmoug. Oracle Data Guard adds an impressive set of disaster recovery features that build upon the already tried-and-true standby technology. This gives you a comprehensive disaster recovery tool suite that allows you to implement the appropriate level of data protection needed by your business.org RMOUG Training Days 2003 .

Sign up to vote on this title
UsefulNot useful