# Database Discussions > Oracle >  Recover Standby Database2

## anubhav singh

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

----------


## gca

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;

----------


## anubhav singh

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

----------


## gca

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.

----------


## anubhav singh

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

----------


## gca

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.

----------

