Hi All
can any body halp me in this situation, or if my message is not clear then please revert me back.
waiting for reply
regards
sahil
Printable View
Hi All
can any body halp me in this situation, or if my message is not clear then please revert me back.
waiting for reply
regards
sahil
I hope I understood the question correctly.
1) When there archive log gaps in the standby database.
2) Initial step for doing a switchover
3) Initial step for doing a failover
To check for archive log gaps:
1- On the standby database:
select count(*) from v$archive_gap;
2- Manually check the alert logs of both primary and standby datbases and match the log sequence numbers.
3. FAL errors in primary alert log indicationg log transport is failing and unable to connect to standby server.
To recover a standby database:
1. Manually copy all miissing archive log files from primary to standby server
2. ) Cancel managed recovery on standby database:
alter databae recover managed standby database cancel;
3.) Recover automatically:
recover automatic standy database;
4.) switch back to managed standby
recover managed standby database disconnect;
Hi Sir,
as you wote in your mail
select count(*) from v$archive_gap;
in my database the output is
SQL> select count(*) from v$archive_gap;
COUNT(*)
----------
0
alert log of Standby is looks like
Sat May 13 14:00:01 2006
ORA-1153 signalled during: ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE...
Sat May 13 14:30:00 2006
ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE
ORA-1153 signalled during: ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE...
Sat May 13 15:00:00 2006
ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE
ORA-1153 signalled during: ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE...
Alert log of Primary database
Sat May 13 12:46:47 2006
prod; ARC0: Creating local archive destination LOG_ARCHIVE_DEST_1: '/usr/backups/prod/logs/1_41257_529620177.dbf' (thread 1 sequence 41257)
ARCH: Connecting to console port...
Sat May 13 12:46:48 2006
prod; ARC0: Closing local archive destination LOG_ARCHIVE_DEST_1: '/usr/backups/prod/logs/1_41257_529620177.dbf'
ARCH: Connecting to console port...
Committing creation of archivelog '/usr/backups/prod/logs/1_41257_529620177.dbf'
Sat May 13 12:46:48 2006
prod; ARC0: Completed archiving log 2 thread 1 sequence 41257
ARCH: Connecting to console port...
but while i am runnning query like below:-
On Standby Database
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
40991
On Production Database
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
41258
Now, u please reply me if i will fallow all the steps given by you then what effect can be done on my database.
waiting for reply.
sahil
Your standby database is in managed recovery mode.
You can check it:
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS;
RECOVER
-------
MANAGED
If it is, cancel managed recovery mode:
alter database recover managed standby database cancel;
After that you can proceed with recovery.
i followed all steps written by you, but i got following error message
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
40991
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
40991
SQL> recover automatic standby database;
ORA-00279: change 126398781 generated at 05/09/2006 18:02:51 needed for thread
1
ORA-00289: suggestion : /usr/backups/prod/logs/1_40987_529620177.dbf
ORA-00280: change 126398781 for thread 1 is in sequence #40987
ORA-00278: log file '/usr/backups/prod/logs/1_40987_529620177.dbf' no longer
needed for this recovery
ORA-00308: cannot open archived log
'/usr/backups/prod/logs/1_40987_529620177.dbf''
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log
'/usr/backups/prod/logs/1_40987_529620177.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
i copied all archive log file from number 1_40991_529620177.dbf why it's asking for 1_40987_529620177.dbf'
if possible thwn please reply soon...............
regards
Anubhav
Manually Resolving a Gap:
=============================
In some rare cases it might be necessary to manually resolve gaps. The following section describes how to query the appropriate views to determine if a gap exists.
On your physical standby database:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Query the V$ARCHIVE_GAP view:
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
----------- ------------- --------------
1 333 336
The query results show that your physical standby database is currently missing logs from sequence 333 to sequence 336 for thread 1. After you identify the gap, issue the following SQL statement on the primary database to locate the archived redo logs on your primary database:
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND
2> SEQUENCE# BETWEEN 333 AND 336;
NAME
--------------------------------------------------------------------------------
/u01/oradata/arch/arch_1_333.arc
/u01/oradata/arch/arch_1_334.arc
/u01/oradata/arch/arch_1_335.arc
Copy the logs returned by the query to your physical standby database and register using the ALTER DATABASE REGISTER LOGFILE command.
SQL> ALTER DATABASE REGISTER LOGFILE
'/u01/oradata/stby/arch/arch_1_333.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/u01/oradata/stby/arch/arch_1_334.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/u01/oradata/stby/arch/arch_1_335.arc';
Once the log files have been registered in the standby controlfile, you can restart the MRP process and the standby database will 'catch up' with the the log gaps or you can manually recover the standby database.