Download 9I DATA GUARD: TRUTH, MYTHS, AND FAILOVER 9i Data Guard

Reviewed by Oracle Certified Master Korea Community
( http://www.ocmkorea.com http://cafe.daum.net/oraclemanager )
9I DATA GUARD: TRUTH, MYTHS, AND FAILOVER
9i Data Guard Definitions
This white paper/presentation will hopefully explain some of the truths and myths about standby databases in Oracle 9i. We'll
start with some definitions:
•
Primary Database:
are being posted.
•
Standby Database:
This database is where you will failover/switchover (which will be covered later) in the event
the primary database becomes unavailable.
•
Data Guard:
Works with standby databases to protect your data against errors, failures and corruptions that might
otherwise destroy your database. It protects critical data by automating the creation, management and monitoring aspects
of a standby database environment. It automates the otherwise manual process of maintaining a transactionally consistent
copy of an Oracle production database for the purpose of recovering from the loss or damage to the production database.
Those of you who have worked with standby databases know what kind of a hassle it can be, manually moving logs along
with manually applying them to the standby database.
•
Data Guard Broker:
Just who is the broker guy? Well the Data Guard Broker is a distributed management
framework that automates and simplifies most of the complex operations required to create, control and monitor a Data
Guard configuration. Listed below are some of the things the broker can do:
This is your operating "production" database. The main database is where your transactions
•
Create local and remote standby databases
•
Configure, control and monitor log transport services
•
Configure, control and monitor log apply services
The broker is nothing more than a program that does the actions for you. You get access to the broker via the Data Guard
Manager. The broker monitors the activity, health and availability for all systems in the Data Guard configuration. There is
both a command-line and GUI version. As in most tools with Oracle, the command-line version works pretty much flawlessly
while the GUI still has some problems when trying to create a standby database or when trying to setup the configuration.
Operational Requirements
Here are some of the requirements for operating a standby database:
•
The primary database must run in ARCHIVELOG mode.
•
Use the same version and release of the operating system on the primary and standby sites. The standby site can, however,
use a different directory structure.
•
The hardware architecture on the primary and standby sites must be the same.
Paper #
•
Use the same version and release of the Oracle database server for the primary and standby databases.
•
Each primary and standby database must have its own control file.
•
Some operating systems will not allow you to mount two instances with the same database name on the same system
simultaneously in the event you place the primary and standby databases on the same system. Work arounds for this
situation exist for every platform. Specifically, you will need to use the init.ora parameter called lock_name_space.
Let's look at a standard configuration with two standby databases on different nodes.
Oracle 9i Data Guard Configuration
Configuration
Paper #
Paper #
This illustration shows a Data Guard configuration consisting of a primary site and two standby sites. At the top of the figure,
there are several terminals displayed to represent the clients and applications, and the user interfaces for managing the Data
Guard environment. The user interfaces shown include the Data Guard command-line interface (DGMGRL) and the Oracle
Data Guard Manager graphical user interface (which is part of Oracle Enterprise Manager, OEM).
On the primary site, the following main components are shown: the primary database, Oracle Data Guard broker, the online
redo logs, and the archived redo logs. This figure also shows the online redo logs archiving through an Oracle Net connection
to each standby site.
The standby site contains the following main components: a standby database, Oracle Data Guard broker, and the archived
redo logs.
Architecture Requirements:
The Oracle9i Data Guard architecture consists of the following components:
•
Primary database: A primary database is a production database. The primary database is used to create a standby
database. Every standby database is associated with one and only one primary database. A single primary database can,
however, support multiple standby databases. The redo logs associated with the primary database are archived to a
standby destination to be applied to the standby database.
•
Physical standby database: A physical standby database is a database replica created from a backup of a primary
database.
•
Log transport services: Log transport services control the automated transfer of archived redo logs from the primary
database to one or more standby sites or destinations.
•
Network configuration: The primary database is connected to one or more remote standby databases through Oracle
Net (used to be known as SQL*NET).
•
Log apply services: Log apply services apply the archived redo logs to the standby database.
•
Role management services: Controls the changing of database roles from primary to standby and back to primary. The
services include switchover and switchback, as well as database failover.
We’ve covered the initial setup requirements to build a standby database, let’s talk about the pieces/parts to make this happen
☺.
Building standby-database(s)
In preparation to build one or more standby databases, the decision has to be made on how many databases you will have and
where they’ll be located. Data Guard manager can support up to nine (9) standby databases for one primary database. These
Paper #
standby databases are separate and independent, and can reside on multiple systems or on a single system. But only one is
required.
Typically, you create a standby database for one or more of the following reasons:
•
Protection against the total destruction of the primary database
•
Protection against application corruption of the primary database
•
Supplemental reporting of data contained in the primary database
For maximum protection against data loss or corruption, maintain the standby database in managed recovery mode in a Data
Guard environment. In this setup, the primary database archives logs to the standby site, and the standby database
automatically applies these logs.
One crucial aspect of any Data Guard environment is archiving the redo logs from the primary site to the standby site. You
have two options for archiving the redo logs:
•
Configure the primary database to archive automatically to the standby site using log transport services
•
Archive the logs manually using operating system commands
When a primary database archives to a standby site, log transport services automatically archive the online redo logs through
Oracle Net to a directory on the standby site. As redo logs are generated on the primary database, log transport services
automatically archive them and log apply services apply them to each standby database. This allows standby databases to
remain synchronized with the primary database. Log transport services help minimize the latency between the primary and
standby databases by continuously capturing the modifications from the archived redo logs.
The primary database can continue to archive to the standby site even if the standby database is not in managed recovery mode,
but only if the standby instance is mounted. The mechanism for recovery of a standby database is independent of the
mechanism for automatic archival of redo logs to the standby site. Consequently, you can take a standby database out of
managed recovery mode and temporarily place it in read-only mode. While the standby database is in read-only mode, archived
redo logs continue to accumulate at the standby site.
Even if you configure the primary database to archive automatically to the standby site, you can still copy the completed
archived redo logs manually if the occasion requires it, but only if you have specified the standby site as an optional destination.
For example, assume that a problem with the Oracle Net configuration prevents the copying of archived redo logs to the
standby site. The primary database continues to archive locally, so you can copy the logs manually using operating system
commands, then perform manual recovery at the standby site to synchronize the standby database.
The directory structure of the various standby sites is important because it determines the path names for the standby datafiles
and redo logs. If you have a standby database on the same site as the primary database, you must use a different directory
structure; otherwise, the standby database attempts to overwrite the primary database files.
Use the same path names for the standby files if possible. This option eliminates the need to set filename conversion
parameters. Nevertheless, if you need to use a site with a different directory structure or place the standby and primary
databases on the same site, you can do so with a minimum of extra administration.
Paper #
Steps to build a standby database.
Setting up a standby database for managed recovery requires you to perform a series of different tasks. After you have
completed the preparation and initiated managed recovery, the standby database automatically and continuously applies redo
logs as they are received from the primary database. The figure below shows the pieces/parts of what a standby database
would look like.
Standby Database Creation
Here are the steps needed to build a standby database. The in-depth details of these can be found in the Oracle 9i Data Guard
Concepts and Administration Guide, Chapter 2.
1
Either make a new backup of the primary database datafiles or access an old backup.
2
Ensure the primary database is in ARCHIVELOG mode.
3
Connect to the primary database and create the standby control file.
Paper #
4
Copy the backup datafiles and control file from the primary site to the standby site.
5
Set the initialization parameters for the primary database.
6
Create the standby initialization parameter file and set the initialization parameters for the standby database. Depending
on your configuration, you may need to set filename conversion parameters.
7
Start the standby instance and mount the standby database.
8
Create standby redo log files, if necessary.
9
Manually change the names of the primary datafiles and redo logs in the standby control file for all files not automatically
renamed using DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT in step 7. If step 7 renamed all files, skip
this step.
10 Manually enable initialization parameter changes on the primary database so that it can initiate archival to the standby
site.
11 Use the Oracle Net Manager to configure a listener on the standby database. If you plan to manage this standby database
using the Data Guard broker, you must configure the listener to use the TCP/IP protocol and statically register the
standby database service using its SID.
12 Use the Oracle Net Manager to create a net service name that the standby database can use to connect to the primary
database. The net service name must resolve to a connect descriptor that uses the same protocol, host address, port, and
SID that you specified when you configured the listener on the primary database site. If you are unsure what values to use
for these parameters, run the Oracle Net Manager on the primary database site to display the listener configuration.
13 Use the Oracle Net Manager to create a net service name that the primary database can use to connect to the standby
database. The net service name must resolve to a connect descriptor that uses the same protocol, host address, port, and
SID that you specified when you configured the listener on the standby database site. If you are unsure what values to use
for these parameters, run the Oracle Net Manager on the standby database site to display the listener configuration.
Database Roles
So what are the various roles that the primary/standby database can be in? Basically a database is either a primary or a standby.
To switch between roles is known as role transition. A list of them will be helpful with definitions of each. Back in Oracle 8
days, you could activate a standby database but couldn’t go back without re-creating the original primary. Some things have
changed for the better.
Database Role Transitions
Method
Description
Paper #
Database
Switchover
You can switch a database role from primary to standby, as well as from standby to primary, without
resetting the online redo logs of the new primary database. No data is lost even when standby redo logs are
not configured.
No reinstantiation of the primary and standby databases is necessary.
Database
Switchback
This is a database switchover, performed in reverse, the results in the original primary database resuming the
primary role.
Graceful
Database
Failover
Database failover changes one of the standby databases into the role of primary database.
A graceful failover will automatically recover some or all of the original primary database application data
and therefore avoid reinstantiating other standby databases. If so, this is a graceful failover and it will be
necessary to reinstantiate only the original primary database as a standby database.
Forced Database Database failover changes one of the standby databases into the role of primary database.
Failover
A forced failover may result in lost application data even when standby redo logs are configured on the
standby database. You will need to reinstantiate the original primary database and all other standby
databases.
Role transition requires all instances whose roles have changed to be shut down and restarted before the new role becomes
effective.
This is a road map of the operations for transitioning.
Standby Database Road Map
Paper #
Database Switchover
You can switch a database role from primary to standby, as well as from standby to primary, without resetting the online redo
logs of the new primary database. This is known as a database switchover operation, instead of a failover operation, because
there is no loss of application data, and there is no need to reinstantiate the standby databases, including the other standby
databases not involved in the switchover operation.
On the primary database, the statement below is used to prepare the current primary database for switchover to the standby
role.
SQL>
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY
On one of the standby databases, the SQL “ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY” statement is
used to prepare the standby database for switchover to the primary role. Now when would this be appropriate? Possibly
when you are scheduled for a downtime on the primary machine. This is when this is most appropriate.
Database Switchback
This is a database switchover, performed in reverse, which results in the original primary database becoming a new primary
database. There is no actual database switchback operation. Use the switchover procedure instead.
Graceful Database Failover
Database failover changes one of the standby databases into the role of primary database. You should perform a standby
database failover only in the event of a software or system failure that results in the loss of the primary database. One of the
consequences of a graceful database failover is that the original primary database must be reinstantiated. However, the other
standby databases in the configuration do not need to be reinstantiated. This is what the original standby database concept
was all about, the original primary has to be rebuilt.
Forced Database Failover
Database failover changes one of the standby databases into the role of primary database. You should perform a standby
database failover only in the event of a software or system failure that results in the loss of the primary database. One of the
consequences of a forced database failover is that the original primary database and all other standby databases must be
reinstantiated. Another consequence is that there may be lost application data unless the standby and primary databases have
been configured to run in guaranteed protection mode.
Paper #
The SQL ”ALTER DATABASE ACTIVATE STANDBY DATABASE” statement changes the state of a standby database to an
active database and prepares it to become the primary database.
Data Guard Broker/Manager
The definitions for these two terms were defined previously in this paper. What will be defined here is the DMON process
and the command line interface. We will also lightly touch on the GUI interface.
The Data Guard monitor process (DMON) is an Oracle background process that runs on every site that is managed by the
broker. When you start the Data Guard monitor, a portion of the system global area (SGA) is allocated and a DMON process
is created.
Whether you use Data Guard Manager or the Command Line Interface (CLI) to manage an object, the DMON process is the
server-side component that interacts with the local instance and the DMON processes running on other sites to perform the
requested function. The DMON process is also responsible for monitoring the health of the broker configuration and for
ensuring that every site has a consistent copy of the binary configuration files in which the DMON process stores its
configuration data.
The next figure shows the DMON process among the several background processes that perform maintenance work for the
Oracle database server.
Oracle9i Broker Background Process
Paper #
The zigzag arrow in the center of previous figure represents the two-way Oracle Net communication channel that exists
between the DMON processes on sites in the same broker configuration.
This two-way communication channel is used to pass requests between sites, and to monitor the health of all of the sites in the
broker configuration.
The command line interface which is installed when Oracle 9i is installed (by default) is called DGMGRL and its located under
$ORACLE_HOME/bin. You don’t have to use the command line version (for those of you who are GUI fanatics) but it’s
helpful to know so if you don’t have access to an OEM console, you can still administer the databases.
Here is the example commands that we’re used to create a standby database from an existing primary database called “play”:
DGMGRL> create configuration 'Primary' as
primary site is 'MainDatabase'
resource is 'MainResource'
Paper #
hostname is 'laptop-jt'
instance name is 'play'
service name is 'play'
site is maintained as physical;
create site 'Secondary'
resource is 'SecondaryResource'
hostname is 'laptop-jt'
instance name is 'plaf'
service name is 'plaf'
site is maintained as physical;
alter resource 'SecondaryResource' set property LogArchiveDestOptions = '';
alter resource 'SecondaryResource' set property ArchiveDestDependency = '';
alter resource 'SecondaryResource' set property StandbyArchiveDest =
'/u01/oradata/plaf/arch';
enable configuration;
That was all there was to building the configuration to make the Data Guard monitor work (this all assumes you’ve built the
standby database, tested to make sure the logs were moving to the standby, etc
One last caveat, as much as I hate the (un)intelligent agent as the next, it is required to be running on all nodes for the
automated notification of errors, like the standby node went down, etc.
Paper #