| Oracle® Data Guard Broker 10g Release 1 (10.1) Part Number B10822-01 |
|
|
View PDF |
| Oracle® Data Guard Broker 10g Release 1 (10.1) Part Number B10822-01 |
|
|
View PDF |
This chapter describes various errors and how to solve them. This chapter contains the following topics:
Section 9.3, "Troubleshooting Problems During a Failover Operation"
Section 9.4, "Troubleshooting Problems During a Switchover Operation"
The Data Guard broker provides information about its activities in several forms:
Database status information (see Section 3.7)
Oracle alert log files
The broker records key information in the alert log file for each database. You can check the alert log files for such information when troubleshooting Data Guard.
Data Guard "broker log" files
For each database in a broker configuration, the broker monitor processes record important behavior and status information in a "broker log" file. The broker log file is maintained as follows for a UNIX environment:
$ORACLE_HOME/rdbms/log/drc*.log
This section describes general problems and solutions. This section contains the following topics:
ORA-16596: Database is Not a Member of the Data Guard Configuration
Log Files Are Being Accumulated on the Primary and Not Archived to Some Standby Databases
Many Log Files Are Received on a Standby Database But Not Applied
A request was issued to the broker, but the database instance through which you have connected is no longer a part of the broker configuration. You may see this error when the broker monitor (DMON) fails to locate a broker configuration profile for the database upon which it is running.
Reconnect to the configuration through another database instance. Confirm that the value of the DB_UNIQUE_NAME initialization parameter for the database and the database object name in the broker configuration are identical.
This problem can also occur if you attempt to enable a configuration, but the broker configuration file for one of its databases was accidentally removed or is outdated. In this case, remove the database from the broker configuration, manually delete the configuration file for that standby database (not for the primary database), and try again to enable the configuration. After the configuration is enabled, run the Add Standby Database wizard and choose the Add existing standby database option to create a new database profile for the previously deleted standby database.
By viewing the Log File Details page for the Data Guard GUI, you have determined that log files are accumulating on the primary database and are not being archived to some of the standby databases in the broker configuration.
To narrow down the problem, do the following:
Verify that the state of the primary database is ONLINE (not LOG-TRANSPORT-OFF).
Verify that the value of the LogShipping property of the standby database in question is ON.
Check the status of the primary database log transport services. If log transport services have an error, use the error message to determine further checking and resolution action. For example:
If the error indicates the standby database is not available, you need to restart the standby database.
If the error indicates no listener, you need to restart the listener.
If the error indicates the standby database has no local destination, you need to set up a standby location to store archived redo log files from the primary database.
By viewing the Performance page or Log File Details page for the Data Guard GUI, you have determined that the standby database accumulates too many log files without applying them.
There are many possible reasons why archived redo log files might not be applied to the standby database. Investigate why the log files are building up and rule out the valid reasons.
Determine whether or not the log apply services might be unexpectedly offline. See the ORA-16766 (for physical standby databases) or ORA-16768 (for logical standby databases) problem and solution statement for more help.
If this is a logical standby database, check to see if a failed transaction has occurred.
If you want to suppress the error while you investigate the problem, you can temporarily disable broker management of the database.
Verify the state of the standby database is online (not in the LOG-APPLY-OFF, OFFLINE, or READ-ONLY states).
Verify the state of the primary database is online (not in the LOG-TRANSPORT-OFF state).
Check to see if log files are building up because the value of the DelayMins property is set too large. (Log apply services will delay applying the archived redo log files on the standby database for the number of minutes specified.)
If you cannot see any errors, compare the archive rate to the apply rate on the Performance page in the Data Guard GUI to see if the apply rate is lower than the archive rate.
If the primary database is flashed back, the standby databases in the configuration are disabled by the broker because they are no longer viable as standbys in their current state. If the standby database has applied logs beyond the point to which the primary was flashed back, and the flashback feature is enabled on this standby database, you can restore their viability as standby databases by flashing them back to the same point or to an earlier point. Then, reenable them within the broker configuration as follows:
DGMGRL> ENABLE DATABASE <db_unique_name>;
For more information about restoring the viability of a standby database that was disabled by the broker, see Section 4.2.5.
Although it is possible for a failover to stop, it is unlikely. If an error occurs, it is likely to happen when the standby database is transitioning to the primary role. If the error status indicates that this problem occurred, use these general guidelines to fix the problem:
Investigate the error information provided by the broker to find the source of the problem and correct it.
Perform the failover again.
The following problems may occur during a failover operation:
The primary database is still running. The Data Guard GUI tries to detect if the primary database is still running. However, if the primary database is still running and the Data Guard GUI cannot detect that it is running, the failover will not be successful.
If the primary database is still running but can no longer function as a primary database, shut it down and retry the failover.
If the switchover fails due to problems with the configuration, the broker reports any problems it encounters in the alert log files or in the broker log files (see Section 9.1). In general, you can choose another database for the switchover or restore the configuration to its pre-switchover state and then retry the switchover. The following subsections describe how to recover from the most common problems.
If the error status indicates a problem when transitioning the original primary database to the standby role (including stopping log transport services and starting log apply services), use these general guidelines to recover:
Disable the configuration using the CLI.
|
Note: You can enable or disable the configuration using the CLI. You cannot disable the configuration using the Data Guard GUI. You can enable the configuration using the Data Guard GUI in the event that it was previously disabled using the CLI. |
Investigate the error message returned by the broker to find the source of the problem on the primary database and correct it. Oracle Enterprise Manager provides an Alert Log Content link for viewing alert log file information. You may also examine the contents of the broker log file for the primary database.
Reenable the configuration to refresh and restore the databases to their original roles and states.
Perform the switchover again.
If the error status indicates that a problem occurred when transitioning the target standby database to the primary role (including stopping log apply services and starting log transport services), use these general guidelines to restore to the pre-switchover state.
Step 1 Analyze and correct the detected failure.
Disable the configuration using the CLI.
|
Note: You can enable or disable the configuration using the CLI. You cannot disable the configuration using the Data Guard GUI. You can enable the configuration using the Data Guard GUI in the event that it was previously disabled using the CLI. |
Investigate the error messages returned by the broker to find the source of the problem on the standby database and correct it. Examine the alert log file information and the contents of the broker log file for the target standby database.
Step 2 Convert back to a primary database.
The original primary database was already converted to a standby database by the time this stage of the switchover is reached. The database must be converted back to being a primary database as follows:
Ensure the original primary database is at least mounted. A restart may be necessary:
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT
Execute the following SQL*Plus command to convert the database back to running in the primary database role:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Restart the database if necessary. The database is now in its former role as a primary database.
Additional steps may be needed to allow any logical standby databases in the configuration to accept and apply redo logs from this primary database. See Oracle Data Guard Concepts and Administration for these steps.
Step 3 Finish the recovery.
Reenable the configuration.
Perform the switchover operation again.
The switchover fails due to problems with log transport services.
Verify the state and status of the standby database by viewing its information on the Data Guard Overview page.
Run the Verify operation after the switchover completes to examine the alert log file of the new primary database and to verify the status of the configuration.
The switchover may fail during verification checks done by Data Guard broker (for example, log transport services might return errors on a database that is involved in the switchover).
Choose another database for the switchover or fix the problem by transporting the archived redo log files.
|
 Copyright © 2000, 2003 Oracle Corporation All Rights Reserved. |
|
