Oracle9i Data Guard Broker Release 1 (9.0.1) Part Number A88807-01 |
|
This chapter contains the following sections:
The most common and currently supported Data Guard configuration is a two-site configuration consisting of a primary database and a standby database at a location that can be local to, or remote from, the primary site.
A supported Data Guard configuration contains the following components:
The standby database is updated by archived redo logs that are shipped automatically from the primary database by means of log transport services. The archived redo logs contain a record of all of the database changes except for unrecoverable or unlogged changes. On the standby site, log apply services apply the archived redo logs to maintain synchronization with the primary database. Thus, the standby database can take over operations if the primary database becomes unusable.
A broker configuration is a logical grouping of the sites and database resources (including log transport services and log apply services) in a Data Guard configuration. The broker implements the DMON process that configures and maintains the broker configuration components as a unified group of resource objects that you can manage and monitor as a single unit. Thus, when you enter a command through Data Guard Manager or the CLI, the appropriate DMON process:
The broker carries out your requests against a hierarchy of objects that are dependent upon one another. For example, a database resource is dependent upon the site in which the resource resides, and the site is dependent upon the configuration. Thus, a site is the parent for a database resource and the configuration is the parent for a site.
This is important because when you request to take an object offline, its dependents will also be taken offline. For example, if a site is put in an offline state, the database that is dependent on the site will also be put in an offline state. Similarly, if the configuration is offline, all of the sites and resources in the configuration are also offline because all are logically dependent on the configuration. It is in this manner that the DMON process allows you to create, monitor, and control all of the aspects of the configuration together as a unit.
Figure 2-1 shows a broker configuration with the Data Guard monitor (DMON) process running on each site.
Table 2-1 provides a comparison of configuration management with and without the broker.
After installing the Oracle9i database server on each site in the configuration, the DRS_START
parameter must be set to TRUE
on each site to enable the DMON processes.
By default, the DRS_START
parameter is initially set to FALSE
in the initialization parameter file. However, its runtime value is determined as follows:
DRS_START
parameter is set to TRUE
automatically.
DRS_START
parameter to TRUE
; otherwise, the DMON process will not start. You can set the DRS_START
parameter either before or after you start the Oracle instance:
DRS_START=TRUE
record to the initialization parameter file.
DRS_START=TRUE
using the SQL ALTER SYSTEM
statement.
SQL> ALTER SYSTEM SET DRS_START=TRUE; System altered. SQL> SHOW PARAMETER DRS_START NAME TYPE VALUE ------------------------------------ drs_start boolean TRUE
Whether you use Data Guard Manager or the CLI, Oracle Corporation recommends that you edit the initialization parameter file on both sites to set the DRS_START=TRUE
parameter. Doing this ensures that the DMON processes will start automatically the next time you start the database.
The broker helps you to create a new configuration or manage an existing configuration. Figure 2-2 shows the life cycle of a broker configuration.
When using Data Guard Manager, the Create Configuration Wizard can either add an existing standby database into the configuration or create a new standby database and add it to the configuration.
When using the CLI, the primary database and a standby database must already exist. You construct the standby database from backups of the primary database control files and datafiles, and then prepare it for recovery.
A broker configuration, when first created, is in a disabled condition. This means its constituent objects are not under the control of the Data Guard monitor. When you finish configuring the sites and resources into a broker configuration, you must enable the configuration to allow the Data Guard monitor to manage the configuration.
You can enable:
The Data Guard monitor transitions the configuration, sites, and database resources into an online state, by default, the first time that you enable the configuration.
At any time, you can issue a single command through Data Guard Manager or the CLI to change the state of the entire configuration, or of a single site or database resource. For example, you could bring the primary database resource into an online, paused state to temporarily stop archiving logs to the standby database. Then, you simply issue another command to return the database resource to a full online state.
The Data Guard monitor allows you to set database properties that map directly to several of the database initialization parameters. You can change these properties to dynamically control such things as log archival, file management, log switching, and more.
You can check the health of the configuration, display and update the properties of the database resources, set Oracle Enterprise Manager events, and change the state to online or offline, as required. You can also coordinate failover and switchover operations outside of the broker.
.
A key concept of management with the broker is the notion of enabling and disabling objects in a broker configuration. The enable and disable operations are relevant only to the objects in a broker configuration; you cannot perform these operations on the physical components of a Data Guard configuration. This is because when you enable or disable an object in the broker configuration, you are effectively enabling or disabling the ability of the Data Guard monitor (DMON) process to:
However, enabling or disabling a broker configuration does not affect services and operations in the actual Data Guard configuration. For example, when you disable a broker configuration, log transport services and log apply services in the Data Guard configuration continue to function unchanged, but you can no longer manage them through the broker interfaces.
In addition, disabling an object does not remove or delete it from the Data Guard configuration file. You can re-enable your ability to manage with the broker using the CLI ENABLE
CONFIGURATION
, ENABLE SITE
, or ENABLE RESOURCE
commands, or the Enable/Disable
option in Data Guard Manager.
While enabled, a broker configuration, site, or database resource can be in one of two states: offline or online. The first time that you enable the broker configuration, each object is automatically entered into the following default state:
When the broker configuration is enabled, the configuration and all of the sites and database resources are also brought online automatically. In addition, note that the database resources' online states are further qualified by substates (opened in read/write mode and started and mounted).
The database resource substates are related to the role (primary or standby) in which the site is currently running. By default, the first time you enable the configuration and all of the objects are brought online, the database resources are put into the following substates:
READ-WRITE-XPTON
substate in the CLI. In Data Guard Manager, you can put the database in this state by selecting Online on the primary database property page.
PHYSICAL-APPLY-ON
substate in the CLI. In Data Guard Manager, you can put the database in this state by selecting Online on the standby database property page.
.
Chapter 3 for complete information about the online substates for the primary and standby database resources
See Also:
Running the broker configuration using the initial default online states described in this section will be fine, most of the time. However, there may be times when you want to change the state of one or more objects in the broker configuration. Section 2.6 describes state transitions in more detail.
When enabled, you can transition any object in the broker configuration into another valid state (or substate if it is a database resource), provided such a transition is allowed for the object. When you change the state of an object, you are effectively changing its current run-time state, which is sometimes referred to as its intended state.
State transitions occur when:
CLI ALTER
command) to bring the configuration, sites, or resources online or take them offline as necessary.
Enable/Disable
option or using the CLI ENABLE
command).
When a state change occurs, it only affects the current (intended) runtime state for the object; the default state is not altered. (Section 2.5 described the default state, which is the initial runtime state of an object when the broker configuration is first enabled.)
State transitions may result in a state change to multiple objects. You can request a state transition that affects only one resource, or you can change the state of the broker configuration and affect all of the sites and resources in the configuration. For example, when you change the broker configuration into an offline state, the configuration and all of its dependent sites and resources are also taken offline. The databases in the configuration will be closed and not mounted, log transport services will stop sending archived redo logs, and log apply services will stop applying redo logs to the standby database.
You can see information about the default and intended (current runtime) states by issuing the CLI SHOW
commands or viewing the General property page in Data Guard Manager. In Example 2-1, the SHOW RESOURCE VERBOSE
command displays the default and intended states and other information for the Sales_db database resource on site Boston. Notice that although the configuration was initially enabled in the READ-WRITE-XPTON (
default state)
, its current runtime (intended) state is READ-WRITE
with log transport services stopped.
DGMGRL> SHOW RESOURCE VERBOSE Sales_db ON SITE Boston;
The CLI returns the following information:
Resource Name: Sales_db Manager Type: internal Standby Type: PHYSICAL Online States: ONLINE PHYSICAL-APPLY-READY PHYSICAL-APPLY-ON READ-ONLY READ-WRITE READ-WRITE-XPTON Properties: INTENDED_STATE = 'READ-WRITE' ENABLED = 'yes' STATUS = 'SUCCESS' IGNORE_STATUS = 'no' LogArchiveDestOptions = '' ArchiveDestDependency = '' StandbyArchiveDest = '' LogArchiveTrace = '127' FalServer = '' FalClient = '' StandbyFileManagement = 'Manual' ArchiveLagTarget = '0' PrimaryLogSeqNumbers = '(monitor)' PrimaryLogTimes = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' SbyLogSeqNumbers = '(monitor)' SbyLogTimes = '(monitor)' SbyLogQueue = '(monitor)' Properties for 'PRIMARY' state: DEFAULT_STATE = 'READ-WRITE-XPTON' EXPLICIT_DISABLE = 'no' REQUIRED = 'yes' Properties for 'STANDBY' state: DEFAULT_STATE = 'PHYSICAL-APPLY-ON' EXPLICIT_DISABLE = 'no' REQUIRED = 'no'
A configuration status reveals the overall health of the configuration. In essence, the status indicates whether or not the configuration, site, or resource is in its intended state.
The following list describes the possible status modes for a configuration:
The configuration, including all of the resources configured within it, is operating in the mode specified by the user. All of the resources that are in an online state are operating properly without any warnings or errors.
One or more of the resources within the configuration is operating in the presence of a warning condition. To obtain specific information, locate each resource with the warning condition and examine its status. The specific warning status associated with the resource should reveal the source of the warning.
One or more of the resources within the configuration has failed to enter the state specified by the user. To obtain specific information, locate each resource with the error condition and examine its status. The specific error status associated with the resource should reveal the source of the problem.
There are two types of properties--configurable and monitorable:
Configurable properties affect the operation or configuration of the resource objects. You can change the value of these properties using the Data Guard CLI or Data Guard Manager. You can edit properties whether the configuration and its sites and database resources are enabled, disabled, online, or offline. However, if the state is disabled and/or offline, the new property value will not take affect until you enable the configuration or site or resource, as appropriate.
Monitorable properties allow you to view information related to resources, but you cannot change the value of these properties.
There are a number of configurable and monitorable properties that are common to most of the objects in a broker configuration. Table 2-2 lists common monitorable properties and the default values for each.
For example, to see these properties, you might use any of the SHOW
commands. The following example uses the SHOW SITE VERBOSE
command to display information about the Boston site:
DGMGRL> SHOW SITE VERBOSE 'Boston'; Site Name: 'Boston' Hostname: 'system1' Instance name: 'bstn' Service Name: 'primary' Standby Type: 'physical' Number Built-in Processes: '2' Enabled: 'yes' Required: 'yes' Default state: 'PRIMARY' Intended state: 'PRIMARY' Number of resources: 1 Resources: Name: Sales_db (default) (verbose name='Sales_db')
|
Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|