3
Managing a Standby Database

This chapter describes how to manage a standby database. It includes the following topics:

Choosing Standby Database Modes

As explained in Standby Database Modes , you can run the standby database in the following mutually exclusive modes:

Managed recovery mode
Manual recovery mode
Read-only mode

Before running in these modes, you must first start the standby instance and then mount the database. The sections in this chapter describe the procedures for initiating the various modes as well as for performing failover to a standby database.

Which Modes Are Typical in a Standby Environment?

Typically, you create a standby database for one or more of the following reasons:

Protection against the total destruction of the primary database
Protection against application corruption of the primary database
Supplemental reporting of data contained in the primary database

If you want maximum protection against data loss or corruption, then maintain the standby database in managed recovery mode in a managed standby environment. In this setup, the primary database archives logs to the standby site, and the standby database automatically applies these logs.

Note:
You may need to apply archived logs manually to the standby database before managed recovery. To learn why, see Resolving a Gap Sequence Before Initiating Managed Recovery .

If you want to use the standby database for reporting purposes, then open it in read-only mode in a managed standby environment. Oracle cannot apply archived redo logs to the standby database when it is in this mode, but you can still execute queries on the database. The primary database continues to archive to the standby site so long as the standby instance is started.

You can easily switch back and forth between managed recovery mode and read-only mode. In most implementations of a managed standby environment, you need to perform this switch at various times to either:

Update a standby database used primarily for reporting

Check that data is correctly applied to a database that is used primarily for disaster protection

See Also:
To learn how to initiate managed recovery, see Placing the Standby Database in Managed Recovery Mode . To learn how to open a standby database in read-only mode, see Opening a Standby Database in Read-Only Mode .

When Is Manual Recovery Required?

Manual recovery mode is required in the following cases:

Managed Standby Environment? Reason for Manual Recovery

Yes

You must resolve a gap sequence; that is, you must put the standby database into a state in which you can initiate managed recovery (see Resolving a Gap Sequence Before Initiating Managed Recovery ).

No

Managed recovery is not an option (see Non-Managed Recovery Environment ), so you must manually transfer logs to the standby site and manually apply them to the standby database.

Managed Standby Environment?	Reason for Manual Recovery
Yes	You must resolve a gap sequence; that is, you must put the standby database into a state in which you can initiate managed recovery (see Resolving a Gap Sequence Before Initiating Managed Recovery ).
No	Managed recovery is not an option (see Non-Managed Recovery Environment ), so you must manually transfer logs to the standby site and manually apply them to the standby database.

Consequently, even if you implement a managed standby environment, you may occasionally need to perform manual recovery on the standby database.

See Also:
To learn how to perform manual recovery of a standby database, see Placing the Standby Database in Manual Recovery Mode .

Placing the Standby Database in Manual Recovery Mode

After you have started and mounted the standby database, you can place it in manual recovery mode. To keep the standby database current, you must manually apply archived redo logs from the primary database to the standby database.

Archived logs arrive at the standby site in one of the following ways:

The primary database automatically archives the logs (only if you implement a managed standby environment).
You manually transfer logs using an operating system utility or some other means.

The standby database assumes that the archived log file group is in the location specified by either of the following parameters in the standby initialization parameter file:

First valid disk location specified by LOG_ARCHIVE_DEST_n (where n is an integer from 1 to 5)
Location specified by LOG_ARCHIVE_DEST

If the archived logs are not in the location specified in the initialization parameter file, you can specify an alternative location using the FROM option of the RECOVER statement.

To place the standby database in manual recovery mode:

Use SQL*Plus to connect to the standby instance and then start the Oracle instance at the standby database. For example, enter:
```
STARTUP NOMOUNT pfile=initSTANDBY.ora
```

Mount the standby database:

ALTER DATABASE MOUNT STANDBY DATABASE;

If Oracle is not archiving logs automatically to the standby site, then manually transfer the logs to the desired location on the standby host using an appropriate operating system utility for transferring binary data. For example, enter:
```
% cp /oracle/arc_dest/*.arc /standby/arc_dest
```

Issue a RECOVER statement to place the standby database in manual recovery mode.

Note:
Specify the FROM 'location' option only if the archived log group is not in the location specified by the LOG_ARCHIVE_DEST_n (where n is an integer from 1 to 5) or LOG_ARCHIVE_DEST parameter in the standby initialization parameter file.

For example, execute one of the following statements:

