Results 1 to 6 of 6

Thread: Recover Standby Database2

  1. #1
    Join Date
    Apr 2006
    Posts
    6

    Recover Standby Database2

    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

  2. #2
    Join Date
    Apr 2006
    Posts
    3
    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;

  3. #3
    Join Date
    Apr 2006
    Posts
    6

    Question reply of gca's solution plz. read it carefully

    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

  4. #4
    Join Date
    Apr 2006
    Posts
    3
    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.

  5. #5
    Join Date
    Apr 2006
    Posts
    6

    problem during standby 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

  6. #6
    Join Date
    Apr 2006
    Posts
    3
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •