Restoring and Recovering Files Over the Network

RMAN enables you to restore or recover files by connecting, over the network, to a physical standby database that contains the required files. You can restore an entire database, data files, control files, server parameter file, or tablespaces. Restoring files over the network is very useful in scenarios where you need to synchronize the primary and standby databases.

Backup sets are used to restore or recover files over the network. Therefore, you can use multisection backups, encryption, and compression to improve backup and restore performance.

Restoring and recovering files over the network is supported starting with Oracle Database 12c Release 1 (12.1).

20.7.1 About Restoring Files Over the Network

RMAN restores database files, over the network, from a physical standby database by using the FROM SERVICE clause of the RESTORE command. The FROM SERVICE clause provides the service name of the physical standby database from which the files must be restored. During the restore operation, RMAN creates backup sets, on the physical standby database, of the files that need to be restored and then transfers these backup sets to the target database over the network.

Use the SECTION SIZE clause of the RESTORE command to perform a multisection restore operation. To encrypt the backup sets created on the physical standby database, use the SET ENCRYPTION command before the RESTORE command to specify the encryption algorithm used.

To transfer files from the physical standby database as compressed backup sets, use the USING COMPRESSED BACKUPSET clause in the RESTORE command. By default, RMAN compresses backup sets using the algorithm that is set in the RMAN configuration. You can override the default and set a different algorithm by using the SET COMPRESSION ALGORITHM command before the RESTORE statement.

20.7.2 About Recovering Files Over the Network

RMAN can perform recovery by fetching an incremental backup, over the network, from a primary database and then applying this incremental backup to the physical standby database. RMAN is connected as TARGET to the physical standby database. The recovery process is optimized by restoring only the used data blocks in a data file. Use the FROM SERVICE clause to specify the service name of the primary database from which the incremental backup must be fetched.

To use multisection backup sets during the recovery process, specify the SECTION SIZE clause in the RECOVER command. To transfer the required files from the primary database as encrypted backup sets, use the SET ENCRYPTION command before the RESTORE command to specify the encryption algorithm used to create the backup sets.

To compress backup sets that are used to recover files over the network, use the USING COMPRESSED BACKUPSET. RMAN compresses backup sets when it creates them on the primary database and then transfers these backup sets to the target database.

20.7.3 Scenarios for Restoring and Recovering Files Over the Network

Recovering files by connecting, over the network, to physical standby database is useful in the following scenarios:

You need to roll-forward a physical standby database to make it in-sync with the primary database.

After creating an incremental backup of the latest changes on the primary database, you can restore the physical standby database using the incremental backup.

You want to restore lost data files, control files, or tablespaces on a primary database using the corresponding files on the physical standby database. You can also restore files on a physical standby database by using the primary database.

20.7.4 Restoring Data Files Over the Network

In this example, the DB_UNIQUE_NAME of the primary database is MAIN and the DB_UNIQUE_NAME of the physical standby database is STANDBY. The data file sales.dbf on the primary database was lost. You want to restore this data file from the physical standby database. The service name of the physical standby database is standby_tns. The RESTORE command with the FROM SERVICE clause enables you to restore the lost data file in the primary database by using the data file in the physical standby database. The password file in the primary database and the physical standby database are the same.

Use the following steps to restore the data file sales.dbf in the primary database by using the data file in the physical standby database:

1. Connect to the primary database as a user with the SYSBACKUP privilege.

%RMAN

RMAN> CONNECT TARGET "[email protected] AS SYSBACKUP";

Enter the password for the sbu user when prompted.

1. Specify that the backup sets must be encrypted using the AES128 encryption algorithm

RMAN> SET ENCRYPTION ALGORITHM 'AES128';

1. Ensure that the tnsnames.ora file in the physical standby database contains an entry corresponding to the primary database. Also ensure that the password files on the primary and physical standby database are the same.
2. Restore the data file on the primary database by using the data file on the physical standby database. The following command creates multisection backup sets to perform the restore operation.

