6 Recovering Data from Recovery Appliance
This chapter explains how to use backups stored on Recovery Appliance to recover your protected database after a failure.
This chapter contains the following sections:
Overview of Restoring and Recovering Data from Recovery Appliance
You can recover the entire protected database, one or more data files, or one or more tablespaces. If only certain data blocks in the protected database are corrupt, then you can perform block recovery to repair only the corrupted blocks. The recovery procedures using Recovery Appliance are identical to those used to recover a database within a conventional RMAN environment. The major difference is the use of a Recovery Appliance as the source for recovery data by configuring or allocating an RMAN channel that corresponds to the Recovery Appliance backup module.
You can use Enterprise Manager Cloud Control (Cloud Control) or RMAN to restore and recover protected databases.
Recovering Protected Databases Using Cloud Control
Cloud Control provides the following techniques to recover protected databases:
-
This technique performs manual recovery based on the specified criteria. You must provide information such as the objects that must be recovered (database, data files, tablespaces, archived redo logs), whether to perform complete recovery or point-in-time recovery, location to which database files must be recovered, and so on.
See Also:
Oracle Database Backup and Recovery User's Guide for more information about performing user-directed recovery
Prerequisites for Recovering Protected Databases Using Cloud Control
-
The protected database must be enrolled and registered with the target Recovery Appliance.
-
Backups required for the recovery process must be stored on the Recovery Appliance. When performing point-in-time recovery, you can recover to any point within the recovery window defined for a protected database.
Restoring and Recovering Data from Recovery Appliance Using the Command Line
The examples in this section contain procedures that represent typical restore and recovery scenarios. If a protected database has been correctly configured for backup operations with a Recovery Appliance as described in "Configuring Backup and Recovery Settings for Protected Databases (Command Line)", it can use the same configuration for recovery operations.
When using Recovery Appliance for restore and recovery operations, the RMAN connection syntax used is the same as with a regular RMAN recovery catalog connection. The only difference is that you connect to the Recovery Appliance catalog and configure RMAN channels as described in "Using RMAN Channels for Recovery Appliance Backup and Recovery Operations".
See Also:
Oracle Database Backup and Recovery User's Guide for a complete description of how to recover databases
This section contains the following examples:
-
Example: Restoring and Recovering an Entire Database With the Existing Current Control File
-
Example: Recovering an Entire Database to a Specified Point-in-Time
-
Example: Restoring and Recovering Tablespaces in the Protected Database
-
Example: Restoring and Recovering a Data File in the Protected Database
-
Example: Restoring and Recovering One or Many Data Blocks in a PDB
-
Example: Recovering the Control File and Database When Real-Time Redo Transport is Configured
Prerequisites for Restoring and Recovering Data from Recovery Appliance
Ensure that the following prerequisites are met before you use backups stored on Recovery Appliance to restore and recover your protected database:
-
The protected database must be enrolled and registered with the target Recovery Appliance.
This is important if you have multiple Recovery Appliances or a Data Guard environment where primary and standby backs up to different Recovery Appliances.
-
Backups required to restore and recover the protected database must be stored on the Recovery Appliance. When performing point-in-time recovery, you can recover to any point within the recovery window defined for the protected database.
-
The Oracle wallet containing credentials used to authenticate with the Recovery Appliance must be configured on the protected database.
-
Configure or allocate RMAN SBT channels that correspond to the Recovery Appliance backup module. The examples in this chapter assume that an SBT channel is configured for Recovery Appliance.
It is recommended that you configure channels using the RMAN
CONFIGURE
command because these settings are persistent settings. However, you can override the configured channel settings by using theALLOCATE CHANNEL
command within theRUN
block that performs the backup or recovery operation.
Restoring Protected Databases Using a Downstream Recovery Appliance
When Recovery Appliance replication is configured, the protected database sends backups to the upstream Recovery Appliance. The upstream Recovery Appliance then forwards these backups to the downstream Recovery Appliance. In the event of a failure, if the upstream Recovery Appliance is unavailable, then you can perform restore operations using the downstream Recovery Appliance.
See Also:
"Protected Databases and Recovery Appliance Architecture" for a brief overview of replication
Use the following high-level steps to restore a protected database directly from a downstream Recovery Appliance:
-
Create an Oracle wallet that contains the credentials of the VPC user with which the protected database will authenticate with the downstream Recovery Appliance.
Note:
The protected database need not be explicitly added to or registered with the downstream Recovery Appliance before performing restore operations. When replication is configured between the upstream and downstream Recovery Appliance, the protected databases enrolled with the upstream Recovery Appliance are registered with the downstream Recovery Appliance.
-
Connect to the protected database as
TARGET
and to the downstream Recovery Appliance catalog asCATALOG
. -
Allocate an RMAN SBT channel that corresponds to the downstream Recovery Appliance, place the protected database in
MOUNT
mode, and restore the protected database.All these statements must be enclosed within a
RUN
block as shown in "Example: Restoring and Recovering an Entire Database With the Existing Current Control File".
Example: Restoring and Recovering an Entire Database With the Existing Current Control File
This example assumes that some or all the data files in the protected database are lost or damaged. However, the control file is available.
To restore and recover all the data files in a protected database:
Example: Restoring and Recovering an Entire Database having Real-time Redo
This example assumes that the protected database were configured to use real-time redo transport.
To restore and recover all the data files in a protected database:
Example: Recovering an Entire Database to a Specified Point-in-Time
This example demonstrates how to perform point-in-time recovery (PITR) for a protected database. PITR may be required to revert the protected database to a prior date to recover from user errors (accidentally dropping tables or updating the wrong tables), media failure, or a failed database upgrade. You need to restore the control file only if there has been a structural change to the control file (such as creating or dropping tablespaces). Use the SET UNTIL
clause to specify the time, SCN, or log sequence to which the protected database must be recovered.
If Flashback Database is enabled for the protected database, you can also use this feature to recover to a prior point-in-time.
See Also:
-
Oracle Database Backup and Recovery User's Guide
-
Oracle Database Backup and Recovery Reference
To restore and recover the entire protected database, including the control file, to a specific point-in-time:
Example: Restoring and Recovering the Control File
This example demonstrates how to recover a protected database after the loss of all control file copies. It is strongly recommended that you create multiple copies of your control files in separate disk locations.
To restore and recover the control file in a protected database:
Example: Restoring and Recovering Tablespaces in the Protected Database
This example demonstrates how to restore and recover one or more tablespaces in the protected database after they are accidentally dropped or corrupted. The example assumes that the database is up and running and that you will restore only the affected tablespaces.
To restore and recover one or more tablespaces:
Example: Restoring and Recovering a Data File in the Protected Database
This example demonstrates how to restore and recover a data file that was accidentally deleted or corrupted.
To restore and recover a data file in a protected database:
Example: Restoring and Recovering PDBs
The multitenant architecture, introduced in Oracle Database 12c Release 1, enables an Oracle Database to function as a multitenant container database (CDB) that includes zero, one, or many customer-created pluggable databases (PDBs). All Oracle databases before Oracle Database 12c are non-CDBs.
A CDB includes the following components: root, seed, and user-created PDBs. The root stores the common users and Oracle-supplied metadata such as the source code for Oracle-supplied packages. The seed is a template that can be used to create new PDBs. A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB.
This section demonstrates various restore and recovery scenarios for PDBs. The steps to restore and recover a PDB are similar to those used for restore and recover operations on non-CDBs. This section contains the following examples:
Performing Complete Recovery of the Whole PDB
This example demonstrates how to perform complete recovery for a PDB in the protected database.
To restore and recover a whole PDB:
Performing Point-in-Time Recovery for the Whole PDB
This example demonstrates how to perform point-in-time recovery for one or more PDBs in your protected database. Specify the SET UNTIL
clause to indicate the point to which the PDB must be recovered.
To restore and recover a PDB to a specific point-in-time:
Recovering Specific Data Files in a PDB
Restoring and recovering data files in a PDB is similar to restoring and recovering any data file using RMAN. This example demonstrates how to restore and recover a data file in a PDB.
To restore and recover a specific data file in a PDB:
Recovering Specific Tablespaces in a PDB
This example demonstrates how to restore and recover the tablespace USR_TBS
contained in the PDB SH_PDB
in your protected database.
Restoring and recovering a tablespace in a PDB is similar to a normal tablespace restore and recovery. The difference is that you need to map the tablespace to the pluggable database (pdb_name:tablespace_name
).
To restore and recover specific tablespaces in a PDB:
Example: Recovering a PDB in an Oracle RAC Environment
The process to restore and recover a PDB in an Oracle Real Application Clusters (Oracle RAC) environment has some slight additions to the non-Oracle RAC process. This example demonstrates how to recover a PDB in an Oracle RAC environment.
To restore and recover a PDB in an Oracle RAC environment:
Example: Restoring and Recovering One or Many Data Blocks in a PDB
Block media recovery enables you to recover one more corrupt data blocks while the data file is still online. This example demonstrates how to perform block media recovery to recover one or more corrupt data blocks.
See Also:
Oracle Database Backup and Recovery User's Guide
The existence of corrupt data blocks can be indicated by one of the following methods:
-
The protected database alert log contains the following message indicating that one or more blocks are corrupt:
Sun Aug 17 09:34:48 2014 Hex dump of (file 2, block 16385) in trace file /u01/app/oracle/diag/rdbms/dbstress/dbstress/trace/dbstress_ora_9732.trc Corrupt block relative dba: 0x00004001 (file 2, block 16385) Fractured block found during backing up datafile Data in bad block: type: 6 format: 2 rdba: 0x00004001 last change scn: 0x0000.00a564c0 seq: 0x1 flg: 0x06 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0x00000000 check value in block header: 0xd6dd computed block checksum: 0x58f7
-
During an RMAN backup, the block corruption is detected and a message similar to the following will be displayed.
RMAN-08038: channel c3: starting piece 1 at 2014/08/17 09:34:43 RMAN-03009: failure of backup command on c1 channel at 08/17/2014 09:34:50 ORA-19566: exceeded limit of 0 corrupt blocks for file /SHARED1/ORADATA/DBF/dbstress/soe.dbf . . RMAN-03002: failure of backup plus archivelog command at 08/17/2014 09:35:55 RMAN-03009: failure of backup command on c1 channel at 08/17/2014 09:34:50 ORA-19566: exceeded limit of 0 corrupt blocks for file /SHARED1/ORADATA/DBF/dbstress/soe.dbf
To restore and recover corrupt data blocks in the protected database:
Example: Recovering a Database Configured for Real-Time Redo Transport After a Severe Storage Failure
Real-time redo transport, when enabled, guarantees the lowest recovery downtime for protected database. When restoring and recovering a protected database immediately after a storage failure, the necessary complete and partial archived log files are restored and recovered so that media recovery can return the database state to the closest state from when the storage failure occurred.
The following example recovers a protected database that was configured to use real-time redo transport after a storage failure that results in the loss of all data files and online redo log files. To recover the protected database to the highest SCN using the backups and redo logs available at the Recovery Appliance, use the FINAL_CHANGE#
column of the RC_DATABASE
view. The FINAL_CHANGE#
column contains the highest SCN to which the protected database must be recovered. Use this SCN value in the SET UNTIL SCN
command prior to performing a recovery. The recovery is performed using only the backups and redo logs available at the Recovery Appliance.
Note:
In the following scenarios, RC_DATABASE.FINAL_CHANGE#
will contain the value -1 and cannot be used in the SET UNTIL SCN
command:
-
version of the protected database is Oracle Database 11g (Release 11.1) or lower
-
COMPATIBLE
parameter of the protected database was set to 10.0 or lower while sending real-time redo log data to the Recovery Appliance
Instead, use the NEXT_CHANGE#
column in the V$ARCHIVED_LOG
view to determine the SCN to which the protected database needs to be recovered.
See My Oracle Support note 243760.1 for additional information. My Oracle Support is available at: https://support.oracle.com
.
To restore and recover a protected database that is configured to use real-time redo transport:
See Also:
-
Oracle Database Backup and Recovery Reference for a description of the
FINAL_CHANGE#
column
Example: Recovering the Control File and Database When Real-Time Redo Transport is Configured
This example recovers a protected database that is configured to use real-time redo transport from the loss of all database files. Since the control file too is lost, you need to first restore the control file and then perform recovery of the protected database.
To restore and recover a protected database, including the control file, that is configured to use real-time redo transport:
Database Duplication from Recovery Appliance
If you need to duplicate a protected database to create a standby database or to clone a protected database to a target host, you can do so by connecting to the Recovery Appliance catalog and using backup-based duplication. By using the catalog, there is no need to connect to the source database. Creating a standby database or a clone both involve running the RMAN DUPLICATE
command.
Note:
DUPLICATE
is the recommended method to create a clone database for standby database, development, or testing purposes, because a new DBID
is created for the clone database.
If the protected database must be restored to a new host following the RMAN
restore and recover to a new host procedure that keeps the same DBID
, you must disconnect from the catalog before performing OPEN RESETLOGS
or use SQL Plus to open the database.
See Also:
-
Oracle Database Backup and Recovery User's Guide for additional information about duplicating databases
-
Oracle Database Backup and Recovery Reference for the syntax of the
DUPLICATE
command
Creating a Standby Database for a Protected Database
When you create a standby database from Recovery Appliance, you connect to the standby (auxiliary instance) and to the Recovery Appliance catalog, and run the RMAN DUPLICATE
command with the FOR STANDBY
option.
Note:
Because the primary database is already registered with the Recovery Appliance catalog, you should not register the standby database with the Recovery Appliance catalog.To create a standby database for a protected database:
Cloning a Protected Database
The example that follows represents the Oracle best practice for cloning a protected database and includes a sample script that you can customize for your scenario.
-
backups of the target database exist on the Recovery Appliance and are available to the auxiliary instance
-
RMAN connection from the auxiliary database to the Recovery Appliance that contains metadata and backups for the target database is available
-
both source and duplicate database use Oracle Managed Files (OMF)
-
operating system used is Linux or UNIX
-
the audit directory is created on the auxiliary database host
-
prerequisites for backup-based duplication are met
-
drops an existing auxiliary database
-
backs up the target database
-
creates a dummy auxiliary instance and opens it in
NOMOUNT
mode -
duplicates the target database using the target database backups and metadata available on the Recovery Appliance
The duplicate database control file is stored as
+REDO/
ORACLE_SID
/CONTROLFILE/cf3.ctl
and the data files are stored in the+DATA
directory. -
verifies that the required objects are created in the duplicate database
To clone a protected database using backup-based duplication without a target connection: