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 Oracle9i. 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.
RMOUG Training Days 2003
rowid. You can query DBA_LOGSTDBY_UNSUPPORTED in your primary database to determine if you have unsupported data types. meaning it has the same objects. If you use your logical standby for querying. not the archiver (ARC0) process. LGWR must be enabled with a log transport setting of SYNC and the disk write setting of AFFIRM. if the standby is unavailable for any reason. With Oracle9i. Additionally. it is logically identical to the primary.1. a logical standby database can take the role of the primary if there is some sort of disaster. Therefore. Just like a physical standby.rmoug.
Prior to Oracle9i. but it is not physically identical at the disk level. When enabled. This ensures zero data loss for the Data Guard configuration.org
RMOUG Training Days 2003
. Setting up a logical standby involves dozens of steps. the primary will also become unavailable. You can configure your standby environment to use both logical and physical standby databases. One noteworthy feature is that the log writer (LGWR) becomes the process for propagating transactions to the standby. In Maximum Protection mode. this could potentially impact your primary database performance. To change your physical standby to the Maximum Protection mode that guarantees zero data loss. Enabling Maximum Protection mode should be a well-planned activity. 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. 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. long raw. you can further enhance it by creating indexes and materialized views independent of the primary. you get a wide variety of data protection levels when configuring archive destinations and transaction completion requirements.
www. Note: The following datatypes are not supported in a logical standby database: long. LGWR must be able to successfully write transactions synchronously to both the primary and the standby. The best places for setup directions are the version 2 Oracle Data Guard Concepts and Administration manual and Oracle MetaLink note 186150. 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. bfile. and urowid. Once enabled. since LGWR is synchronously shipping redo information to the standby. nclob. On your primary database you enable the feature as follows: SQL> alter system set log_archive_dest_2='SERVICE=standby1 LGWR SYNC AFFIRM'.Stand By Your Data Guard
In contrast with a physical standby. For example. 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.
SQL> alter database add standby logfile ('/ora1/oradata/BRDSTN/sb_redo_02. offering more reliability These files can exist on raw devices. When you use standby redo logs. SQL> recover managed standby database disconnect. SQL> alter database set standby database protected. New with Oracle9i.------------.log') size 20M. In your standby environment.-----------------------.Stand By Your Data Guard
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. you get some interesting side benefits: • • Standby redo logs can setup with multiple members. standby redo logs are special redo logs that are required when you enable higher levels of data protection. To give you that fuzzy and warm feeling that you've set things up correctly. The last step involved in deploying Maximum Protection mode protection is to alter your primary database into protected mode: SQL> startup mount. on your primary select the new Oracle9i database role and mode columns now available in the v$database view:
www. On the standby. you create the logs as follows: SQL> alter database mount standby database. SQL> alter database open. 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'. Another important architectural aspect of the Maximum Protection mode is that the standby must use standby redo logs. SQL> alter database add standby logfile ('/ora1/oradata/BRDSTN/sb_redo_01.log') size 20M.rmoug. transmit_mode. TARGET STATUS STANDBY VALID PROCESS LGWR TRANSMIT_MOD AFF SYNCHRONOUS YES
To verify the role and protection mode. offering possible performance benefits
The standby redo logs must be of the same size as the primary online redo logs.---------. process. affirm from v$archive_dest where target='STANDBY' and status='VALID'. and must have at least two groups.org
RMOUG Training Days 2003
. on your primary query the v$archive_dest view: SQL> select target. status.
the missing archive log files are sent to the appropriate standbys. standby_mode from v$database. Once a gap is noticed. and once discovered. This method is automatic and does not need any special configuration.org
RMOUG Training Days 2003
. The first method for gap resolution is via a periodic background communication between the primary database and all of its standby databases. This situation will likely arise if there is a network problem or if the standby database is down for any reason. 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. if the primary log transport mechanism is not able to ship the redo data from the primary database to the physical standby database. Previously in Oracle8i. For example. An untimely gap resolution mechanism compromises the availability of data in the standby environment. this will most likely result in a loss of data after you failover to your standby database. Discovering and resolving archive log gaps is critical to enabling high availability.
Archive Gap Management
In a managed recovery configuration. you get nice improvements in the method that archive gaps are discovered and resolved. 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. 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. if you have an undetected gap.Stand By Your Data Guard
SQL> select database_role. and then disaster strikes. Data Guard compares log files created on the primary with log files received on the standby databases to detect the gaps. Data Guard has two methods for automatically detecting and resolving archive gaps.rmoug.
www. then you have a gap between what archive logs have been generated by the primary and what have been applied to the physical standby. In Oracle9i. you had the responsibility of monitoring for gaps. SQL> alter system set FAL_CLIENT = standby1.
dbf' size 5M. However. standby1 is the Oracle Net name of the standby database and primary1 is the Oracle Net name of the primary database. statements are automatically applied to the standby without DBA intervention. In the next example.rmoug. Data Guard automatically determined there was a gap and transmitted and applied the appropriate archived redo logs. In this scenario. Another advantage is that most DDL statements are supported. Again. in Oralce8i. timely gap resolution is critical to maintaining a high availability.. The primary database alert. the network was temporarily down. CREATE PACKAGE. The FAL processes use these parameters to determine the location of the physical standby and primary databases.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. 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. one shortcoming of Oracle8i is that tablespace and datafile add/drop operations are not propagated in an automated fashion.org
RMOUG Training Days 2003
. For example.
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.Stand By Your Data Guard
Once these initialization parameters are enabled on the standby database. 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. The new Fetch Archive Log (FAL) processes manage this automated gap detection and resolution.arc Media Recovery Log /ora1/oradata/BRDSTN/ar/arch_0001_000154. The FAL server process runs on the primary database server and services requests from the FAL client. With automatic gap detection and resolution. After the network came back up.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. Data Guard now automates a previously manual task. any CREATE USER. For example. etc. CREATE TABLE. you may add a datafile to your primary database: SQL> alter tablespace GOBR add datafile '/ora1/oradata/BRDSTN8/gobr02. the managed recovery process on the physical standby will automatically check and resolve gaps at the time archive redo is applied. and during the down time the primary generated two archived redo logs numbered 153 and 154.
When that command is propagated to the standby. One such option automates the delay in the application of archived redo logs to the physical standby. if you issue the following command on your primary:
SQL> drop tablespace SHOLAY including contents and datafiles.org
RMOUG Training Days 2003
. This relieves you from having to manually intervene with these critical physical DBA tasks. tablespace and datafile add/drop commands are automatically propagated to the standby environment. In your standby database issue the following command: SQL> alter system set standby_file_management = auto. The STANDBY_FILE_MANAGEMENT initialization parameter has no effect on datafile rename commands. With Oracle9i.rmoug. The idea being that with a delay. 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. New with Oracle9i. All you have to do is set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO. tablespace and datafile add/drop operations can be setup to be automatically propagated to the standby database. you now get many robust options for configuring your managed recovery environment.dbf'.
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.
www. While this isn't a huge inconvenience. 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. For example. Note: If you rename a datafile in Oracle9i. 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. 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. if somebody accidentally drops a table you will notice the problem before it has had time to make it to the physical standby database. From that point forward. 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. when enabling managed recovery mode. For example. you still must manually intervene. the SHOLAY tablespace will be dropped and the datafiles will be removed from disk.Stand By Your Data Guard
If you don't manually intervene before that statement is propagated to the standby.dbf' as '/ora1/oradata/BRDSTN8/gobr02.
These roles are mutually exclusive. 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. shutting it down. one for when it's in a primary role and one for when it's in a standby role. DATABASE_ROLE -----------------------PRIMARY A database switchover is a Data Guard feature that allows you to switch the role of a database. reverse (sometimes called a switchback) the database roles back to the original configuration. and maintain a manual delay process. 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. In a scenario like this. and thus the only way to put it back would be from a backup. If problems arise (and they will) you'll need to know some of the inner workings of
www. Note: Switchover should not be confused with database failover. 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. a database either has the role of a primary database or a standby database. 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. After the hardware maintenance is finished. say for hardware maintenance. To view the current role of your database: SQL> select database_role from v$database. This relieves you from having to script. You would only initiate a failover if your primary database was lost beyond hope.ora) for each database. you would switchover the primary to a standby role and switch the standby to the primary role. monitor.
In Data Guard.Stand By Your Data Guard SQL> recover managed standby database delay 60 disconnect. The Oracle9i switchover feature is useful when you need to take your primary database out of service. but are not applied until 60 minutes later. mounting it.rmoug. A failover is taking a standby database.org
RMOUG Training Days 2003
In this scenario the archive redo logs are immediately copied to the standby location as they become available. Performing a switchover should be a well-planned and practiced activity.
If you're just getting started with Oracle Data Guard. manage.
Use Alert Logs
As you deploy your Oracle Data Guard environment and perform maintenance operations. monitor. The most visible component of the broker is Data Guard Manager. 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. and automate tasks in your greater Data Guard environment.ora) that handle file name conversions. It is available in both Oracle9i and Oracle9i version 2.log files. 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. it's easier to implement if you: • • • Set up Oracle Data Guard with two different servers. In a Unix environment the tail command is particularly helpful in this regard:
www. Refer to the Oracle Data Guard Broker documentation for full implementation details. pertinent messages are often written to the primary and standby alert. Data Guard Manager is a screen-based. Having said that. 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. 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. You can use Data Guard Manager to automate many tasks in your Data Guard environment.Stand By Your Data Guard
your Data Guard environment. wizard driven tool invoked from Oracle Enterprise Manager (OEM).rmoug. Data Guard Broker is a comprehensive set of tools that you can use to create. When getting started with Oracle Data Guard. I recommend becoming familiar with manually implementing and maintaining an environment before using automated tools.log files. Thus. lay it onto your standby server without having to modify parameters in your spfile (or init. Data Guard Manager will be easy for you to use.org
RMOUG Training Days 2003
. maintain. The OEM Oracle9i version 2 edition of Data Guard Manager is particularly feature-rich. If you are familiar with OEM tools. 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.
Recovering standby MANUAL recover standby database. process.
Failover alter database mount standby database. nor does it show all options.log
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.
Read-only to managed recovery mode alter database close.transmit_mode. archiver.
Starting standby startup nomount.rmoug.
Viewing database role and mode select database_role. standby_mode from v$database.org
RMOUG Training Days 2003
. alter database activate standby database.affirm. alter database open read only. Pin these up on your cube wall so that you can concentrate on concepts rather than digging through manuals looking for syntax.status. alter database mount standby database. recover managed standby database.async_blocks.Stand By Your Data Guard $ tail -f alert_BRDSTN.type from v$archive_dest. This list is not comprehensive.
www. MANAGED recover managed standby database [disconnect|cancel]. but I've found it makes a good quick reference:
Creating standby controlfile alter database create standby controlfile as '<path>/<filename>'.
Placing physical standby in read-only alter database recover managed standby database cancel.
Viewing transaction protection level select target.
RMOUG Training Days 2003
www.Stand By Your Data Guard
Oracle Data Guard is a fully integrated feature of Oralce9i that enables you to build highly available database solutions. 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.