Error while performing failover in Dataguard configuration

Posted on 2008-11-14
Last Modified: 2013-12-19
I have one configuration where i have one primary and two physical standby databases...
primary database is working in Maximum availability modes.. standby redo logs are set on all three databases.
to check one of my standby databases can take over primary role , i am trying to mock the primary database failure by disconnecting one of my standby database from network.. and making that standby database primary by performing following steps

SQL>alter database recover managed standby database finish;

Database altered
SQL>alter database commit to switchover to primary;

this statement gave me error
"Media recovery required"

and failover failed...

in alert log file i can see the following

alter database recover managed standby database finish
Terminal Recovery: request posted
Fri Nov 14 23:46:02 2008
Warning: log 4 of thread 1 is being archived or modified
MRP0: Background Media Recovery terminated with error 261
Fri Nov 14 23:46:02 2008
Errors in file /oracle/admin/dar/bdump/dar_mrp0_196840.trc:
ORA-00261: log 4 of thread 1 is being archived or modified
ORA-00312: online log 4 thread 1: '/std_loga/log01a.log'
ORA-00312: online log 4 thread 1: '/std_logb/log01b.log'
Recovery interrupted.
MRP0: Background Media Recovery process shutdown
Fri Nov 14 23:46:03 2008
Terminal Recovery: completion detected
Completed: alter database recover managed standby database fi
Fri Nov 14 23:46:03 2008
alter database commit to switchover to primary
Database not recovered through End-Of-REDO
Database not recovered through End-Of-REDO
Switchover: Media recovery required - standby not in limbo
ORA-16139 signalled during: alter database commit to switchover to primary...

the strange thing is.. if i do this two three times , it will succeed once...

any ideas why it is happening?
Question by:aiklamha
    1 Comment
    LVL 47

    Accepted Solution

    Oracle docs say:

    Canceling Managed Recovery
    Cancel the managed recovery operation at any time by issuing either of the
    following SQL*Plus statements:
    The first statement waits for the managed recovery operation to finish with the
    current redo log before terminating recovery. If you use the IMMEDIATE option,
    however, Oracle stops the managed recovery operation either before reading
    another block from the redo log or before opening the next redo log file, whichever
    comes first.  

    Activating a Standby Database
    You should not activate or perform a failover to the standby database except in an
    emergency. After it is activated, the standby database becomes a normal production
    database and loses its standby functionality. You cannot undo the activation and
    return the database to standby mode.
    Depending on the nature of the emergency, you may not have access to your
    primary database files. If you do have access, then you should attempt to archive
    the current online redo log on the primary database manually, and then transfer and
    apply all available archived redo logs to the standby database.
    See Also: For more information about using tempfiles and
    temporary tablespaces, see the Oracle8i Administrators Guide.
    See Also: For CREATE TEMPORARY TABLESPACE syntax, see
    the Oracle8i SQL Reference.
    Note: You should not activate a standby database to test whether
    it is being updated correctly. Open it in read-only mode instead.

    To attempt to salvage the primary database redo logs:
    1. If possible, archive the current online redo log on the primary database:
    2. If you do not maintain a managed standby environment, manually transfer to
    the standby site all available archived logs that have not yet been applied to the
    standby database. Use an appropriate operating system utility for transferring
    binary data. For example, enter:
    % cp /oracle/arc_dest/*.arc /standby/arc_dest
    3. If the standby database is currently in managed recovery mode, cancel recovery:
    If the standby database is not currently in managed recovery mode, put it in a
    mounted state. For example, if the standby instance is not started, enter:
    4. Perform manual recovery on the standby database before activating it, optionally
    specifying the FROM location option (see Placing the Standby Database in
    Manual Recovery Mode on page 3-3). For example, enter one of the following
    SQL> RECOVER AUTOMATIC STANDBY DATABASE # uses location for logs listed in
    initialization parameter file
    SQL> RECOVER AUTOMATIC FROM /logs STANDBY DATABASE # specifies nondefault
    Following this procedure rolls forward the standby database to the time
    immediately before the failure of the primary database. You can apply any redo log
    other than the current redo log to the standby database. If you have lost your
    noncurrent online redo logs and they have not been archived, then activate the
    standby database without recovering the transactions from the unarchived redo
    logs of the primary database.
    Activating the standby database automatically resets the online redo logs. Note that
    the redo logs from the standby database and primary database are now
    incompatible. You cannot apply archived redo logs from the original primary
    database to the activated standby database or vice versa. Also, the standby database
    is not mounted when activated; therefore, the tables and views do not contain
    useful information immediately after activation.
    To activate a standby database:
    1. Ensure that your standby database is mounted in EXCLUSIVE mode by
    executing the following query:
    SQL> SELECT name,value FROM v$parameter WHERE name=parallel_server;
    parallel_server FALSE
    1 row selected.
    If the value is TRUE, then the database is not mounted exclusively; if the value
    is FALSE, then the database is mounted exclusively.
    2. Activate the standby database:
    Note that this command resets the online redo logs.
    3. Shut down the standby instances:
    4. As soon as possible, back up your new production database. At this point, the
    former standby database is now your production database. This task, while not
    required, is a recommended safety measure because you cannot recover
    changes made after activation without a backup.
    5. Start the new production instance in read/write or read-only mode:
    SQL> ALTER DATABASE READ ONLY; # opens the database in read-only mode
    SQL> ALTER DATABASE READ WRITE; # opens the database in read/write mode


    Featured Post

    Looking for New Ways to Advertise?

    Engage with tech pros in our community with native advertising, as a Vendor Expert, and more.

    Join & Write a Comment

    Truncate is a DDL Command where as Delete is a DML Command. Both will delete data from table, but what is the difference between these below statements truncate table <table_name> ?? delete from <table_name> ?? The first command cannot be …
    Introduction A previously published article on Experts Exchange ("Joins in Oracle", makes a statement about "Oracle proprietary" joins and mixes the join syntax with gen…
    This video shows how to copy a database user from one database to another user DBMS_METADATA.  It also shows how to copy a user's permissions and discusses password hash differences between Oracle 10g and 11g.
    This video shows information on the Oracle Data Dictionary, starting with the Oracle documentation, explaining the different types of Data Dictionary views available by group and permissions as well as giving examples on how to retrieve data from th…

    731 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    15 Experts available now in Live!

    Get 1:1 Help Now