A Data Guard configuration consists of one primary database and up to nine standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located if they can communicate with each other. For example, you can have a standby
database on the same system as the primary database, along with two standby databases on another system.
The Data Guard broker logically groups these primary and standby databases into a broker configuration that allows the broker to manage and monitor them together as an integrated unit. You can manage a broker configuration using either the Oracle Enterprise Manager graphical user interface or the Data Guard command-line interface.
Oracle Data Guard is included with the Enterprise Edition and Personal Edition of the Oracle database software. A Data Guard configuration may be managed by using either SQL*Plus, or Data Guard broker's command-line interface (DGMGRL), or Oracle Enterprise Manager 10g Grid Control.
To use DGMGRL, the best practice is to install the Oracle Enter
prise Edition or Personal Edition database software on each location you expect to include in broker configurations. You must install Oracle Enterprise Manager 10g Grid Control to use the Enterprise Manager Web-based user interface for Data Guard.
The following conditions must be true before you can use the broker:
· The primary and standby databases must be running Oracle D
atabase 10g (10.2) and each can be installed in either a single-instance or multi-instance environment. The database must be licensed for Oracle Enterprise Edition or Personal Edition.
· You must use a server parameter file (SPFILE).
· The value of the DG_BROKER_START parameter must be set to TRUE for all instances in the configuration.
- After starting the Oracle instance, set the DG_BROKER_START=true initialization parameter using the SQL ALTER SYSTEM statement. The parameter value will be saved in the server parameter file. The next time you start the Oracle instance, the broker is started automatically, and you do not need to issue the SQL ALTER SYSTEM statement again.
· If any of the databases in the configuration is a RAC database, you must set up the DG_BROKER_CONFIG_FILEn initialization parameters for that database such that they point to the same shared files for all instances of that database. The shared files could be files on a cluster file system, if available, on raw devices, or stored using Automatic Storage Management (ASM).
· Oracle Net Services network files must be set up on the primary database and on the standby database if you configure an existing standby database into the broker configuration. Otherwise, Enterprise Manager automatically sets up the network files when it creates a standby database.
· If you are using a nondefault port number (for example, something other than port 1521) for the local listener address, you must set the LOCAL_
LISTENER initialization parameter on each instance that is part of a broker configuration to a listener address that is reachable by all members of the configuration.
- To enable DGMGRL to restart instances during the course of broker operations, a service with a specific name must be statically registered with the local listener of each instance. The value for the GLOBAL_DBNAME attribute must be set to a concatenation of db_unique_name_DGMGRL.db_domain.
For example, in the LISTENER.ORA file:
LISTENER = (DESCRIPTION =
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=host_name)
(PORT=port_num))))
SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME=sid_name)
(GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain)
(ORACLE_HOME=oracle_home)))
· Any database, including insta
nces of the database, managed by the broker must be mounted.
· If any of the databases in the configuration is a RAC database, the START_OPTIONS for that database must be set to MOUNT in the Oracle Cluster Repository (OCR) using srvctl as follows:
srvctl add database -d <db_unique_name> -o <$oracle_home> -s mount
or srvctl modify database -d -o <$oracle_home> -s mount · The primary database must be opened in ARCHIVELOG mode.
ATIBLE initialization parameter to 9.2.0.1.0 or higher for both the primary and standby databases. However, if you want to take advantage of new Oracle Database 10g features, set the COMPATIBLE parameter to 10.2.0.0.
Note : Ensure the COMPATIBLE initialization parameter is set to the same value on both the primary and standby databases. If the values differ, redo transport services may be unable to transmit redo data from the primary database to the standby databases.
Configuration Support:
The broker enables you to logically define a Data Guard configuration, consisting of a primary database and one or more standby databases. With the broker, you define a broker configuration that is a logical grouping of the databases, including redo transport services and log apply services. At the DBA's discretion, the broker controls the logical objects in the configuration, modifies their behavior at runtime, monitors the overall health of the configuration, and reports any health and other operational characteristics up through the Oracle Enterprise Management notification mechanisms if you are using Oracle Enterprise Manager, or through SHOW commands if you are using DGMGRL.
The Data Guard log apply services update s
tandby databases with redo data that is transmitted automatically from the primary database by redo transport services. The archived redo log files and standby redo log files contain all of the database changes except for unrecoverable or unlogged changes. On physical standby databases, Redo Apply applies the redo data to stay transactionally consistent with the primary database. On logical standby databases, SQL Apply applies the redo data to stay transactionally consistent with the primary database.
The broker's Data Guard monitor (DMON) process configures and maintains the broker configuration as a group of objects that you can manage and monitor as a single unit. Thus, when you enter a command that affects multiple databases, the DMON process:
· Carries out your req
uest on the primary database
· Coordinates with the DMON process for each of the other databases, as required for your request
· Updates the configuration file on the local system
· Communicates with the DMON process for each of the other databases to update their copies of the configuration file
·
Through the DMON process, you can configure, monitor, and control the databases and the configuration together as a unit. If you disable the configuration, broker management of all of the databases in the configuration is also disabled. If you later enable the configuration, broker management is enabled for each database in the configuration.
On the primary database, the figure shows the redo transport services in addition to the following main components: the primary database, DMON, the online redo log files, and the archived redo log files. The figure also shows standby redo log files in outline form on the primary side; the standby redo logs are outlined to indicate they are currently inactive but have been configured in preparation for a switchover to the standby role.The standby database includes the following components: a standby database, log apply services, DMON, archived redo log files, and standby redo log files. The online redo log files on the standby database are outlined to indicate they are currently inactive but have been configured in preparation for a switchover to the primary role.
We have assume the following broker configuration:
- The configuration name is Nitish_DR_Solution.
- The database unique name (DB_UNIQUE_NAME) of the primary database is Nitish_Production_Box.
- The database unique name (DB_UNIQUE_NAME) of the remote standby database is Nitish_DR_Box.
- The protection mode is maximum performance mode.
- There are no standby redo log files.
- The standby database is a physical standby database.
Creating a Configuration
Step 1 Invoke the Data Guard CLI.
To start the CLI, enter DGMGRL at the command-line prompt on a system where Oracle Data Guard is installed:
% DGMGRL
DGMGRL for Solaris: Version 10.1
Copyright (c) 2000, 2003, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL>
Step 2 Connect to the primary database.
Before you specify any command (other than the HELP, EXIT, or QUIT), you must first connect to the primary database using the DGMGRL CONNECT command.
The account from which you connect to the database (SYS in this example) must have SYSDBA privileges on the primary and standby databases.
Note:
You do not have to include AS SYSDBA on the CONNECT command because SYSDBA is the default setting for this command.
Example:
DGMGRL> CONNECT sys/change_on_install@Nitish_Production_Box.foo.com;
Connected.
Step 3 Create the broker configuration.
To create the broker configuration, you first define the configuration including a profile for the primary database, which in this case is called Nitish_Production_Box. In a later command, you will add a profile for the standby database, Nitish_DR_Box.
Note:
The names for the primary and standby databases must match their database unique names. Fetch these from their DB_UNIQUE_NAME initialization parameter as follows:
SQL> SHOW PARAMETER DB_UNIQUE NAME;
Use the CREATE CONFIGURATION command to create the Nitish_DR_Solution configuration and define the primary database, Nitish_Production_Box:
DGMGRL> CREATE CONFIGURATION 'Nitish_DR_Solution' AS
> PRIMARY DATABASE IS 'Nitish_Production_Box'
> CONNECT IDENTIFIER IS Nitish_Production_Box.foo.com;
The CLI returns the following information:
Configuration "Nitish_DR_Solution" created with primary database "Nitish_Production_Box"
The name Nitish_Production_Box is the value of this database's DB_UNIQUE_NAME initialization parameter.
Step 4 Show the configuration information.
Use the SHOW CONFIGURATION command to display a brief summary of the configuration:
DGMGRL> SHOW CONFIGURATION;
The CLI returns the following information:
Configuration
Name: Nitish_DR_Solution
Enabled: NO
Protection Mode: MaxPerformance
Databases:
Nitish_Production_Box - Primary database
Current status for "Nitish_DR_Solution":
DISABLED
Step 5 Add a standby database to the configuration.
To add a standby database to the Nitish_DR_Solution configuration, use the ADD DATABASE command to create a broker configuration profile for the standby database.
The following command defines Nitish_DR_Box as a standby database, which is the standby database associated with the primary database called Nitish_Production_Box:
DGMGRL> ADD DATABASE 'Nitish_DR_Box' AS
> CONNECT IDENTIFIER IS Nitish_DR_Box.foo.com
> MAINTAINED AS PHYSICAL;
The CLI returns the following information:
Database "Nitish_DR_Box" added.
The name Nitish_DR_Box is the value of the database's DB_UNIQUE_NAME initialization parameter.
Use the SHOW CONFIGURATION command to verify that the Nitish_DR_Box database was added to the Nitish_DR_Solution configuration:
DGMGRL> SHOW CONFIGURATION;
The CLI returns the following information:
Configuration
Name: Nitish_DR_Solution
Enabled: NO
Protection Mode: MaxPerformance
Databases:
Nitish_Production_Box - Primary database
Nitish_DR_Box - Physical standby database
Current status for "Nitish_DR_Solution":
DISABLED
Setting Database Properties
After you create the configuration with the CLI, you can set database properties at any time. For example, the following statements set the LogArchiveFormat and StandbyArchiveLocation properties for the Nitish_DR_Box standby database:
DGMGRL> EDIT DATABASE 'Nitish_DR_Box' SET PROPERTY 'LogArchiveFormat'='log_%t_%s_%r_%d.arc';Property "LogArchiveFormat" updated. DGMGRL> EDIT DATABASE 'Nitish_DR_Box' SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/';Property "StandbyArchiveLocation" updated. DGMGRL> SHOW DATABASE VERBOSE 'Nitish_DR_Box'; Database Name: Nitish_DR_Box Role: PHYSICAL STANDBY Enabled: NO Intended State: OFFLINE Instance(s): Nitish_DR_Box1 Properties: InitialConnectIdentifier = 'Nitish_DR_Box.foo.com' LogXptMode = 'ARCH' Dependency = '' DelayMins = '0' Binding = 'OPTIONAL' MaxFailure = '0' ReopenSecs = '300' AsyncBlocks = '2048' NetTimeout = '30' LogShipping = 'ON' PreferredApplyInstance = '' ApplyInstanceTimeout = '120' RealTimeApply = 'OFF' ApplyNoDelay = 'NO' ApplyNext = '0' ApplyParallel = 'AUTO' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '5' LogArchiveMinSucceedDest = '1' DbFileNameConvert = 'dbs/t, dbs/s2t' LogFileNameConvert = 'dbs/t, dbs/s2t' StatusReport = '(monitor)' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' HostName = 'dr.foo.com' SidName = 'Nitish_DR_Box1' LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=dr.foo.com)(PORT=1514))'StandbyArchiveLocation = '/archfs/arch/'
AlternateLocation = '' LogArchiveTrace = '4095'LogArchiveFormat = 'log_%t_%s_%r_%d.arc'
LatestLog = '(monitor)' TopWaitEvents = '(monitor)' Current status for "Nitish_DR_Box":DISABLED These properties map directly to the LOG_ARCHIVE_FORMAT and STANDBY_ARCHIVE_DEST initialization parameters. If broker management of the database is enabled, setting a database property value causes the underlying parameter value to be changed in the corresponding database, and the value for the changed parameter is reflected in the server parameter file. Thus, if the database is shut down and restarted outside of the Data Guard GUI and the CLI (such as from the SQL*Plus interface), the database uses the new parameter values from the updated server parameter file when it starts. However, you should not make changes to the log transport services initialization parameters through SQL statements. Doing so will cause an inconsistency between the database and the broker.
| Note: The database properties are typically displayed in mixed-case (for example, |
You can change a property if the database is enabled or disabled. However, if the database is disabled when you change a property, the change does not take effect until the database is enabled.
Enabling the Configuration and Databases
So far, the Nitish_DR_Solution configuration was disabled, which means it is not under the control of the Data Guard broker. When you finish configuring the databases into a broker configuration and setting any necessary database properties, you must enable the configuration to allow the Data Guard broker to manage it. This brings the primary and standby databases online.
You can enable:
- The entire configuration, including all of its databases
- A standby database
Enable the entire configuration.
You can enable the entire configuration, including all of the databases, with the following command:
Enabled.
Show the configuration.
Use the SHOW command to verify that the configuration and its databases were successfully enabled and brought online:
The CLI returns the following information:
Configuration
Name: Nitish_DR_Solution
Enabled: YES
Protection Mode: MaxPerformance
Databases:
Nitish_Production_Box - Primary database
Nitish_DR_Box - Physical standby database
Current status for "Nitish_DR_Solution":
SUCCESS
Enable the database.
This step is unnecessary except if the standby database was previously disabled with the DISABLE DATABASE command. Normally, enabling the configuration also enables the standby database.
DGMGRL> ENABLE DATABASE 'Nitish_DR_Box';
Enabled.
Show the database.
DGMGRL> SHOW DATABASE 'Nitish_DR_Box';
Database
Name: Nitish_DR_Box
Role: PHYSICAL STANDBY
Enabled: YES
Intended State: ONLINE
Instance(s):
Nitish_DR_Box1
Current status for "Nitish_DR_Box":
SUCCESS
Removing the Configuration or a Standby Database
When you use either the REMOVE CONFIGURATION or REMOVE DATABASE command, you effectively delete the configuration or standby database profile from the broker configuration file, removing the ability of the Data Guard broker to manage the configuration or the standby database, respectively.
A remove operation does not remove or delete the actual Data Guard configuration underneath, nor does it affect the operation of the actual Data Guard configuration and its databases.
Step 1 Remove a standby database from the configuration.
When you use the REMOVE DATABASE command, broker management and monitoring of the database ceases and the database's profile is deleted from the broker configuration file:
DGMGRL> SHOW CONFIGURATION;
Configuration
Name: Nitish_DR_Solution
Enabled: YES
Protection Mode: MaxPerformance
Databases:
Nitish_Production_Box - Primary database
Nitish_DR_Box - Physical standby database
Current status for "Nitish_DR_Solution":
SUCCESS
DGMGRL> REMOVE DATABASE 'Nitish_DR_Box';
The CLI returns the following message to indicate the command successfully removed the Nitish_DR_Box database information from the Data Guard configuration file:
Removed database "Nitish_DR_Box" from the configuration.
DGMGRL> SHOW CONFIGURATION;
Configuration
Name: Nitish_DR_Solution
Enabled: YES
Protection Mode: MaxPerformance
Databases:
Nitish_Production_Box - Primary database
Current status for "Nitish_DR_Solution":
SUCCESS
When running in either the maximum protection or maximum availability mode, the broker prevents you from deleting the last standby database that supports the protection mode.
Step 2 Remove the broker configuration.
Use the following command to remove the entire configuration from management and monitoring by the broker:
The CLI returns the following message to indicate the command successfully removed all of the configuration information from the Data Guard configuration file:
Removed configuration.
DGMGRL> SHOW CONFIGURATION;
Error: ORA-16532: Data Guard configuration does not exist
unable to describe configuration
Performing a Switchover Operation
You can switch the role of the primary database and a standby database using the SWITCHOVER command. Before you issue the SWITCHOVER command, you must ensure:
- The state of the primary and standby databases are online.
- All participating databases are in good health, without any errors or warnings present.
- The standby database properties were set on the primary database, so that the primary database can function correctly when transitioning to a standby database (shown in the following examples in boldface type).
- Standby redo log files on the primary database are set up, if necessary.
Step 1 Check the primary database.
Use the SHOW DATABASE VERBOSE command to check the state, health, and properties of the primary database, as follows:
DGMGRL> SHOW DATABASE VERBOSE 'Nitish_Production_Box'; Database Name: Nitish_Production_Box Role: PRIMARY Enabled: YES Intended State: ONLINE Instance(s): sales1 Properties: InitialConnectIdentifier = 'Nitish_Production_Box.foo.com'LogXptMode = 'ARCH'
Dependency = '' DelayMins = '0' Binding = 'OPTIONAL' MaxFailure = '0' ReopenSecs = '300' AsyncBlocks = '2048' NetTimeout = '30' LogShipping = 'ON' PreferredApplyInstance = '' ApplyInstanceTimeout = '120' RealTimeApply = 'OFF' ApplyNoDelay = 'NO' ApplyNext = '0' ApplyParallel = 'AUTO' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '5' LogArchiveMinSucceedDest = '1'DbFileNameConvert = 'dbs/s2t, dbs/t'
LogFileNameConvert = 'dbs/s2t, dbs/t'
StatusReport = '(monitor)' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' HostName = 'north.foo.com' SidName = 'sales1' LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=north.foo.com)(PORT=1514))'StandbyArchiveLocation = '/archfs/arch/'
AlternateLocation = '' LogArchiveTrace = '4095'LogArchiveFormat = 'r_%t_%s_%r.arc'
LatestLog = '(monitor)' TopWaitEvents = '(monitor)' Current status for "Nitish_Production_Box":SUCCESS
In particular, you should examine the boldface properties and the current status item, and some of the standby properties such as StandbyArchiveLocation, DbFileNameConvert, and LogFileNameConvert.
Step 2 Check the standby database that is the target of the switchover.
Use the SHOW DATABASE VERBOSE command to check the state, health, and properties of the standby database that is the target of the switchover. For example:
DGMGRL> SHOW DATABASE VERBOSE 'Nitish_DR_Box'; Database Name: Nitish_DR_Box Role: PHYSICAL STANDBY Enabled: YES Intended State: ONLINE Instance(s): Nitish_DR_Box1 Properties: InitialConnectIdentifier = 'Nitish_DR_Box.foo.com' LogXptMode = 'SYNC' Dependency = '' DelayMins = '0' Binding = 'OPTIONAL' MaxFailure = '0' ReopenSecs = '300' AsyncBlocks = '2048' NetTimeout = '30' LogShipping = 'ON' PreferredApplyInstance = '' ApplyInstanceTimeout = '120' RealTimeApply = 'OFF' ApplyNoDelay = 'NO' ApplyNext = '0' ApplyParallel = 'AUTO' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '5' LogArchiveMinSucceedDest = '1' DbFileNameConvert = 'dbs/t, dbs/s2t' LogFileNameConvert = 'dbs/t, dbs/s2t' StatusReport = '(monitor)' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' HostName = 'dr.foo.com' SidName = 'Nitish_DR_Box1' LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=dr.foo.com)(PORT=1514))' StandbyArchiveLocation = '/archfs/arch/' AlternateLocation = '' LogArchiveTrace = '4095' LogArchiveFormat = 'log_%t_%s_%r_%d.arc' LatestLog = '(monitor)' TopWaitEvents = '(monitor)' Current status for "Nitish_DR_Box":SUCCESS
In particular, you should examine the current status of the database.
Step 3 Issue the switchover command.
Issue the SWITCHOVER command to swap the roles of the primary and standby databases. The following example shows how the broker automatically shuts down and restarts the two participating databases as a part of the switchover.
DGMGRL> SWITCHOVER TO "Nitish_DR_Box";Performing switchover NOW. Please wait...Operation requires shutdown of instance "sales1" on database"Nitish_Production_Box".Shutting down instance "sales1"...ORA-01109: database not open Database dismounted.ORACLE instance shut down.Operation requires shutdown of instance "Nitish_DR_Box1" on database"Nitish_DR_Box".Shutting down instance "Nitish_DR_Box1"...database not mountedORACLE instance shut down.Operation requires startup of instance "sales1" on database "Nitish_Production_Box".Starting instance "sales1"...ORACLE instance started.Database mounted.Operation requires startup of instance "Nitish_DR_Box1" on database "Nitish_DR_Box".Starting instance "Nitish_DR_Box1"...ORACLE instance started.Database mounted.Switchover succeeded. New primary is "Nitish_DR_Box" After the switchover completes, use the SHOW CONFIGURATION and SHOW DATABASE commands to verify that the switchover operation was successful.
Step 4 Show the configuration.
Issue the SHOW CONFIGURATION command to verify that the switchover was successful.
DGMGRL> SHOW CONFIGURATION; Configuration Name: Nitish_DR_Solution Enabled: YES Protection Mode: MaxProtection Databases:Nitish_Production_Box - Physical standby database
Nitish_DR_Box - Primary database
Current status for "Nitish_DR_Solution":SUCCESS Performing a Failover Operation
You invoke a failover operation in response to an emergency situation, usually when the primary database cannot be accessed or is unavailable. The following scenario describes a failover to the remote database called Nitish_DR_Box.
Step 1 Connect to the target standby database.
To perform the failover operation, you must connect to the standby database to which you want to fail over using the SYSDBA username and password of that database. For example:
DGMGRL> CONNECT sys/knl_test7@Nitish_DR_Box.foo.comConnected. Step 2 Issue the failover command.
Now you can issue the failover command to make the target standby database the new primary database for the configuration. Note that after the failover completes, the original primary database cannot be used as a viable standby database of the new primary database unless it is re-created .The following example shows how the broker automatically shuts down and restarts the new primary database as a part of the failover.
DGMGRL> FAILOVER TO "Nitish_DR_Box";Performing failover NOW. Please wait...Operation requires shutdown of instance "Nitish_DR_Box1" on database"Nitish_DR_Box".Shutting down instance "Nitish_DR_Box1"...database not mountedORACLE instance shut down.Operation requires startup of instance "Nitish_DR_Box1" on database "Nitish_DR_Box".Starting instance "Nitish_DR_Box1"...ORACLE instance started.Database mounted.Failover succeeded. New primary is "Nitish_DR_Box" Step 3 Show the configuration.
Issue the SHOW CONFIGURATION command to verify the failover.
DGMGRL> SHOW CONFIGURATION; Configuration Name: Nitish_DR_Solution Enabled: YES Protection Mode: MaxPerformance Databases: Nitish_Production_Box - Physical standby databaseNitish_DR_Box - Primary database
Current status for "Nitish_DR_Solution":SUCCESS Step 4 Show the database.
Issue the SHOW DATABASE command to see that the old primary database was disabled by the broker as a consequence of the failover and it must be re-created.
DGMGRL> SHOW DATABASE 'Nitish_Production_Box'; Database Name: Nitish_Production_Box Role: PHYSICAL STANDBY Enabled: NO Intended State: ONLINE Instance(s): sales1 Current status for "Nitish_Production_Box":Error: ORA-16795: Database resource guard detects that database reinstantiation is required 
No comments:
Post a Comment