RESTORE DATAFILE '/oradata/datafiles/sales.dbf'

FROM SERVICE standby_tns

SECTION SIZE 120M;

20.7.5 Rolling Forward a Physical Standby Database Using the RECOVER Command

You can use the RECOVER ... FROM SERVICE command to synchronize the data files on the physical standby database with those on the primary database. RMAN creates an incremental backup containing the changes to the primary database, transfers the incremental backup over the network to the physical standby database, and then applies the incremental backup to the physical standby database. All changes to data files on the primary database, beginning with the SCN in the standby data file header, are included in the incremental backup.

The RECOVER ... FROM SERVICE command refreshes the standby data files and rolls them forward to the same point-in-time as the primary. However, the standby control file still contains old SCN values which are lower than the SCN values in the standby data files. Therefore, to complete the synchronization of the physical standby database, you must refresh the standby control file and then update the data file names, online redo log file names, and the standby redo log file names in the refreshed standby control file.

If network resources are a constraint, then you can use the BACKUP INCREMENTAL command to create incremental backups on the primary database, and then use the incremental backups to roll forward the physical standby database.

Steps to Refresh a Physical Standby Database with Changes Made to the Primary Database describes the steps to refresh a physical standby using the FROM SERVICE clause.

See Also:

Oracle Data Guard Concepts and Administration for information about using the BACKUP INCREMENTAL command to roll forward a physical standby database

20.7.5.1 Steps to Refresh a Physical Standby Database with Changes Made to the Primary Database

Assume that the DB_UNIQUE_NAME of the primary database is MAIN and its net service name is primary_db. The DB_UNIQUE_NAME of the standby database is STANDBY and its net service name is standby_db.

Use the following steps to refresh the physical standby database with changes made to the primary database:

1. Ensure that the following prerequisites are met:

1. Oracle Net connectivity is established between the physical standby database and the primary database.
2. You can do this by adding an entry corresponding to the primary database in the tnsnames.ora file of the physical standby database.
3. The password files on the primary database and the physical standby database are the same.
4. The COMPATIBLE parameter in the initialization parameter file of the primary database and physical standby database is set to 12.0.

1. Start RMAN and connect as target to the physical standby database. It is recommended that you also connect to a recovery catalog.

The following commands connect as TARGET to the physical standby database and as CATALOG to the recovery catalog. The connection to the physical standby is established using the sbu user, who has been granted SYSBACKUP privilege. The net service name of the physical standby database is standby_db and that of the recovery catalog is catdb.

CONNECT TARGET "[email protected]_db AS SYSBACKUP";

CONNECT CATALOG [email protected];

1. Obtain the names of the data files and the temp files in the physical standby database using the following command:

REPORT SCHEMA;

This command also implicitly resynchronizes the recovery catalog and ensures that it contains all the file names of the standby database.

1. Note the names of the online redo log files and standby redo log files of the physical standby database. You may require these names in a later step.

The following command lists the names and group identifiers of the redo log files:

SELECT type, group#, member FROM v$logfile;

1. Stop the managed recovery processes on the physical standby database.

The following command stops the recovery processes:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

When using Data Guard Broker, use the following command to stop the managed recovery process:

DGMGRL > edit database standby_db set state='APPLY-OFF';

1. Note the current SCN of the physical standby database. This is required to determine, in a later step, if new data files were added to the primary database.

Query the V$DATABASE view to obtain the current SCN using the following command:

SELECT CURRENT_SCN FROM V$DATABASE;

1. Place the physical standby database in NOMOUNT mode.

Use the following steps to place the standby in NOMOUNT mode:

SHUTDOWN IMMEDIATE;

STARTUP NOMOUNT;

1. Restore the standby control file by using the control file on the primary database.

The following command restores the control file on the physical standby database by using the primary database control file.

RESTORE STANDBY CONTROLFILE FROM SERVICE primary_db;

After this step, the names of files in the standby control file are the names that were used in the primary database.