RECOVER STANDBY DATABASE # uses location for logs specified in
                   # initialization parameter file
RECOVER FROM '/logs' STANDBY DATABASE # specifies nondefault location

As Oracle generates archived redo logs, you must continually transfer and apply them to the standby database to keep it current.

Resolving a Gap Sequence Before Initiating Managed Recovery

A gap sequence is a range of archived redo logs needed by the standby database before it can enter managed recovery mode. A standby database is able to begin managed recovery when you can apply the next archived log generated by the primary database to the standby database in managed recovery mode. This section contains the following topics:

What Causes Gap Sequences?

A gap sequence can occur whenever the primary database archives a log but the log is not transferred to the standby site. Because the standby database requires the sequential application of redo logs, a missing log prevents managed recovery from applying subsquent logs.

Gap sequences can occur in the following situations:

Creation of the Standby Database

One example of a gap sequence occurs when you create the standby database from an old backup. For example, if the standby database is made from a backup that contains changes through log 100, and the primary database currently contains changes through log 150, then the standby database requires that you manually apply logs 101 to 150 before managed recovery can begin.

Another typical example of a gap sequence occurs when you generate the standby database from a hot backup of an open database. For example, assume the scenario illustrated in Figure 3-1.

Figure 3-1 Manual Recovery of Archived Logs in a Gap Sequence

Text description of the illustration sbr81090.gif.

The following steps occur:

You take a hot backup of database PRIMARY.
At time t, while you are busy configuring the network files, PRIMARY archives logs 4 and 5.
At time t + 1, you start the standby instance.
PRIMARY archives logs 6, 7, and 8 to both the primary site and the standby site.

Archived logs 4 and 5 are now part of a gap sequence; that is, you must apply them manually to the standby database before managed recovery can apply archived logs 6, 7, and 8 to the standby database.

Shutdown of the Standby Database When the Primary Database Is Open

You may be required to shut down the standby database to resolve maintenance issues. For example, you must shut down the standby database in the following scenarios:

You change a control file parameter, for example, MAXDATAFILE, in the primary database.
You issue an ALTER DATABASE CLEAR UNARCHIVED LOGFILES statement.

CAUTION:
Performing a RESETLOGS operation on the primary database sinvalidates the standby database. If you reset the logs on the primary database, you must rebuild the standby database.

To avoid creating gap sequences, follow these rules:

Start the standby databases and listeners before starting the primary database.
Shut down the primary database before shutting down the standby database.

If you violate either of these two rules, then the standby database is down while the primary database is open and archiving. Consequently, Oracle can create a gap sequence. When you restart the standby database later, you must synchronize the standby database manually with the primary database before you can initiate managed recovery.

Note:
If the standby site is specified as MANDATORY in one of the LOG_ARCHIVE_DEST_n parameters of the primary initialization parameter file (see Specifying Mandatory and Optional Archive Destinations ), dynamically change it to OPTIONAL before shutting down the standby database. Otherwise, the primary database eventually stalls because it cannot archive its online redo logs.

Network Failure Preventing the Transfer of Logs to the Standby Site

If you maintain a managed standby environment, and the network goes down, the primary database may continue to archive to disk but be unable to archive to the standby site. In this situation, archived logs accumulate as usual on the primary site, but the standby instance is unaware of them.

To prevent this problem, you can specify that the standby destination have mandatory status. If the archiving destination is mandatory, then the primary database will not archive any logs until it is able to archive to the standby site. For example, you can set the following in the primary initialization parameter file to make STANDBY1 a mandatory archiving destination:

LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1 MANDATORY'

One consequence of this configuration is that unless the network problem is fixed, the primary database eventually stalls because it cannot switch into an unarchived online redo log. This problem is exacerbated if you maintain only two online redo logs in your primary database.

See Also:
For a detailed account of the significance of the OPTIONAL and MANDATORY options for standby archival, see the chapter on archived redo logs in the Oracle8i Administrator's Guide. See Scenario 7: Recovering After a Network Failure for additional information.

Determining Whether a Gap Sequence Exists

To determine whether there is a gap sequence, execute the SQL script in the following procedure. If there is a gap sequence, the output of the query specifies the thread number and log sequence number of all logs in the gap sequence. If there is no gap sequence for a given thread, the query returns either no rows or an identical number in the LowSeq# and HighSeq# columns.

To identify the logs in the gap sequence:

