Skip Headers

Oracle Data Guard Concepts and Administration
Release 2 (9.2)

Part Number A96653-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page Go to next page
View PDF

B
Manual Recovery

Although Oracle Corporation recommends that you use the managed recovery mode for your physical standby databases, you can also use manual recovery mode. You might choose manual recovery mode for any of the following reasons:

This appendix explains how to work in manual recovery mode. It includes the following topics:

B.1 Preparing a Standby Database for Manual Recovery: Basic Tasks

Table B-1 summarizes the basic tasks for setting up a standby database in preparation for manual recovery. This procedure assumes that you plan to connect to the standby database through Oracle Net. If you do not want to use Oracle Net to connect to the standby database, skip steps 4 and 5.

Table B-1 Task List: Preparing for Manual Recovery
Step Task Procedure

1

Either make a new backup of the primary database datafiles or access an old backup.

Section 3.2.2

2

Connect to the primary database and create the standby control file.

Section 3.2.3

3

Prepare and copy the backup datafiles and standby control file from the primary site to the standby site.

Section 3.2.4 and Section 3.2.5

4

If you want to create an Oracle Net connection to the standby database, create a service name.

Section 6.4 and LOCATION and SERVICE in Chapter 12

5

If you want to create an Oracle Net connection to the standby database, configure the listener on the standby site so that it can receive requests for connections to the standby instance.

Section 6.4

6

Create the standby initialization parameter file on the standby site and set the initialization parameters for the standby database. Optionally, set DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT to automatically rename primary files in the standby control file.

Section 5.8

7

Start the standby instance and mount the standby database.

Section 6.2.1

8

While connected to the standby database, manually change the names of the primary datafiles and redo logs in the standby control file for all files not automatically renamed using DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT in step 6. If step 6 renamed all files, skip this step.

Section B.4

B.2 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. Figure B-1 shows a database in manual recovery mode.

Figure B-1 Standby Database in Manual Recovery Mode

Text description of sbr81098.gif follows.

Text description of the illustration sbr81098.gif

This section contains the following topics:

