Oracle9i Data Guard Concepts and Administration Release 1 (9.0.1) Part Number A88808-01 |
|
This appendix provides help troubleshooting a standby database. This appendix contains the following sections:
If you encounter a problem during standby database preparation, it will probably be one of the following:
If the STANDBY_ARCHIVE_DEST
initialization parameter is not defined as a valid directory name on the standby site, the Oracle database server will not be able to determine the directory in which to store the archived redo logs. Check the DESTINATION
and ERROR
columns in the V$ARCHIVE_DEST
view. For example, enter:
SQL> SELECT destination, error FROM v$archive_dest;
Make sure the destination is valid.
If the standby site is not receiving the logs, the first thing you should do is obtain information about the archiving status of the primary database by querying the V$ARCHIVE_DEST
view. Check especially for error messages. For example, enter:
SQL> SELECT dest_id "ID", 2> status "DB_status", 3> destination "Archive_dest", 4> error "Error" 5> FROM v$archive_dest; ID DB_status Archive_dest Error -- --------- ------------------------------ -------------------------------------- 1 VALID /vobs/oracle/work/arc_dest/arc 2 ERROR standby1 ORA-16012: Archivelog standby database identifier mismatch 3 INACTIVE 4 INACTIVE 5 INACTIVE 5 rows selected.
If the output of the query does not help you, check the following list of possible issues. If any of the following conditions is not met, the primary database will fail to archive to the standby site:
tnsnames.ora
file at the primary site.
LOG_ARCHIVE_DEST_
n
parameter of the primary initialization parameter file is incorrect.
LOG_ARCHIVE_DEST_STATE_
n
parameter specifying the state of the standby archiving destination has the value DEFER.
listener.ora
file has not been configured correctly at the standby site.
If any of the following conditions is not met, you cannot mount the standby database:
NOMOUNT
mode. You must first start the instance and then mount the database.
ALTER DATABASE CREATE STANDBY CONTROLFILE ...
statement or RMAN. You cannot use the following types of control file backups:
If you encounter a problem switching over from a primary database to a standby database, it will probably be one of the following:
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
failed with ORA-01093 error "Alter database close only permitted with no sessions connected".
This error occurs because the COMMIT TO SWITCHOVER
statement implicitly closed the database and, if there are any other user sessions connected to the database, the close fails.
Action: Make sure all user sessions are disconnected from the database. You can query the V$SESSION
fixed view to see what sessions are still around. For example:
SQL> SELECT SID, PROCESS, PROGRAM FROM v$session; SID PROCESS PROGRAM ---------- --------- ------------------------------------------------ 1 26900 oracle@dbuser-sun (PMON) 2 26902 oracle@dbuser-sun (DBW0) 3 26904 oracle@dbuser-sun (LGWR) 4 26906 oracle@dbuser-sun (CKPT) 5 26908 oracle@dbuser-sun (SMON) 6 26910 oracle@dbuser-sun (RECO) 7 26912 oracle@dbuser-sun (ARC0) 8 26897 sqlplus@dbuser-sun (TNS V1-V3) 11 26917 sqlplus@dbuser-sun (TNS V1-V3) 9 rows selected.
In the previous example, the first seven sessions are all server background processes. Among the two SQL*Plus sessions, one is the current SQL*Plus session issuing the query, and the other is an extra session that should be disconnected before the switchover operation.
Suppose the standby database and the primary database reside on the same site. After both the ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY
and the ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
statements are successfully executed, shut down and restart the standby database and the primary database. However, the startup of the second database fails with ORA-01102 error "cannot mount database in EXCLUSIVE mode."
This could happen during the switchover if you forget to set the LOCK_NAME_SPACE
parameter in the initialization parameter file that is used by the standby database (that is, the original primary database). If the LOCK_NAME_SPACE
parameter of the standby database is not set, the standby and the primary databases both use the same mount lock and cause the ORA-01102 error during the startup of the second database.
Action: Add LOCK_NAME_SPACE=
unique_lock_name
to the initialization parameter file used by the standby database and shut down and restart both the standby and the primary databases.
The archived redo logs are not applied to the standby database after the switchover.
This may happen because some environment or initialization parameters have not been properly set after the switchover.
Action:
tnsnames.ora
file at the primary site and the listener.ora
file at the standby site. There should be entries for a listener at the standby site and a corresponding tnsname at the primary site.
LOG_ARCHIVE_DEST_
n
initialization parameters have been set to properly archive logs from the primary site to standby site. For example, query the V$ARCHIVE_DEST
fixed view at the primary site as follows:
SQL> SELECT DEST_ID, STATUS, DESTINATION FROM v$archive_dest;
If you do not see an entry corresponding to the standby site, you need to set LOG_ARCHIVE_DEST_
n
and LOG_ARCHIVE_DEST_STATE_
n
initialization parameters.
STANDBY_ARCHIVE_DEST
and LOG_ARCHIVE_FORMAT
initialization parameters correctly at the standby site so that the archived redo logs are applied to the desired location.
DB_FILE_NAME_CONVERT
and LOG_FILE_NAME_CONVERT
initialization parameters. Set the STANDBY_FILE_MANAGEMENT
initialization parameter to auto
if you want the standby site to automatically add new datafiles that are created at the primary site.
|
![]() Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|