Start SQL*Plus and mount the standby database:

SQL> CONNECT sys/sys_pwd@standby1 AS SYSDBA
SQL> STARTUP NOMOUNT pfile=/oracle/admin/pfile/init.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Copy the following SELECT statement into a script and then run the script on the standby database:

SELECT high.thread#, "LowGap#", "HighGap#" 
FROM 
     ( 
     SELECT thread#, MIN(sequence#)-1 "HighGap#" 
     FROM 
     ( 
         SELECT a.thread#, a.sequence# 
         FROM 
         ( 
             SELECT * 
             FROM v$archived_log 
         ) a, 
         ( 
             SELECT thread#, MAX(next_change#)gap1 
             FROM v$log_history 
             GROUP BY thread# 
         ) b 
         WHERE a.thread# = b.thread# 
         AND a.next_change# > gap1 
     ) 
     GROUP BY thread# 
 ) high, 
 
 ( 
     SELECT thread#, MIN(sequence#) "LowGap#" 
     FROM 
     ( 
         SELECT thread#, sequence# 
         FROM v$log_history, v$datafile 
         WHERE checkpoint_change# <= next_change# 
         AND checkpoint_change# >= first_change# 
     ) 
     GROUP BY thread# 
 ) low 
 WHERE low.thread# = high.thread#;

Examine the output of the query to determine the gap sequence. For example, the output may look like:
```
SQL> @gap
THREAD#    LowSeq#    HighSeq#  
---------- ---------- ----------
       1   460        463
       2   202        204
       3   100        100
```
Not every thread has a gap sequence. As this example illustrates, the LowSeq# and HighSeq# for thread 3 are identical, so no gap sequence exists for this thread.

You must apply the logs in the gap sequence for each thread to the standby database to prepare it for managed recovery.

See Also:
To learn how to perform manual recovery, see Placing the Standby Database in Manual Recovery Mode .

Transmitting the Logs in the Gap Sequence to the Standby Site

After you have obtained the log sequence numbers of the logs in the gap sequence, you can obtain their filenames by querying the V$ARCHIVED_LOG view on the primary site (see Determining Which Archived Logs Have Been Received by the Standby Site ). The archived log filenames on the standby site are generated by the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT parameters in the standby initialization parameter file.

If the standby database is on the same host as the primary database, or the standby database is on a remote host with a different directory structure from the primary database, the filenames for the logs on the standby site cannot be the same as the filenames of the logs archived by the primary database. Before transmitting the archived logs to the standby site, determine the correct filenames for the logs at the standby site.

To transmit logs in a gap sequence to the standby site:

Review the list of gap sequence logs that you obtained earlier. For example, assume you have the following gap sequence:
```
THREAD#    LowSeq#    HighSeq#  
---------- ---------- ----------
       1   460        463
       2   202        204
       3   100        100
```
Note that no gap sequence exists for thread 3, so you only need to transmit logs from threads 1 and 2.

Determine the filenames of the logs in the gap sequence that were archived by the primary database. For example, after connecting to the primary database using SQL*Plus, issue a SQL query to obtain the name of a log in each thread:

SQL> CONNECT sys/sys_pwd@primary
SQL> SELECT name 
  2> FROM v$archived_log
  3> WHERE sequence# in (460, 202);

NAME                                                                            
----------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_460.arc
/primary/thread2_dest/arcr_2_202.arc
2 rows selected.

Review the settings for STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT in the standby initialization parameter file. For example, you discover the following:
```
STANDBY_ARCHIVE_DEST = /standby/arc_dest/
LOG_ARCHIVE_FORMAT = log_%t_%s.arc
```
These parameter settings determine the filenames of the archived redo logs at the standby site.

Transfer the gap sequence logs from the primary site to the standby site, renaming them according to values for STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT. For example, enter:

% cp /primary/thread1_dest/arcr_1_460.arc /standby/arc_dest/log_1_460.arc
% cp /primary/thread1_dest/arcr_1_461.arc /standby/arc_dest/log_1_461.arc
% cp /primary/thread1_dest/arcr_1_462.arc /standby/arc_dest/log_1_462.arc
% cp /primary/thread1_dest/arcr_1_463.arc /standby/arc_dest/log_1_463.arc

% cp /primary/thread1_dest/arcr_2_202.arc /standby/arc_dest/log_2_202.arc
% cp /primary/thread1_dest/arcr_2_203.arc /standby/arc_dest/log_2_203.arc
% cp /primary/thread1_dest/arcr_2_204.arc /standby/arc_dest/log_2_204.arc