1. Mount the standby database using the following command:

ALTER DATABASE MOUNT;

1. Update the names of the data files and the temp files in the standby control file.

If you are connected to a recovery catalog, then use the following command to update the file names:

RECOVER DATABASE NOREDO;

If you are not connected to a recovery catalog, then use the CATALOG command and the SWITCH command to update all the data file names.

CATALOG START WITH '/disk2/datafiles/';

SWITCH DATABASE TO COPY;

Here, /disk2/datafiles/ is the location of the data files on the physical standby database. All data files must be stored in this location.

If the data files are in different locations, then use the ALTER DATABASE RENAME FILE command to rename data files.

1. Refresh the data files on the physical standby database by using an incremental backup of the data files on the primary database.

The following command creates a multisection incremental backup on the primary database that is then used to refresh the standby data files. primary_db is the net service name of the primary database that is used to refresh the standby database. The NOREDO clause specifies that the archived redo log files must not be applied during recovery.

RECOVER DATABASE

FROM SERVICE primary_db

NOREDO

SECTION SIZE 120M;

1. Use the current SCN returned in Step 6 to determine if new data files were added to the primary database since the standby database was last refreshed. If yes, these data files need to be restored on the standby from the primary database.

The following example assumes that the CURRENT_SCN returned in Step 6 is 35806 and lists the data files that were created on the primary after the timestamp represented by this SCN:

SELECT file# FROM V$DATAFILE WHERE creation_change# >= 35806;

1. If no files are returned in Step 12, then go to Step 14. If one or more files are returned in Step 12, then restore these data files from the primary database.

1. If you are not connected to a recovery catalog, then use the following commands to restore data files that were added to the primary after the standby was last refreshed (data files 15 and 17 were added to the primary):

RUN

{

SET NEWNAME FOR DATABASE TO '/oracle/database';

RESTORE DATAFILE 15, 17 FROM SERVICE primary_db;

}

1. If you are connected to a recovery catalog, then use the following command to restore data files that were added to the primary after the standby was last refreshed (data files 15 and 17 were added to the primary):

RESTORE DATAFILE 15, 17 FROM SERVICE primary_db;

2. Update the names of the online redo logs and standby redo logs in the standby control file using one of the following methods:

1. Use the ALTER DATABASE CLEAR command to clear the log files in all redo log groups of the standby database. RMAN then recreates all the standby redo logs and the online redo log files.

Note:

Clearing log files is recommended only if the standby database does not have access to the online redo log files and standby redo log files of the primary database. If the standby database has access to the redo log files of the primary database and the redo log file names of the primary database are OMF names, then the ALTER DATABASE command will delete log files on the primary database.

The GROUP# column of the V$LOGFILE view queried in Step 4 provides the redo log group identifiers of the log groups that must be cleared. Use separate ALTER DATABASE CLEAR commands to clear each redo log group.

The following command clears the redo log group with identifier 2.

ALTER DATABASE CLEAR LOGFILE GROUP 2;

You can delete the old redo log files after clearing all the redo log groups.

Use the ALTER DATABASE RENAME FILE command to rename the redo log files. Use a separate command to rename each log file listed in Step 4.

To rename log files, the STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL. Renaming log files is recommended when the number of online redo logs files and standby redo log files is the same in the primary database and the physical standby database.

See Also:

Oracle Database SQL Language Reference for the ALTER DATABASE command syntax

1. On the primary database, switch the archived redo log files using the following command:

ALTER SYSTEM ARCHIVE LOG CURRENT;

(For Active Data Guard only) Perform the following steps to recover redo data and open the physical standby database in read-only mode:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE UNTIL CONSISTENT;

ALTER DATABASE OPEN READ ONLY;

1. Start the managed recovery processes on the physical standby database.

The following command starts the managed recovery process:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

When using Data Guard Broker, use the following command to start the managed recovery process:

DGMGRL> edit database standby_db set state='APPLY-ON';