B.2.1 Initiating Manual Recovery Mode

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

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

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

  1. 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
    
  2. Mount the standby database:
    ALTER DATABASE MOUNT STANDBY DATABASE;
    
  3. If log transport services are not archiving logs automatically to the standby site, then manually copy the logs to the desired location on the standby site using an appropriate operating system utility for transferring binary data. For example, enter:
    % cp /oracle/arc_dest/*.arc /standby/arc_dest
    
  4. 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 parameter (where n is an integer from 1 to 10) or the LOG_ARCHIVE_DEST_n 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 the Oracle database server generates archived redo logs, you must continually copy and apply them to the standby database to keep it current.

B.2.2 When Is Manual Recovery Required?

Manual recovery mode is required in a non-Data Guard environment. A non-Data Guard environment is one in which you manually:

Even if you implement a Data Guard environment, you might occasionally choose to perform manual recovery on the standby database. For example, you might choose to manually resolve an existing archive gap by using manual recovery mode.

B.3 Resolving Archive Gaps Manually

An archive gap is a range of archived redo logs created whenever you are unable to apply the next archived redo log generated by the primary database to the standby database. This section contains the following topics:

B.3.1 What Causes Archive Gaps?

An archive gap can occur whenever the primary database archives a log, but the log is not archived to the standby site. Because the standby database requires the sequential application of redo logs, media recovery stops at the first missing log encountered.

Archive gaps can occur in the following situations:

B.3.1.1 Creation of the Standby Database

One example of an archive gap 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 apply logs 101 to 150. Another typical example of an archive gap occurs when you generate the standby database from a hot backup of an open database.

For example, assume the scenario illustrated in Figure B-2.

Figure B-2 Manual Recovery of Archived Logs in an Archive Gap

Text description of sbr81090.gif follows.

Text description of the illustration sbr81090.gif

The following steps occur:

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

Archived log sequences 4 and 5 are now part of an archive gap, and these logs must be applied to the standby database.

B.3.1.2 Shutdown of the Standby Database When the Primary Database Is Open

You might be required to shut down the standby database to resolve maintenance issues. For example, you must shut down the standby database when you change a control file parameter, such as MAXDATAFILE, in the primary database.

To avoid creating archive gaps, follow these rules:

If you violate either of these two rules, then the standby database is down while the primary database is open and archiving. Consequently, the Oracle database server can create an archive gap.


Note:

If the standby site is specified as MANDATORY in one of the LOG_ARCHIVE_DEST_n parameters of the primary initialization parameter file, 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.


B.3.1.3 Network Failure Preventing the Archiving of Logs to the Standby Site

If you maintain a Data Guard environment, and the network goes down, the primary database might 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:
  • Section 5.4.3 for a detailed account of the significance of the OPTIONAL and MANDATORY attributes for standby archival
  • Section 10.4 for a related scenario

B.3.2 Determining If an Archive Gap Exists

To determine if there is an archive gap, query the V$ARCHIVED_LOG and V$LOG views. If an archive gap exists, the output of the query specifies the thread number and log sequence number of all logs in the archive gap. If there is no archive gap for a given thread, the query returns no rows.

To identify the logs in the archive gap

Query the V$ARCHIVED_LOG and V$LOG views on the standby database. For example, the following query shows that there is a difference in the RECD and SENT sequence numbers for the destination specified by DEST_ID=2, indicating that there is a gap:

SQL> SELECT MAX(R.SEQUENCE#) LAST_SEQ_RECD, MAX(L.SEQUENCE#) LAST_SEQ_SENT FROM
2> V$ARCHIVED_LOG R, V$LOG L WHERE
3> R.DEST_ID=2 AND L.ARCHIVED='YES';
LAST_SEQ_RECD LAST_SEQ_SENT ------------- ------------- 7 10

Use the following query to determine the names of the archived redo logs on the local system that must be copied to the standby system that has the gap:

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND
2> SEQUENCE# BETWEEN 7 AND 10;
NAME -------------------------------------------------------------------------------- /primary/thread1_dest/arcr_1_7.arc
/primary/thread1_dest/arcr_1_8.arc
/primary/thread1_dest/arcr_1_9.arc
/primary/thread1_dest/arcr_1_10.arc

B.3.3 Manually Transmitting the Logs in the Archive Gap to the Standby Site

After you have obtained the log sequence numbers of the logs in the archive gap, you can obtain their filenames by querying the V$ARCHIVED_LOG view on the primary 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 site as the primary database, or the standby database is on a remote site with a different directory structure than 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 copy logs in an archive gap to the standby site

  1. Review the list of archive gap logs that you obtained earlier. For example, assume you have the following archive gap:
    THREAD#    LOW_SEQUENCE#   HIGH_SEQUENCE#
    ---------- -------------   --------------
           1             460              463
           2             202              204
           3             100              100
    

    If a thread appears in the view, then it contains an archive gap. You need to copy logs from threads 1, 2, and 3.

  2. Determine the filenames of the logs in the archive gap that were archived by the primary database. After connecting to the primary database, issue a SQL query to obtain the name of a log in each thread. For example, use the following SQL statement to obtain filenames of logs for thread 1:
    SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1
      2> AND SEQUENCE# > 459 AND SEQUENCE# < 464;
    
    NAME
    ---------------------------------------------------------------------
    /primary/thread1_dest/arcr_1_460.arc
    /primary/thread1_dest/arcr_1_461.arc
    /primary/thread1_dest/arcr_1_462.arc
    /primary/thread1_dest/arcr_1_463.arc
    4 rows selected
    
    
  3. On the standby site, 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.

  4. On the primary site, copy the archive gap 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 the following copy commands to copy the archive gap logs required by thread 1:
    % 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
    
    

    Perform similar copy commands to copy archive gap logs for threads 2 and 3.

  5. On the standby site, if the LOG_ARCHIVE_DEST and STANDBY_ARCHIVE_DEST parameter values are not the same, then copy the archive gap 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, the Oracle database server 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 Section B.3.4 to apply the archive gap logs to the standby database.

See Also:

Section 6.5.3 and V$ARCHIVED_LOG in Chapter 14

B.3.4 Manually Applying the Logs in the Archive Gap to the Standby Database

After you have copied the logs in the archive gap to the standby site, you can apply them using the RECOVER AUTOMATIC statement.

To apply the archived redo logs in the archive gap

  1. Start up and mount the standby database (if it is not already mounted). For example, enter:
    SQL> STARTUP NOMOUNT PFILE=/oracle/admin/pfile/initSTBY.ora
    SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
    
  2. Recover the database using the AUTOMATIC option:
    SQL> ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE;
    

    The AUTOMATIC option automatically generates the name of the next archived redo log needed to continue the recovery operation.

    After recovering the available logs, the Oracle database server 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}
    
  3. Cancel recovery after the Oracle database server has applied the available logs, by executing the following statement (or typing CTRL+C):
    SQL> CANCEL
    Media recovery cancelled.
    

    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
    

Oracle Corporation recommends automatically applying the logs in the archive gap using the RECOVER MANAGED STANDBY DATABASE clause of the ALTER DATABASE statement.

See Also:

Section 6.4 for additional information

B.4 Renaming Standby Database Files Manually

Sometimes all of the primary datafiles and redo logs cannot be renamed in the standby control file by conversion parameters. For example, assume that your database has the following datafiles, which you want to rename as shown in the following table:

Primary Filename Standby Filename

/oracle/dbs/df1.dbf

/standby/df1.dbf

/oracle/dbs/df2.dbf

/standby/df2.dbf

/data/df3.dbf

/standby/df3.dbf

You can set DB_FILE_NAME_CONVERT as follows to convert the filenames for the first two datafiles:

DB_FILE_NAME_CONVERT = '/oracle/dbs', '/standby'

Nevertheless, this parameter will not capture the renaming of /data/df3.dbf. You must rename this datafile manually in the standby database control file by issuing a SQL statement as follows:

SQL> ALTER DATABASE RENAME FILE '/data/df3.dbf' to '/standby/df3.dbf';

To rename a datafile manually

  1. Start up and mount the standby database (if it is not already started) and then mount the database:
    SQL> STARTUP NOMOUNT PFILE=initSTANDBY1.ora;
    SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
    
  2. Issue an ALTER DATABASE statement for each datafile requiring renaming, where old_name is the old name of the datafile as recorded in the control file and new_name is the new name of the datafile that will be recorded in the standby control file:
    SQL> ALTER DATABASE RENAME FILE 'old_name' TO 'new_name';
    

When you manually rename all of the datafiles that are not captured by the DB_FILE_NAME_CONVERT parameter, the standby database control file can correctly interpret the log stream during the recovery process.