If the LOG_ARCHIVE_DEST and STANDBY_ARCHIVE_DEST parameter values are not the same, then copy the gap sequence logs from the STANDBY_ARCHIVE_DEST directory to the LOG_ARCHIVE_DEST directory. If these parameter values are the same, then you do not need to perform this step.

For example, assume the following standby initialization parameter settings:
```
STANDBY_ARCHIVE_DEST = /standby/arc_dest/
LOG_ARCHIVE_DEST = /log_dest/
```
Because the parameter values are different, copy the archived logs to the LOG_ARCHIVE_DEST location:
```
% cp /standby/arc_dest/* /log_dest/
```
When you initiate manual recovery, Oracle looks at the LOG_ARCHIVE_DEST value to determine the location of the logs.

Now that all required logs are in the STANDBY_ARCHIVE_DEST directory, you can proceed to the next stage: applying the gap sequence logs to the standby database.

Applying the Logs in the Gap Sequence to the Standby Database

After you have transmitted the logs in the gap sequence to the standby site, you can apply them using the RECOVER AUTOMATIC statement. Once applied, you can go on to place the standby database in managed recovery mode.

To apply the archived redo logs in the gap sequence:

Start SQL*Plus and mount the standby database (if it is not already mounted). For example, enter:

SQL> CONNECT sys/sys_pwd@standby1 AS SYSDBA
SQL> STARTUP NOMOUNT pfile=/oracle/admin/pfile/initSTBY.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Recover the database using the AUTOMATIC option:

SQL> RECOVER AUTOMATIC STANDBY DATABASE

After recovering the available logs, Oracle prompts for the name of a log that does not exist. The reason is that the recovery process does not know about the logs archived to the standby site by the primary database. For example, you might see:

ORA-00308: cannot open archived log '/oracle/standby/standby_logs/arcr_1_
540.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Cancel recovery after Oracle has applied the available logs by executing the following statement (or typing CTRL+C):

SQL> CANCEL
Media recovery cancelled.

Note that the following error messages are acceptable after recovery cancellation and do not indicate a problem:

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error 
below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'some_filename'
ORA-01112: media recovery not started

You are now able to initiate managed recovery.

Placing the Standby Database in Managed Recovery Mode

If you implement a managed standby environment, you can automate archiving to either a local or remote host. Oracle keeps the standby database synchronized with the primary database by waiting for archived logs from the primary database and then automatically applying them to the standby database, as shown in Figure 3-2. This feature eliminates the need to interactively provide the recovery process with the filenames of the archived logs.

Figure 3-2 Transmitting and Applying Archived Redo Logs to a Standby Database

Text description of the illustration sbr81079.gif.

Initiating Managed Recovery Mode

Enable managed recovery using the following SQL*Plus statement:

RECOVER MANAGED STANDBY DATABASE

You can use the TIMEOUT option of the RECOVER statement to specify an optional timeout interval. In this case, the managed recovery operation waits the specified number of minutes for Oracle to write the requested archived log entry to the standby control file's directory.

If Oracle times out because it cannot find the required next log entry in the standby control file, the system issues an appropriate message and exits managed recovery mode. By default, the managed recovery operation waits indefinitely for the next archived log; it terminates only through a CANCEL statement (or CTRL+C key combination), a shutdown, or a crash.

To place the standby database in managed recovery mode:

After connecting to the standby database, start the standby database without mounting it, specifying a parameter file if necessary:
```
STARTUP NOMOUNT pfile=initSTANDBY.ora
```

Mount the database:

ALTER DATABASE MOUNT STANDBY DATABASE;

Ensure that the standby database is synchronized; that is, no gap sequence exists. See Determining Whether a Gap Sequence Exists to determine whether there is a gap sequence. If there is, manually synchronize the database. If there is not, proceed to the next step.
Place the standby database in managed recovery mode:
```
RECOVER MANAGED STANDBY DATABASE
```
Note:
The RECOVER MANAGED STANDBY DATABASE statement does not permit a FROM 'location' option.

If you want to use the optional timeout option, add TIMEOUT integer to the command syntax:
```
RECOVER MANAGED STANDBY DATABASE TIMEOUT 60
```

Oracle now begins managed recovery. As the primary database archives redo logs to the standby site, the standby database automatically applies them.

