• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1570
  • Last Modified:

Error while performing failover in Dataguard configuration

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
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?
0
Muhammad Khan
Asked:
Muhammad Khan
1 Solution
 
schwertnerCommented:
Oracle docs say:

Canceling Managed Recovery
Cancel the managed recovery operation at any time by issuing either of the
following SQL*Plus statements:
RECOVER MANAGED STANDBY DATABASE CANCEL
RECOVER MANAGED STANDBY DATABASE CANCEL IMMEDIATE
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:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
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:
SQL> CANCEL
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:
SQL> STARTUP NOMOUNT pfile=initSTANDBY.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
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
statements:
SQL> RECOVER AUTOMATIC STANDBY DATABASE # uses location for logs listed in
initialization parameter file
SQL> RECOVER AUTOMATIC FROM /logs STANDBY DATABASE # specifies nondefault
location
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;
NAME VALUE
-----------------------------------------------------------------
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:
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
Note that this command resets the online redo logs.
3. Shut down the standby instances:
SQL> SHUTDOWN IMMEDIATE
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> STARTUP MOUNT
SQL> ALTER DATABASE READ ONLY; # opens the database in read-only mode
SQL> ALTER DATABASE READ WRITE; # opens the database in read/write mode


0

Featured Post

NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now