Databases Reference
In-Depth Information
5.
Send a new archive log from the primary database to the new standby database:
SQL> alter system set log_archive_dest_state_n = enable;
SQL> alter system archive log current;
6.
Verify that the standby database has received the new archive log:
SQL> select dest_id, dest_name,status, type, error, destination
from v$archive_dest_status
where dest_id = <standby_dest#>;
7.
Restart the managed recovery process (MRP):
SQL> recover managed standby database using current logfile through all
switchover disconnect;
8.
Once the standby database is in sync with the primary database, verify that the new
standby database data files and control files are in sync. To do this, you must first stop the
managed recovery process:
SQL> recover managed standby database cancel;
9.
Perform the validation check after opening the physical standby database read-only:
10.
If you don't see any rows returned, that means the list of data files in the data dictionary
matches the data files listed in the control file:
SQL> alter database open;
SQL> select file#, CRSCNBAS from file$
MINUS
select file#, creation_change# from v$datafile;
11.
Restart managed recovery after your validation check is successful:
SQL> recover managed standby database using current logfile through all
switchover disconnect;
How It Works
Oracle recommends that you actually use Flashback Database to reinstate the original primary database after a
Data Guard failover to a physical standby database, because it gets the job done much faster than any other method.
However, you sometimes may not have access to Flashback Database, either because you didn't enable it or because
the flashback data isn't accessible for some other reason. In such cases, you can reinstate the original primary
database using RMAN backups, as shown in the Solution section.
Since a backup control file may not always reflect the same list of data files as that recorded in the data dictionary,
it's a good practice to create a standby control file after each backup.
In the Solution section, we showed how to remove any archive logs created at or after the failover operation.
If the primary database was isolated from the standby for any length of time, the archive logs on the standby could be
inconsistent with those on the current primary database. To avoid problems from applying these divergent archive
logs, you must delete them from both your backups, as well as from the fast recovery area.
