? Perform a full recovery after losing critical or non-critical data files? Restore with incremental update backup? Switch to image copy for quick recovery? Restore the database to a new host? Using Backup control files for recovery
- Using the Rman Restore and recover commands
? Restore command: Restoring a database file from a backup? Recover command: Recover restored files RMAN> SQL ' ALTER tablespace inv_tbs OFFLINE IMMEDIATE ' by applying incremental backup and recorded changes in redo log files; rman> RESTORE tablespace Inv_tbs; rman> RECOVER tablespace Inv_tbs; Rman> SQL ' altertablespace inv_tbs ONLINE '; oracle Enterprise Manager Recovery Wizard Create and run an Rman script to perform recovery The process of rebuilding an entire database or a portion of a database from a backup using the Rman restore and recover commands typically consists of two stages: retrieving a copy of the data file from the backup, and re-applying the changes made to the file since the archive and online redo log, To restore the database to the desired SCN (usually the latest SCN). ? RESTORE {DATABASE | Tablespace Name[,name] ... | The datafile name [, name]}... restore command retrieves the data file from the backup location on the tape, disk, or other media to disk and makes it available to the database server. RMAN restores any archive redo logs that are required during the recovery operation from the backup. If the backup is stored on the media manager, you must configure or assign a channel to access the backup stored on the media. ? RECOVER {DATABASE | Tablespace Name[,name] ... | The datafile name [, name]}... recover command obtains a copy of the restored data file and applies the changes recorded in the incremental backup and database redo logs to the replica. can also use the Recovery Wizard with Oracle Enterprise Manager to perform full or point-in-time recovery. On the availability (availability) page, in the Backup/recovery (Backup/Restore) section, click Perform Recovery (Perform recovery). Note: One way to automatically detect recovery requirements and perform this recovery is to use data recovery guidance.
- Perform a full recovery: missing non-critical data files in Archivelog mode
If a data file is missing or corrupted and the file does not belong to the system or undo tablespace, only the missing data file is restored and restored. Perform full recovery: missing non-critical data files in Archivelog mode when the database is in Archivelog mode, if any data files that are not part of the system or undo tablespace are lost, only the objects in the missing files are affected. To restore and recover missing data files using Oracle Enterprise Manager, follow these steps: 1. On the availability (availability) property page, click Perform Recovery (Perform recovery). 2. Select "Datafiles (data file)" as "Recovery scope" and select "Restore datafiles (data file)" as "Operation type (action type)". 3. Add all data files that need to be recovered. 4. Specify which backup to restore files from. 5. Determine whether to restore the file to the default location or to a new location if the disk or controller is missing. 6. Submit the Rman job to restore and restore the missing files. Because the database is in Archivelog mode, you can revert to the last commit time, and the user does not need to re-enter any data.
- Perform a full recovery: Missing system Critical data files in Archivelog mode
If a data file is missing or corrupted and the file belongs to the system, UNDO (or Sysaux) tablespace, follow these steps: 1. Instances may or may not shut down automatically. If it is not automatically closed, use shutdown abort to close the instance. 2. Load the database. 3. Restore and restore the missing data files. 4. Open the database. Perform a full recovery: The system Critical data file that is missing in Archivelog mode is considered a system-critical data file that is part of the systems tablespace or data file that contains undo data. If you use Oracle Enterprise Manager for recovery, the Sysaux table space is also critical. If you lose one of these files, you need to restore the database from the Mount state (unlike other data files that can be restored while the database is open). Complete the recovery by performing the following steps: 1. If the instance has not been closed, close the instance. 2. Load the database. 3. On the maintenance (Maintenance) property page, click Perform Recovery (Perform recovery). 4. Select "Datafiles (data file)" As the recovery type, and then select "Restore to Current Time". 5. Add all data files that need to be recovered. 6. Determine whether you want to restore the file to the default location or to a new location if the disk or controller is missing. 7. Submit the Rman job to restore and restore the missing files. 8. Open the database. The user does not need to reenter the data because it will revert to the time of the last commit.
- Recovering a copy of an image
RMAN can use an incremental backup to recover an image copy:? The image copy is updated with all the changes that were made to the SCN for the incremental backup. Incremental backups reduce the time required for media recovery. You do not need to perform an image copy after an incremental restore. A copy of the recovery image can use Rman to apply an incremental backup to a copy of the data file image. In this recovery method, you use Rman to recover a copy of the data file, that is, by applying an incremental backup to the image replica to roll forward (restore) The image copy to a specified point in time. The image copy is updated with all the changes that were before the SCN when the incremental backup was performed. RMAN uses the updated data files obtained in media recovery, as with the full image copy obtained in the SCN, so there is no overhead required to create a full-image copy of the database on a daily basis. The following describes the advantages of using an incremental backup for a copy of a data file image:? Because you only need to apply the archive log since the last incremental backup, you can reduce the time required for media recovery (using archived logs). You do not need to perform a full image copy after an incremental restore. If the recovery process fails during the application of an incremental backup file, only the recovery process needs to be restarted. RMAN automatically determines the incremental backup files that are required for this period of time before the copy of the image data file is created until the recovery process is stopped. If multiple versions of an image copy are recorded in the Rman catalog, Rman automatically uses the latest version of the image copy. If Rman cannot merge the incremental backup file with the image copy, it will report an error.
- Restore Image Replicas: example
If you run the following command every day: rman> recover copy of the database with tag ' daily_inc '; Rman> Backup incremental Level 1 for recover of copy with tag ' daily_inc ' database; The results are as follows: Restoring an image copy: example if you run the command shown above every day, you can get a continuous update of the image copies of all database data files at any time. The chart shows what happens each time the operation occurs. Note that this algorithm requires a period of preparation, and the strategy does not work until the 3rd day. Day 1th: The recover command does not take any action. There is no copy of the image to recover. Backup command to create an image copy. Day 2nd: The Recover command is still not performing any action. Because an incremental backup does not already exist. Because a copy of the baseline image was created on day 1th, the backup command creates an incremental backup. Day 3rd: The Recover command applies changes in the incremental backup to the image copy. The backup command will perform another incremental backup that will be used on the 4th day to restore the image copy. The loop is done accordingly. It is important to use tags when implementing this backup strategy. Tags can link these specific incremental backups to a copy of the image you create. If you do not use tags, you may be able to restore the image copy using the most recent but possibly incorrect incremental backup.
- Perform a quick switchover to the image copy
sql> SWITCH datafile ' filename ' to COPY; Perform a quick switchover to a copy of the image perform the following steps to use the image copy of the data file for rapid recovery: 1. Take the data file offline. 2. Use Switch to ... The copy command points to the image copy of these files. 3. Recover data files. 4. Bring the data file online. At this point, the database is available and the data file has been recovered. However, if you want to put the data file back to its original location, continue with the following steps: 5. Use the Backup as Copy command to create an image copy of the data file in the original location. 6. Take the data file offline. 7. Switch to the copy created in step 5 using the switch to copy command. 8. Recover data files. 9. Bring the data file online. You can use this command to recover data files, tablespace, temporary files, or the entire database. The destination file that you switch to must be a copy of the image.
- Using set newname to switch files
? Use the Set newname command in the run block to revert to a nondefault location. run{ALLOCATE CHANNEL dev1 DEVICE TYPE DISK; ALLOCATE CHANNEL dev2 DEVICE TYPE SBT; SQL "ALTER tablespace users OFFLINE IMMEDIATE";
SET NEWNAME for datafile '/disk1/oradata/prod/users01.dbf ' to '/disk2/users01.dbf ';RESTORE tablespace users; SWITCH datafile All; RECOVER tablespace users; SQL "ALTER tablespace users ONLINE";} ? Specify a default name format for all files in the database or named table spaces, and do not specify individual names individually. The default name is used for the duplicate, restore, and switch commands in the run block. Using the set newname Toggle file Set newname command can only be used in a run block. This command prepares name mappings for subsequent operations. In the example in, the SET newname command defines where the restore operation for the data file is written. After the restore command is executed, the USERS01.DBF data file is restored to/DISK2/USERS01.DBF. The data file is written to that location, but the control file still does not point to that location. The switch command causes the control file to be updated with the new location. A more efficient approach is to use the SET newname clause to specify the default name format for all data files in the named Tablespace and for all data files in the database (instead of setting the file name separately as in the database version before Oracle database 11gR2 (11.2)). The order of precedence for the Set NEWNAME command is as follows: 1.SET NEWNAME for datafile and set NEWNAME for TEMPFILE2. SET NEWNAME for TABLESPACE3. SET NEWNAME for DATABASE
- Substitution Variables for SET newname
run{SET NEWNAME for datafile 1 to '/oradata1/system01.dbf '; SET NEWNAME for datafile 2 to '/oradata2/sysaux01.dbf '; SET NEWNAME for datafile 3 to '/oradata3/undotbs01.dbf '; SET NEWNAME for datafile 4 to '/oradata4/users01.dbf ';
SET NEWNAME for tablespace example to '/oradata5/%b ';DUPLICATE TARGET DATABASE to Dupldb; The substitution variable for set newname is used to avoid possible name collisions when restoring to another location, using an alternate variable for the set newname command. Specify at least one of the following substitution variables:%b,%f, and%u. %i and%n are optional variables. The example shows that the set NEWNAME for tablespace command uses an alternate variable and an explicit set NEWNAME clause to set the default name.
- Perform database restore and restore in Noarchivelog mode
? If any data files are missing when the database is in Noarchivelog mode, perform the following tasks: – If the instance has not been closed, close the instance. – Restore the entire database from backup, including all data files and control files. – Open the database. The user must reenter the changes that have been made since the last backup. Perform database restore and recovery in Noarchivelog mode if any data files in the database are lost in Noarchivelog mode, you need to fully restore the database, including the control files and all data files. If you have an incremental backup, you need to perform a restore and restore operation. If the missing data file belongs to a read-only tablespace, you can simply restore the file. When the database is in Noarchivelog mode, it can only be restored to the state at the time of the last backup. Therefore, the user must reenter the changes that have been made since the last backup. For this type of recovery, use the Restore and recover commands, or perform the following tasks in Oracle Enterprise Manager: 1. If the instance has not been closed, close the instance. 2. On the maintenance (Maintenance) property page, click Perform Recovery (Perform recovery). 3. Select "Whole database" as the recovery type.
A restore point provides a name for a point in time: Use a restore point to specify a name for a specific point in time or SCN number. This can be used as a reference in the future when a point-in-time recovery or flashback operation is performed. The first example creates a restore point that represents the current point in time. If you intend to apply an update to the application or data in the database, and you want to reverse-reference this state of the database, you can use the Before_mods restore point. The second example in creates a restore point that represents the previous SCN 100. This restore point is used the same way as the previous restore point. Under normal circumstances, the restore point remains at least in the database by the
Control_file_record_keep_timeThe length of time specified by the initialization parameter. However, when you create a restore point, you can use the preserve option, which causes the restore point to persist until it is explicitly deleted. You can view the name, SCN, timestamp, and other information for the restore point in the V$restore_point view.
- Perform point-in-time recovery
Perform a point-in-time restore of server management by doing the following: 1. Determine the restore target point: SCN, time, restore point, or log sequence number. 2. Set the NLS environment variable accordingly. 3. Load the database. 4. Prepare and run the run block using the set UNTIL, restore, and recover commands. 5. Open the database in readonly mode and verify that the recovery point is the recovery point you want. 6. Open the database using Resetlogs. Perform point-in-time recovery you can perform a point-in-time recovery of server administration by following these steps. The database must be in Archivelog mode. 1. Determine the restore target. This can be a date and time, an SCN, a restore point, or a log sequence number. For example, if you know that some of the error transactions were committed yesterday 3:00, you can choose yesterday 2:59 as the target restore point time. 2. Set the national Language Support (NLS) operating system environment variable to ensure that the time constants provided for Rman are in the correct format. The following are some example settings: $ export Nls_lang = american_america.us7ascii$ Export Nls_date_format = "Yyyy-mm-dd:hh24:mi:ss" 3. Mount the database. If the database is open, you must close it first, as shown in this example: Rman> shutdown immediaterman> startup Mount 4. Create a run block and run the block. The Recover and restore commands should be in the same run block so that the until settings can be applied to both. For example, if you choose to revert to a specific SCN, the restore command needs to know the value so that the file can be restored from a sufficiently early backup (that is, a backup before the SCN). The following is an example of a RUN block: Run{setUNTIL time ' 2007-08-14:21:59:00 ';RESTORE DATABASE; RECOVER DATABASE;} 5. When you open a database for read/write operations, the restore that you just performed is completed immediately. Therefore, first open the database in read only mode and review some data to see if the recovery operation meets the expected results. Rman> SQL ' ALTER DATABASE OPEN READ only '; 6. If you are satisfied with the recovery result, use the Resetlogs option to open the database as follows: rman> ALTER database open resetlogs;
- Perform recovery using Backup control files
? Restores and mounts backup control files when all copies of the current control file are missing or corrupted. After you restore the backup control file, execute the Recover command. Use the Resetlogs option to open the database after performing a full recovery or point-in-time recovery. Perform recovery using Backup control files if you lose all copies of the current control file, you must restore and mount the backup control file before you perform the restore. You can recover a lost data file by performing a recovery operation, or you can restore only the control file. If the recovery directory is used, the process is exactly the same as recovering using the current control file, because Rman can use the recovery catalog to get the Rman metadata.
- Recovering lost Server parameter files
Use the FROM memory clause to create system-wide current parameter settings. sql> CREATE pfile[= ' pfile_name '] from{{SPFILE [= ' Spfile_name ']} | MEMORY}; sql> CREATE spfile[= ' spfile_name '] from{{PFILE [= ' Pfile_name ']} | MEMORY}; The easiest way to recover a lost server parameters File Recovery Server parameter file is to use theFrom
MEMORYclause, which can use the system-wide current parameter settings to create a text initialization parameter file (PFILE) or a server parameter file (SPFILE). In a RAC environment, the files that are created contain the parameter settings from each instance. During instance startup, all parameter settings are logged to the Alert.log file. In Oracle Database 11g, alert.log parameter dump is written using valid parameter syntax. This makes it easy to cut the parameters and paste them into a separate file, which can be used as a pfile for subsequent instances. When the instance starts, the name of the PFILE or SPFile is written to Alert.log. This is also prompted by the alert log when an unknown client pfile is used. To support additional functionality, you must set the compatible initialization parameter to 11.0.0.0 or higher.
- Restore server parameter files from automatic backup of control files
rman> STARTUP Force Nomount; Rman> RESTORE SPFILE from Autobackup; rman> STARTUP Force; Restore server parameter files from automatic backup of control files if the server parameter file is missing and cannot be usedFrom MEMORYclause, you can restore the file from an automatic backup. This process is similar to restoring a control file from an automated backup. If automatic backups are not located in the Quick recovery area, set up dbid for your database first. Issue the restore SPFILE from autobackup command. If you are restoring SPFILE to a nondefault location, specify the command as follows: Restore SPFILE to <file_name> from Autobackup if you want to restore the server parameter file from the Quick recovery area, specify the command as follows: RMAN > Run {2> restore spfile from autobackup3> recovery area = ' <flash recovery area destination> ' 4> db_name = ' <db_name> ';5>}
- To restore a control file from an automatic backup
Rman> STARTUP Nomount; Rman>RESTORE controlfile from Autobackup; rman> ALTER DATABASE MOUNT; Rman> RECOVER DATABASE; rman> ALTER DATABASE OPEN resetlogs; Restore control files from automatic backup if you do not use the recovery catalog, you should configure automatic backups of the control files so that you can quickly restore the control files if needed. The commands for restoring control files are the same regardless of whether you use the Quick recovery area. However, if you use the Quick recovery area, RMAN will implicitly cross-check the backup and image replicas listed in the control file, and catalog all files that are not recorded in the recovery control file that are located in the Quick Restore area, which improves the role of the restored control files when restoring the rest of the database. Use the command shown above to recover after losing the control file. First, start the instance in Nomount mode. The instance cannot be loaded because there is no control file. Restore the control files from the backup. Because the control file exists, the database can be loaded. Now, you must restore the database because you currently have a backup control file that contains information about the old version of the database. After you restore the database, you can open it. Because the new control file represents a different instance of the database, you must specify Resetlogs. Note: Tape backups are not automatically cross-checked after you restore the control files. If you use tape backup, after you restore the control file and mount the database, you must cross-check the backup on the tape. To restore a control file from an automatic backup, the database must be inNomountState. If the automatic backup is not in the Quick recovery area, you must set the database identifier (DBID) before issuing the restore controlfile from Autobackup command, as shown in the following example:rman> SHUTDOWN ABORT; Rman> STARTUP Nomount;
rman> SET DBID 1090770270;Rman> RESTORE controlfile from Autobackup; Automatic backup of RMAN search control files. If an automatic backup is found, RMAN restores the backup's control file to all the control file locations listed in the Control_files initialization parameters. If you have a recovery directory, you do not have to set up dbid, and you do not have to use automatic control file backup to restore control files. You can use the Restore controlfile command without parameters:rman> the restore controlfile; When you do this, the instance must be in theNomountand Rman must be connected to the recovery directory. The restored control file is written to all the locations listed in the Control_files initialization parameter. Use the Restore Controlfile ... The to <destination> command restores the control file to a nondefault location. If the spfile of the database is also lost and needs to be restored from an automated backup, the restore process is similar to restoring the control file from an automated backup. You must set dbid for the database before you use theRESTORE SPFILE from AutobackupCommand. RMAN can restore control files from an automated backup after the instance is started using the restored server parameters file. After you restore and load the control file, you have the necessary backup information to restore and restore the database. After you restore a control file for a database from a backup, you must perform a full media restore and then open the database by using the Resetlogs option.
- Recovering a database in Noarchivelog mode using an incremental backup
Use an incremental backup to perform a limited recovery on a database in Noarchivelog mode. STARTUP Force Nomount; RESTORE Controlfile; ALTER DATABASE MOUNT; RESTORE DATABASE; RECOVER DATABASE Noredo; ALTER DATABASE OPEN resetlogs; Use an incremental backup to restore a database in Noarchivelog mode use an incremental backup to perform a limited recovery on a database in Noarchivelog mode. An incremental backup must be a consistent backup. If you create an incremental backup, RMAN uses level 0 and Level 1 backups to restore and restore the database. If the online redo log file is missing or cannot be applied to an incremental backup, you must specify the Noredo option in the Recover Database command. If the Noredo option is not specified, RMAN searches for an online redo log file after the incremental backup is applied. If the online redo log file is not available, RMAN publishes an error message. If the current online redo log file contains all the changes since the last incremental backup, you can issue the recover database command and apply the changes without specifying the NOREDO option. Note: You need to restore a control file only if it is not the current control file.
- Restoring and recovering a database on a new host
Use this procedure to perform the following actions:? Perform a test restore? Move the production database to the new host on the new host to restore and restore the database using the procedure that is described in the following pages to perform a test restore. You can also use this procedure to move a production database onto a new host. The database identifier (DBID) of the restored test database is the same as the DBID of the original database. If you use the recovery catalog to connect the test database and the recovery catalog database, the recovery directory is updated with information from the test database. This affects the ability of rman to restore and restore the source database. If your goal is to create a new copy of the target database to be used on the new host, you should use the Rman Duplicate command to create the replica database. The replica database is assigned a new dbid, so the database can be registered in the same recovery directory as the original target database.
- Preparing to restore a database to a new host
To prepare for restoring a database, follow these steps:? Record the database identifier (DBID) of the source database. Copy the source database initialization parameter file to the new host. Ensure that the source backup is accessible on the restore host, including automatic backup of the control files. Note: If you are performing a test restore, do not connect to the recovery directory when you restore the data file. If you connect to the recovery directory, RMAN Records information about the restored data file in the recovery directory, and it also considers that the restored database is the current target database. If the control file is not large enough to contain all the Rman repository data that needs to be restored in the backup, and you must use the recovery catalog at this point, export the recovery directory and import it into a different scenario or database. Use the replicated recovery directory for a test restore.
- Restoring a database to a new host
In order to restore the database, perform the following steps on the restore host: 1. Configure the ORACLE_SID environment variable. 2. Start Rman and connect to the target instance in Nocatalog mode. 3. Set the database identifier (DBID). 4. Launch the instance in Nomount mode. 5. Restore the server parameters file from the backup set. 6. Close the instance. 7. Edit the restored initialization parameter file. 8. Launch the instance in Nomount mode. 9. Create a run block to perform the following tasks: – Restore Control Files – Mount Database 10. Create an Rman recovery script to restore and restore the database. 11. Execute the Rman script. 12. Open the database using the Resetlogs option. Restore a database to a new host to restore the database, follow the steps listed on the Restore host. 1. Configure the ORACLE_SID environment variable, as shown in the following example: $ setenv oracle_sid orcl 2. Start Rman and connect to the target instance. Do not connect to the recovery directory as follows: $ Rman TARGET/ 3. Sets the database identifier (DBID). You can find the dbid of the source database by querying the dbid column in V$database. RMAN> SET DBID 1090770270; 4. Starting an instance in Nomount mode: rman> startup nomount because the server parameter file has not yet been restored, Therefore, you receive an error similar to the following. RMAN launches the instance using the "virtual" parameter file. startup failed:ora-01078:failure in processing system parameters 5. Restore the server parameter file from the backup set and close the instance, as shown in the following example: RESTORE SPFILE to PFILE '?/oradata/test/initorcl.ora ' from Autobackup; 6. Close instance: shutdown immediate; 7. Change any location-specific parameters, such as those that end with _dest, by editing the restored initialization parameter file to reflect the new directory structure. 8. Use the edited text initialization parameter file to launch the instance in Nomount mode. RMAN> STARTUP nomount> pfile= '?Oradata/test/initorcl.ora '; 9. Create a RUN block to restore the control file from an automated backup and mount the database, as shown in the following example: Run{restore controlfile from Autobackup; ALTER DATABASE MOUNT; 10. Query V$datafile on the new host to determine the database file name (recorded in the control file). Create an Rman recovery script to restore and restore the database, depending on the actual situation, you can include the following steps: a. For each data file where the restore destination differs from the location on the original host, use the set newname command to specify its path on the new host. B. Use the SQL ALTER DATABASE RENAME File command to specify the path to the online redo log file. C. Use the set until command to limit the recovery to the end of the archive redo log file. D. include the switch command so that the control file recognizes the new path name as the correct name for the data file. Below is an example of a recovery script: Run{set NEWNAME for datafile 1 to '?/ORADATA/TEST/SYSTEM01.DBF '; SET NEWNAME for datafile 2 to '?/ORADATA/TEST/UNDOTBS01.DBF '; SET NEWNAME for datafile 3 to '?/ORADATA/TEST/SYSAUX.DBF '; SET NEWNAME for datafile 4 to '?/ORADATA/TEST/USERS01.DBF '; SET NEWNAME for datafile 5 to '?/ORADATA/TEST/EXAMPLE01.DBF '; SQL "ALTER DATABASE RENAME FILE"/u01/app/oracle/oradata/orcl/redo01.log "to"?/oradata/test/redo01.log "; SQL "ALTER DATABASE RENAME FILE"/u01/app/oracle/oradata/orcl/redo02.log "to"?/oradata/test/redo02.log "; SQL "ALTER DATABASE RENAME FILE"/u01/app/oracle/oradata/orcl/redo03.log ' to '?/oradata/test/redo03.log ' "; SET UNTIL SCN 4545727; RESTORE DATABASE; SWITCH datafile All; RECOVER DATABASE;} 11. Execute the recovery script. 12. Open the database using the resetlogs option: rman> ALTER database open resetlogs; After the test is complete, you can close the test DB instance and delete the test database and all its files.
- Perform disaster recovery
? A disaster means that the entire target database, the recovery catalog database, all current control files, all online redo log files, and all parameter files are lost. Disaster recovery includes restoring and recovering the target database. Minimum requirements for backup sets: – Backup of data files – corresponding archive redo log files – at least one control file automatic backup to perform disaster recovery disaster recovery includes loss of the entire target database, all current control files, all online redo log files, Restore and restore the target database after all parameter files and the recovery catalog database (if any). To perform a disaster recovery, you need at least the following backups:? Backup of data files? The corresponding archive redo log generated after the backup? At least one control file is automatically backed up to perform the disaster recovery basic process:? Restore automatic backup of server parameter files. Start the target DB instance. Restore control files from automatic backup.? Mount the database. Restore the data file. Recover data files.? Use the Resetlogs option to open the database. The basic process for performing disaster recovery is outlined above. After you mount the database, follow the appropriate steps to perform the recovery using the backup control file.
Source: http://blog.csdn.net/rlhua/article/details/12346829
