Release 2 (9.2)
Part Number A96629-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Data Guard Broker Release 2 (9.2) Part Number A96629-01 |
|
This chapter provides several scenarios that show how to use the Data Guard command-line interface (CLI) to create, manage, and monitor a broker configuration.
This chapter describes the following scenarios:
DG_BROKER_START initialization parameter must be set to TRUE for all instances in the configuration. You also need to use a server parameter file (SPFILE) with the broker (see Section 7.1.3, "DGMGRL Command Usage Notes").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 (SPFILE). Then, the next time that you start the Oracle instance, the broker is started automatically and you do not need to issue the SQL ALTER SYSTEM statement again.
This scenario describes the creation of a physical standby database on a remote site. The following assumptions are being made:
To create your Data Guard configuration, you must construct the standby database from backups of the primary database control files and datafiles, and then prepare it for recovery. Oracle9i Data Guard Concepts and Administration provides detailed information about creating standby databases. However, the following list summarizes the steps:
| See Also:
Oracle9i Data Guard Concepts and Administration for detailed information about creating standby databases. |
tnsnames.ora and the listener.ora files as well as the startup of listeners on both primary and standby sites.CREATE SPFILE FROM PFILE='pfilename';
If an instance is not using a SPFILE, then you must shut down the instance and restart it using the SPFILE.
| See Also:
Oracle9i Database Administrator's Guide for detailed information about creating server parameter files (SPFILE) |
This section provides examples that create a broker configuration named Sales that includes a primary and standby site located in two different cities.
Each site in this configuration has a single database instance:
The following steps show how to create a configuration and add one physical standby site.
To start the CLI, enter DGMGRL at the command-line prompt on a system where Oracle9i Data Guard is installed:
% DGMGRL [options] DGMGRL for Solaris: Version 9.2.0.0.0 - Production. (c) Copyright 2002 Oracle Corporation. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL>
Before you specify any command (other than the HELP, EXIT, or QUIT command), 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 sites. You do not have to include AS SYSDBA on the CONNECT command because SYSDBA is the default setting for this command.
The following examples show two variations of the CONNECT command. Example 6-1 shows how to connect to the default database on the local system and Example 6-2 includes the Oracle Net service name (prmy) to make a connection to a database located on a remote system.
DGMGRL> CONNECT sys/change_on_install; Connected.
DGMGRL> CONNECT sys/change_on_install@primary; Connected.
To create the broker configuration, you first define the configuration including the primary site, which in this case is called Boston. In a later command, you will add the standby site, San Francisco.
Use the CREATE CONFIGURATION command to create the Sales configuration and define the primary site, Boston. The Boston site hosts a database resource called Sales_db.
DGMGRL> CREATE CONFIGURATION 'Sales' AS PRIMARY SITE IS 'Boston' RESOURCE IS 'Sales_db' HOSTNAME IS 'prmyhost1' INSTANCE NAME IS 'bstn' SERVICE NAME IS 'primary' SITE IS MAINTAINED AS PHYSICAL;
The CLI returns the following information:
Configuration "Sales" added with primary site "Boston" Database resource "Sales_db" added.
Use the SHOW CONFIGURATION command to display a brief summary of the configuration:
DGMGRL> SHOW CONFIGURATION;
The CLI returns the following information:
Configuration 'Sales' is Primary Site is 'Boston' Current status for "Sales": DISABLED
Use the SHOW CONFIGURATION VERBOSE command to display a detailed summary of the configuration:
DGMGRL> SHOW CONFIGURATION VERBOSE;
The CLI returns the following information that shows the broker configuration currently contains only the primary site:
Configuration Name: 'Sales' Enabled: 'no' Default state: 'ONLINE' Intended state: 'OFFLINE' Protection Mode: 'MaxPerformance' Number of sites: 1 Sites: Primary site: Boston Current status for "Sales": SUCCESS
To add a standby database site to the Sales configuration, use the CREATE SITE command.
The following command defines the San Francisco location as a standby site hosting a database resource called reportingdb, which is the standby database associated with the primary database called Salesdb.
DGMGRL> CREATE SITE 'San Francisco' RESOURCE IS 'reportingdb' HOSTNAME IS 'stdbyhost1' INSTANCE NAME IS 'sfdb' SERVICE NAME IS 'dest2' SITE IS MAINTAINED AS PHYSICAL;
The CLI returns the following information:
Site "San Francisco" added to configuration. Database resource "reportingdb" added.
Then, use the SHOW SITE VERBOSE command to verify that the San Francisco site was added to the Sales configuration:
DGMGRL> SHOW SITE VERBOSE 'San Francisco';
The CLI returns the following information:
Site Name: 'San Francisco' Hostname: 'system2' Instance name: 'sfdb' Service Name: 'dest2' Standby Type: 'physical' Number Built-in Processes: '2' Number Generic Processes: '0' Enabled: 'no' Required: 'yes' Default state: 'STANDBY' Intended state: 'OFFLINE' Number of resources: 1 Resources: Name: reportingdb (default) (verbose name='reportingdb')
After you create the configuration with the CLI, you can set database properties at any time. For example, the following SQL statement sets the LogArchiveFormat and StandbyArchiveDest properties for the reportingdb standby database resource:
DGMGRL> ALTER RESOURCE reportingdb ON SITE 'San Francisco' SET PROPERTY LogArchiveFormat='log_%t_%s.arc'; DGMGRL> ALTER RESOURCE reportingdb ON SITE 'San Francisco' SET PROPERTY StandbyArchiveDest = '/archfs/arch/';
These properties map directly to the LOG_ARCHIVE_FORMAT and STANDBY_ARCHIVE_DEST database initialization parameters. If the database resource is enabled, setting a database resource 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 SPFILE file. Thus, if the database is shut down and restarted outside of Data Guard Manager (such as from the SQL*Plus interface), the database uses the new parameter values from the updated SPFILE file when it starts. However, you should not make changes to the database dynamically through SQL statements. Doing so will cause an inconsistency between the database and the broker.
You can change a property if the database resource is enabled or disabled. However, if the database resource is disabled when you change a property, the change does not take effect until the database resource is enabled.
You can change the protection mode of the configuration at any time. However, it is best if you do this when there is no activity occurring in the configuration.
.|
Note: Sometimes the broker may need to restart instances within the configuration after the configuration is already enabled. For example, if the protection mode that is set on the database is different from what is set in the configuration. the broker will automatically restart the database instance. See Section 2.9 for information the steps required to change the protection mode for your configuration. |
This scenario sets the protection mode of the configuration to the MAXPROTECTION mode. Note that this protection mode requires that the broker configuration has at least one physical standby site configured to use standby redo logs.
Because we will be setting the protection mode to the MAXPROTECTION mode, it is important to ensure that sufficient standby redo logs are configured on the physical standby site.
Data Guard Manager provides the Standby Redo Log Assistant to configure standby redo logs automatically for you. If you are using the CLI, see Oracle9i Data Guard Concepts and Administration for information about creating standby redo logs.
Use the ALTER RESOURCE (property) command on the standby database to set the log transport mode that corresponds to the protection mode you plan to set. For example:
DGMGRL> ALTER RESOURCE 'reportingdb' ON SITE 'San Francisco' SET PROPERTY > LogXptMode=SYNC;
The broker will not allow this command to succeed unless there is a physical standby database configured with standby redo logs in the configuration.
Use the ALTER CONFIGURATION command to upgrade the broker configuration to the MAXPROTECTION protection mode.
DGMGRL> ALTER CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION; Operation requires restart of site "Boston" Shutting down site Boston... Database closed. Database dismounted. ORACLE instance shut down. Restarting site Boston... Started "Boston" as new primary
After you change the protection mode, the primary database will automatically restart.
Use the SHOW CONFIGURATION VERBOSE command to display the current protection mode for the configuration.
DGMGRL> SHOW CONFIGURATION VERBOSE; Configuration Name: 'Sales' Enabled: 'yes' Default state: 'ONLINE' Intended state: 'ONLINE' Protection Mode: 'MaxProtection' Number of sites: 2 Sites: Primary Site: Boston Standby Site: San Francisco Current status for "Sales": SUCCESS
If the configuration is disabled when you enter this command, the actual protection mode change is not applied until you enable the configuration with the ENABLE CONFIGURATION command. The broker will not allow you to enable the configuration if it does not find any standby database in the configuration that can support the requirements of the protection mode.
There may be situations in which you want to change the state or properties of the objects in a broker configuration to perform routine maintenance on one or more objects. You might also need to disable objects in a configuration when you want to transition the resources from a managed mode to a state of no longer being managed by the Data Guard broker.
As you monitor the configuration, you might need to dynamically modify the states of the resource objects and database properties. The following sections show how to change the state or properties of the objects in the configuration.
Taking an object offline should be done only when absolutely necessary, because it will perform a shutdown immediate and startup nomount on the database. If you take a configuration offline, all instances will be restarted when you bring the configuration online again. You can be connected through any database to change a Data Guard configuration to an offline state. You cannot change state of a configuration, site, or database resource object that is disabled.
Example 6-3 shows how to take all objects offline across the entire broker configuration.
DGMGRL> ALTER CONFIGURATION SET STATE = 'OFFLINE';
Section 6.3 described the database properties that must be set before the configuration is enabled. You can modify the values of database properties at any time--if the database is enabled, disabled, online, or offline.
Example 6-4 shows how to use the ALTER RESOURCE command to change the LogArchiveTrace property to the value 127 for the Sales_db database resource
DGMGRL> ALTER RESOURCE 'Sales_db' ON SITE 'Boston' > SET PROPERTY 'LogArchiveTrace'='127';
The CLI returns the following message to indicate that the LogArchiveTrace property was updated successfully in the Data Guard configuration file:
Property "LogArchiveTrace" updated
If the configuration is currently disabled, the database resource does not use the new property value until you enable the broker configuration with the ENABLE CONFIGURATION command.
You might want to use the standby database temporarily for reporting applications. To change the state of the standby database to read-only, enter the ALTER RESOURCE command as shown in Example 6-5.
DGMGRL> ALTER RESOURCE 'reportingdb' ON SITE 'San Francisco' > SET STATE='READ-ONLY';
Remember that when you put the standby database in the read-only state, it stops log apply services from applying the archived redo logs to the standby database.
By default, a site is in the same state as the configuration. However, you can use the ALTER SITE command (shown in Example 6-6) to restrict a site and its dependent database resources from going online when its parent configuration goes online.
DGMGRL> ALTER SITE 'Boston' SET STATE='Offline';
The CLI returns the following message to indicate that the command was successfully updated in the Data Guard configuration file:
Succeeded.
When you disable the broker configuration or any of its sites or resources, you are disabling the broker's management of those objects and are effectively removing your ability to use the CLI to manage and monitor the disabled object. However, disabling the broker's management of a broker configuration does not affect the actual operation of the underlying Data Guard configuration, its sites, or the database resources. For example, the log transport services and log apply services in the Data Guard configuration continue to function unchanged, but you cannot manage them with the CLI.
In addition, disabling the broker's management of an object does not remove or delete it from the Data Guard configuration file. You can re-enable your ability to use the CLI (or Data Guard Manager) to manage the object by entering the appropriate ENABLE CONFIGURATION, ENABLE SITE, or ENABLE RESOURCE command.
After you enter a DISABLE CONFIGURATION, DISABLE SITE, or DISABLE RESOURCE command, the CLI returns the following message to indicate that the command successfully updated the Data Guard configuration file:
Disabled.
You must use the DISABLE CONFIGURATION command to disable management of the entire broker configuration or that of the primary site as shown in Example 6-7.
DGMGRL> DISABLE CONFIGURATION;
The only way to disable broker management of the primary site is to use the DISABLE CONFIGURATION command; the DISABLE SITE command only disables management of a standby site.
|
Note: If you disable management of a configuration while connected to the standby database, you must connect to the primary database when you re-enable the configuration. |
You use the DISABLE RESOURCE command on the primary database or standby database when you no longer want to use the CLI to manage and monitor it. The DISABLE RESOURCE command disables broker management of the database, but it does not stop or change actual database operations (for example, log apply services) occurring in the Data Guard configuration. The command shown in Example 6-8 disables management of the reportingdb standby database.
DGMGRL> DISABLE RESOURCE reportingdb ON SITE 'San Francisco';
You use the DISABLE SITE command when you no longer want to use the CLI to manage and monitor a standby site and a standby database resource.
You can explicitly disable broker management of a standby site to prevent it from being brought online when the rest of the configuration is brought online. Example 6-9 shows how to disable the San Francisco standby site.
DGMGRL> DISABLE SITE 'San Francisco';
When running in either the maximum protection or maximum availability protection mode, the broker prevents you from disabling the last database resource or site that supports the protection mode.
When you use either the REMOVE CONFIGURATION or REMOVE SITE command, you effectively delete the configuration or standby site information from the Data Guard configuration file, removing the ability of the Data Guard broker to manage the configuration or the standby site, respectively.
A remove operation does not remove or delete the actual Data Guard configuration, nor does it affect the operation of the actual Data Guard configuration, its sites, or the database resources.
|
Caution: After you use the |
When you use the REMOVE SITE command, you remove the standby site and standby database from management and monitoring by the broker.
DGMGRL> REMOVE SITE 'San Francisco';
The CLI returns the following message to indicate that the command successfully removed the San Francisco site information from the Data Guard configuration file:
Removed site "San Francisco" from configuration.
Use the following command to remove the entire configuration from management and monitoring by the broker:
DGMGRL> REMOVE CONFIGURATION;
The CLI returns the following message to indicate that the command successfully removed all of the configuration information from the Data Guard configuration file:
Removed configuration.
You cannot remove the primary site unless the configuration is disabled. To remove the primary site when the configuration is enabled, you must remove the entire configuration. Also, when you remove a site, the broker verifies that it is the last site configured to meet the minimum requirements for the current protection mode. However, you can delete the configuration regardless of the protection mode.
| See Also:
Section 2.9, "Protection Modes" for more information about the broker manages objects to ensure support for protection modes |
So far, the Sales configuration has been disabled, which means it is not under the control of the Data Guard broker. When you finish configuring the sites and resources into a broker configuration and setting any necessary database properties (described in Section 6.3), you must enable the configuration to allow the Data Guard broker to manage the configuration, and so that you bring the primary and standby database systems online.
You can enable:
You can enable the entire configuration, including all of the sites and resources, with the following command:
DGMGRL> ENABLE CONFIGURATION; Enabled.
The configuration's default state is online.
Use the SHOW command to verify that the configuration and its resources were successfully enabled and brought online.
DGMGRL> SHOW CONFIGURATION VERBOSE;
The CLI returns the following information:
Configuration Name: 'Sales' Enabled: 'yes' Default state: 'ONLINE' Intended state: 'ONLINE' Protection Mode: 'MaxProtection' Number of sites: 2 Sites: Primary Site: Boston Standby Site: San Francisco
You can switch the role of the primary site and a standby site using the SWITCHOVER command. Before you issue the SWITCHOVER command, you must make sure:
READ-WRITE-XPTON and the state of the target standby database resource is PHYSICAL-APPLY-ON for a physical standby database resource or LOGICAL-APPLY-ON for a logical standby database resourcePerform the following steps:
Use the SHOW RESOURCE VERBOSE command to check the state and health of the primary database resource, as follows:
DGMGRL> SHOW RESOURCE VERBOSE 'Sales_db'; Resource Name: Sales_db Manager Type: internal Standby Type: PHYSICAL Online States: ONLINE PHYSICAL-APPLY-READY PHYSICAL-APPLY-ON READ-ONLY LOGICAL-APPLY-READY LOGICAL-APPLY-ON READ-WRITE READ-WRITE-XPTON Properties: INTENDED_STATE = 'READ-WRITE-XPTON' ENABLED = 'yes' IGNORE_STATUS = 'no' LogXptMode = 'ARCH' Dependency = '' Alternate = '' DelayMins = '0' Binding = 'OPTIONAL' MaxFailure = '0' ReopenSecs = '300' AsyncBlocks = '2048' LogShipping = 'ON' ApplyNext = '0' ApplyNoDelay = 'NO' ApplyParallel = '1' StandbyArchiveDest = '/dbs/a1' LogArchiveTrace = '4095' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '5' LogArchiveMinSucceedDest = '1' DbFileNameConvert = 'dbs/s2t, dbs/t' LogFileNameConvert = 'dbs/s2t, dbs/t' LogArchiveFormat = 'r_%t_%s.arc' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(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 = 'yes' Current status for "Sales_db": SUCCESS
In particular, you should examine the INTENDED_STATE property and the current status item, and some of the standby properties such as StandbyArchiveDest, DbFileNameConvert, and LogFileNameConvert. See Chapter 4 for information about managing database resources.
Use the SHOW RESOURCE VERBOSE command to check the state and health of the standby database resource that is the target of the switchover operation. For example:
DGMGRL> SHOW RESOURCE VERBOSE reportingdb; Resource Name: reportingdb Manager Type: internal Standby Type: PHYSICAL Online States: ONLINE PHYSICAL-APPLY-READY PHYSICAL-APPLY-ON READ-ONLY LOGICAL-APPLY-READY LOGICAL-APPLY-ON READ-WRITE READ-WRITE-XPTON Properties: INTENDED_STATE = 'PHYSICAL-APPLY-ON' ENABLED = 'yes' IGNORE_STATUS = 'no' LogXptMode = 'ARCH' Dependency = '' Alternate = '' DelayMins = '0' Binding = 'OPTIONAL' MaxFailure = '0' ReopenSecs = '300' AsyncBlocks = '2048' LogShipping = 'ON' ApplyNext = '0' ApplyNoDelay = 'NO' ApplyParallel = '1' StandbyArchiveDest = '/dbs/a2' LogArchiveTrace = '4095' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '5' LogArchiveMinSucceedDest = '1' DbFileNameConvert = 'dbs/t, dbs/s2t' LogFileNameConvert = 'dbs/t, dbs/s2t' LogArchiveFormat = 'r_%t_%s.arc' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(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 = 'yes' Current status for "reportdb2": SUCCESS
In particular, you should examine the INTENDED_STATE property and the current status of the resource.
Issue the SWITCHOVER command to swap the roles of the primary and standby sites. The following example shows how the broker automatically shuts down and restarts the two participating sites as a part of the switchover operation. (See the usage notes in Section 7.1.3 for information about how to set up the broker environment so that CLI can automatically restart the primary and standby sites for you.)
DGMGRL> SWITCHOVER TO 'San Francisco'; Performing switchover NOW. Please wait... Operation requires restart of site "Boston" Operation requires restart of site "San Francisco" Shutting down site Boston... database not mounted ORACLE instance shut down. Shutting down site San Francisco... database not mounted ORACLE instance shut down. Restarting site Boston... Restarting site San Francisco... Started "Boston" as standby Started "San Francisco" as new primary Switchover succeeded. New primary is "San Francisco"
After the switchover operation completes, use SHOW CONFIGURATION, SHOW SITE and SHOW RESOURCE commands to verify that the switchover operation was successful.
You invoke a failover operation in response to an emergency situation; usually when the primary site cannot be accessed or connected. See Section 3.2.2, "Managing Failover Operations" before you fail over to decide which standby site should be the target of the failover operation and which type of failover operation (graceful or forced) you want to perform.
If you must perform a failover operation, Oracle Corporation recommends that you always perform a graceful failover operation. The following scenario describes a graceful failover operation to the remote site called "San Francisco."
To perform the failover operation, you must connect to the standby site to which you want to fail over using the SYSDBA username and password of that site. For example:
DGMGRL> connect sys/change_on_install@dest2; Connected.
Now you can issue the failover command to make the target standby site the new primary site for the configuration. Note that after the failover operation completes, the original primary site cannot be used as a viable standby site of the new primary site. The following example shows how the broker automatically shuts down and restarts the new primary site as a part of the failover operation. (See the usage notes in Section 7.1.3 for information about how to set up the broker environment so that the CLI can automatically restart the new primary site and database for you.)
DGMGRL> FAILOVER TO 'San Francisco' GRACEFUL; Performing failover NOW. Please wait... Operation requires restart of site "San Francisco" Shutting down site San Francisco... database not mounted ORACLE instance shut down. Restarting site San Francisco... Started "San Francisco" as new primary Failover succeeded. New primary is "San Francisco" You have now finished failover. You can use SHOW CONFIGURATION, SHOW SITE and SHOW RESOURCE commands to check if the failover operation is successful.
The scenario in this section demonstrates how to use SHOW commands to view database monitorable properties, and identify and resolve a failure situation.
Assume that a failure occurred when the primary database attempted to transport an archived redo log to the standby site. To identify the failure, examine the LogXptStatus (log transport status) property to see the error status of log transport services for the standby site. Use the following command at the DGMGRL command-line prompt:
DGMGRL> SHOW RESOURCE 'Sales_db' LogXptStatus; LogXptStatus = 'San Francisco=ORA-16049: simulated error on archivelog write'
This LogXptStatus property indicates that the error ORA-16049 has been returned during a write operation to the standby site, San Francisco.
To obtain additional information, use the SHOW LOG ALERT LATEST command to view the database alert log on the primary site, Boston. For example:
DGMGRL> SHOW LOG ALERT LATEST ON SITE 'Boston';
The command returns the following output:
-------------------------------------------------------------------------------- 7590 Transmitting activation ID 1332649663 (4f6e9ebf) 7591 ARCH: Completed archiving log# 1 thrd# 1 seq# 737 7592 Fri Jan 19 16:23:26 2001 7593 Completed checkpoint up to RBA [0x2e2.2.10], SCN: 0x0000.0000df8d 7594 Fri Jan 19 16:25:07 2001 7595 Beginning log switch checkpoint up to RBA [0x2e3.2.10], SCN:0x0000.0000df91 7596 Fri Jan 19 16:25:07 2001 7597 ARCH: Beginning to archive log# 2 thrd# 1 seq# 738 7598 Fri Jan 19 16:25:07 2001 7599 Thread 1 advanced to log sequence 739 7600 Current log# 1 seq# 739 mem# 0: /vobs/oracle/dbs/t_log1.f 7601 Fri Jan 19 16:25:07 2001 7602 ARC0: Beginning to archive log# 2 thrd# 1 seq# 738 7603 ARC0: Unable to archive log# 2 thrd# 1 seq# 738 7604 Log actively being archived by another process 7605 Fri Jan 19 16:25:07 2001 7606 Transmitting activation ID 1332649663 (4f6e9ebf) 7607 Transmitting activation ID 1332649663 (4f6e9ebf) 7608 ARCH: I/O error 16049 archiving log 2 to 'standby1' 7609 ARCH: Completed archiving log# 2 thrd# 1 seq# 738
In the example, lines 7603 through 7609 (in boldface type) show that the archiver process (ARCn) failed to transmit log file 738 to the standby archive destination identified as standby1. This is probably because an I/O error occurred when archiving the redo log to the standby site.
To determine the severity of this failure and its effect on the integrity of the Data Guard configuration, use the following commands to examine the state of the archived redo logs from the perspective of both the primary and standby sites.
SendQEntries (send queue entries) property on the primary database, Sales_db. The SendQEntries property shows the archive status of all of the log files on the primary site:
DGMGRL> SHOW RESOURCE 'Sales_db' SendQEntries; PRIMARY_SEND_QUEUE SITE_NAME STATUS LOG_SEQ TIME_GENERATED TIME_COMPLETED San Francisco ARCHIVED 738 01/19/2001 16:23:23 01/19/2001 16:25:07 CURRENT 739 01/19/2001 16:25:07
The output shows that log 738 has been archived locally on the primary site but has not yet shipped to the San Francisco standby site.
SbyLogQueue (standby log queue) property to view the archived redo logs that have been received by the standby site, but have not been applied to the standby database, reportingdb:
DGMGRL> SHOW RESOURCE 'reportingdb' SbyLogQueue; STANDBY_RECEIVE_QUEUE LOG_SEQ TIME_GENERATED TIME_COMPLETED 738 01/19/2001 16:23:23 01/19/2001 16:25:07
DGMGRL> SHOW RESOURCE VERBOSE 'Sales_db' SendQEntries; DGMGRL> PRIMARY_SEND_QUEUE SITE_NAME STATUS LOG_SEQ TIME_GENERATED TIME_COMPLETED San Francisco ARCHIVED 738 01/19/2001 16:23:23 01/19/2001 16:25:07 San Francisco ARCHIVED 740 01/19/2001 16:31:26 01/19/2001 16:32:33 CURRENT 745 01/19/2001 16:51:55 DGMGRL> SHOW RESOURCE VERBOSE 'reportingdb' SbyLogQueue; DGMGRL> STANDBY_RECEIVE_QUEUE LOG_SEQ TIME_GENERATED TIME_COMPLETED 738 01/19/2001 16:23:23 01/19/2001 16:25:07 739 01/19/2001 16:25:07 01/19/2001 16:31:26 740 01/19/2001 16:31:26 01/19/2001 16:32:33 741 01/19/2001 16:32:33 01/19/2001 16:36:28 742 01/19/2001 16:36:28 01/19/2001 16:41:36 743 01/19/2001 16:41:36 01/19/2001 16:46:41 744 01/19/2001 16:46:41 01/19/2001 16:51:55
As you can see, the problem is not resolving itself. The primary send queue contents shown by the SendQEntries property show that logs 738 and 740 have not been successfully archived to the standby destination. The initial failure with transporting log 738 to the standby has caused log apply services on the standby database to fall behind the primary database. The output for the SbyLogQueue property shows that the standby database receive queue grows with every new archived redo log sent by the primary database.
The failure resulted in only a portion of log 738 being written to the standby database destination.
The final step in this process is to examine the database alert log on the standby site to determine a possible solution to the problem. The following command allows you to view the latest entries in the database alert log for the standby site.
DGMGRL> SHOW LOG ALERT LATEST ON SITE 'San Francisco'; --------------------------------------------------------------------------------
7571 Fri Jan 19 16:21:15 2001 7572 Media Recovery Log /vobs/oracle/dbs/stdby_1_736.arc 7573 Media Recovery Waiting for thread 1 seq# 737 7574 Fri Jan 19 16:23:30 2001 7575 Media Recovery Log /vobs/oracle/dbs/stdby_1_737.arc 7576 Media Recovery Waiting for thread 1 seq# 738 7577 Fri Jan 19 16:25:15 2001 7578 Media Recovery Log /vobs/oracle/dbs/stdby_1_738.arc 7579 Fri Jan 19 16:25:15 2001 7580 Errors in file /vobs/oracle/rdbms/log/stdby1_mrp0_28842.trc: 7581 ORA-00311: cannot read header from archived log 7582 ORA-00334: archived log: '/vobs/oracle/dbs/stdby_1_738.arc' 7583 ORA-27091: skgfqio: unable to queue I/O 7584 ORA-27072: skgfdisp: I/O error 7585 SVR4 Error: 25: Inappropriate ioctl for device 7586 Additional information: 1 7587 MRP0: Background Media Recovery failed with error 311 7588 Recovery interrupted. 7589 Recovered data files restored to a consistent state at change 270314464672. 7590 MRP0: Background Media Recovery process is now terminated
This output from the database alert log shows that a fatal error reading log 738 (the corrupted log file) has resulted in the shutdown of the background Media Recovery Process. For this reason, no other archived redo logs have been applied to the standby database. The errors are shown in boldface type in the example.
The solution is to manually copy logs 738 and 740 from the primary site to the standby site. Then, the next log file that is sent automatically to the standby site should trigger the application of all of the log files waiting in the standby queue to the standby database.
If this does not fix the problem, you might need to take the standby database resource offline and then put it back online again.
The ALTER RESOURCE command in the following example changes the state of the reportingdb database resource to offline and then back into an online state.
DGMGRL> ALTER RESOURCE 'reportingdb' ON SITE 'San Francisco' SET STATE='offline'; Succeeded. DGMGRL> ALTER RESOURCE 'reportingdb' ON SITE 'San Francisco' SET STATE='PHYSICAL-APPLY-ON';
|
 Copyright © 2000, 2002 Oracle Corporation. All Rights Reserved. |
|