Note:
After you execute the RECOVER statement, the prompt sits on the line following the RECOVER statement; this is the expected behavior.

To quickly test whether managed recovery is applying the transferred archived redo logs:

Several methods exist for determining the status of archived redo logs, as explained in Troubleshooting the Standby Database Configuration . The following procedure forces archiving at the primary site, which allows you to query a view on the standby database to determine whether the archived log was applied.

Connect to the primary database and make sure it is open.

% sqlplus sys/sys_pwd@primary
SQL> SELECT status FROM v$instance;

STATUS
-------
OPEN

Archive the current online redo log:

ALTER SYSTEM ARCHIVE LOG CURRENT;
System altered.

Query the primary database to determine the most recently archived redo log:

SQL> SELECT max(sequence#) FROM v$log_history;

MAX(SEQUENCE#)
--------------
           541

Create a new session on the standby instance and query the V$LOG_HISTORY view:
```
% sqlplus sys/sys_pwd@standby1
SQL> SELECT max(sequence#) FROM v$log_history;

MAX(SEQUENCE#)
--------------
           541
```
The sequence number should be the same as the number on the primary site. If it is not, wait a short time for Oracle to finish receiving and applying the log and try again. If Oracle still does not apply the log, see Troubleshooting the Standby Database Configuration for ways of obtaining troubleshooting information.

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. Note the following scenarios:

If you cancel recovery Then

Before recovery opens the next redo log

CANCEL IMMEDIATE is equivalent to CANCEL.

While the standby database is processing a redo log

CANCEL IMMEDIATE leaves the database in an inconsistent state. Oracle does not allow a database to be opened in an inconsistent state, although you can still initiate manual or managed recovery.

If you cancel recovery	Then
Before recovery opens the next redo log	CANCEL IMMEDIATE is equivalent to CANCEL.
While the standby database is processing a redo log	CANCEL IMMEDIATE leaves the database in an inconsistent state. Oracle does not allow a database to be opened in an inconsistent state, although you can still initiate manual or managed recovery.

Opening a Standby Database in Read-Only Mode

The read-only mode allows users to open and query a standby database without the potential for online data modifications. This functionality enables you to reduce system overhead on the primary database by using the standby database for reporting purposes. Also, you can periodically open the standby database in read-only mode to ensure that a managed standby database is being updated properly.

This section contains the following topics:

Considering Whether to Run in Read-Only Mode

When determining whether to run the standby database in read-only mode, consider the following:

If you maintain the standby database primarily for disaster protection, then you should not rely too heavily on your standby database as a source of information. If a disaster does occur, then you will have to activate the standby database quickly and immediately cease all user activity.
Using a standby database for queries makes it unavailable for managed recovery. At some point, you need to run a recovery operation against the standby database to resynchronize it with the primary database. This action limits the role of the standby database as a disaster recovery database.

If you need the standby database both for disaster prevention and reporting, then you can maintain multiple standby databases, some read-only and some in managed recovery mode. You will need to resynchronize the read-only database, but the recovery mode databases give you protection against disaster.

Receiving Archived Redo Logs While in Read-Only Mode

While the standby database is in read-only mode, the site can still receive archived redo logs from the primary site. Nevertheless, Oracle does not apply these logs automatically, as in managed recovery. Consequently, a read-only standby database is not synchronized with the primary database at the archive level. You should not activate the standby database in a failover situation unless all archived redo logs have been applied.

Opening the Database in Read-Only Mode

The following states are possible for a standby database:

Shutdown
Manual recovery mode
Managed recovery mode
Read-only mode

You can move from any of the first three states into read-only mode (and back again) using the following procedures.

To open the standby database in read-only mode when the database is shut down:

Use SQL*Plus to start the Oracle instance for the standby database without mounting it:
```
SQL> STARTUP NOMOUNT pfile=initSTANDBY.ora
```

Mount the standby database:

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Open the database in read-only mode:
```
SQL> ALTER DATABASE OPEN READ ONLY;
```

To open the standby database in read-only mode when in manual recovery mode:

Cancel the recovery by entering the following (terminate the flow of archived redo logs to get the prompt):
```
SQL> RECOVER CANCEL
```
Open the database in read-only mode:
```
SQL> ALTER DATABASE OPEN READ ONLY;
```

To open the standby database in read-only mode when in managed recovery mode:

Start a SQL*Plus session and execute the following statement:
```
SQL> RECOVER MANAGED STANDBY DATABASE CANCEL
```
Open the database in read-only mode:
```
SQL> ALTER DATABASE OPEN READ ONLY;
```

To move the standby database from read-only mode back to managed recovery mode:

Terminate all active user sessions on the standby database.

Issue the following statement:

SQL> RECOVER MANAGED STANDBY DATABASE # you can also set the TIMEOUT option

To move the standby database from read-only mode back to manual recovery mode:

Terminate all active user sessions on the standby database.

Issue the following statement:

SQL> RECOVER STANDBY DATABASE # you can also set the TIMEOUT option

Creating Temporary Tablespaces

In order to perform queries on a read-only standby database, the Oracle database server needs to be able to perform on-disk sorting operations. You cannot allocate space for sorting operations in tablespaces that cause Oracle to write to the data dictionary, however, for these modifications cause the standby control file to diverge from the primary control file.

Temporary tablespaces allow you to add tempfile entries in read-only mode for the purposes of making queries. You can then perform on-disk sorting operations in an Oracle8i read-only database without affecting dictionary files or generating redo entries.

Note the following requirements for creating temporary tablespaces:

The tablespaces must be temporary, locally managed, and contain only tempfiles.
User-level allocations and permissions to use the locally managed temporary tablespaces must be in place on the primary database. You cannot change these settings on the standby database.

You should also follow these guidelines:

Minimize data validation time on the standby database so that you can switch into managed or manual recovery mode when necessary.
Minimize runtimes for reports.
Implement desired optimizations on the primary database only.

See Also:
For more information about using tempfiles and temporary tablespaces, see the Oracle8i Administrator's Guide.

To create a temporary tablespace for use on a read-only standby database:

Open the standby database in read-only mode using the relevant procedure described in Opening the Database in Read-Only Mode .
Create a temporary tablespace. For example, enter:
```
SQL> CREATE TEMPORARY TABLESPACE tbs_1 TEMPFILE 'file_1.f' 
     EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;
```
See Also:
For CREATE TEMPORARY TABLESPACE syntax, see the Oracle8i SQL Reference.

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.

Note:
You should not activate a standby database to test whether it is being updated correctly. Open it in read-only mode instead.

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.

To attempt to salvage the primary database redo logs:

If possible, archive the current online redo log on the primary database:
```
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
```
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
```
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;
```
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). 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:

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.

Activate the standby database:
```
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
```
Note that this command resets the online redo logs.
Shut down the standby instances:
```
SQL> SHUTDOWN IMMEDIATE
```
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.

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

Note:
After you activate the standby database, you lose all transactions from unarchived logs at your original production database. Because the standby redo logs are reset at activation, you cannot apply logs archived before activation.

Using a Standby Database in an Oracle Parallel Server Configuration

You can use a standby database in conjunction with the Oracle Parallel Server (OPS) option. The following table describes the possible combinations of nodes in the primary and standby databases:

Single-Instance Standby Database Multi-Instance Standby Database

Single-Instance Primary Database
Yes

Yes (for read-only queries)

Multi-Instance Primary Database
Yes

Yes

	Single-Instance Standby Database	Multi-Instance Standby Database
Single-Instance Primary Database	Yes	Yes (for read-only queries)
Multi-Instance Primary Database	Yes	Yes

In each scenario, each node of the primary database transmits its own thread of archived redo logs to the standby database. For example, Figure 3-3 illustrates an Oracle Parallel Server database with two nodes transmitting redo logs to a single-instance standby database.

Figure 3-3 Transmitting Archived Logs from a Multi-Instance Primary Database

Text description of the illustration sbr81088.gif.

In this case, node 1 of the primary database transmits logs 1, 2, 3, 4, 5 while node 2 transmits logs 32, 33, 34, 35, 36. If the standby database is in managed recovery mode, it automatically determines the correct order in which to apply the archived redo logs.

If both your primary and standby databases are in an Oracle Parallel Server configuration, and the standby database is in managed recovery mode, then a single node of the standby database applies all sets of logs transmitted by the primary nodes. In this case, the standby nodes that are not applying redo cannot be in read-only mode while managed recovery is in progress; in most cases, the non-recovery nodes should be shut down, although they can also be mounted.

See Also:
For information about configuring a database for Oracle Parallel Server, see the Oracle8i Parallel Server Setup and Configuration Guide.

3 Managing a Standby Database