Tài liệu Oracle RMAN 11g Backup and Recovery- P7 doc

268 Part II: Setup Principles and Practices need to work with your system administrator to make sure the following are done before you attempt your restore/recovery: The OS parameters are configured for Oracle. Your disks are configured correctly and are the correct sizes. The tape drives are installed, and the tape software is installed and configured. Your network is operational. The Oracle RDBMS software is installed. The MML is configured. Ancillary items are recovered from backups that RMAN does not back up, which include The database networking files (for example, sqlnet.ora and listener.ora) The oratab file, if one is used The database parameter files, if they are not SPFILEs and are not backed up by RMAN Any RMAN control file backups that were made to disk if you have enabled autobackup of control files Once these items have been restored, you are ready to begin restoring your Oracle database. If you are using a recovery catalog, you will want to recover it first, of course. Then, you can recover the remaining databases. When you start recovering databases, you need to start by recovering the SPFILE (if you are using one and it was backed up), followed by the control file. The next two sections cover those topics for you. A Note about Recoveries, the Recovery Catalog, and the MML Layer In our travels around the world to talk about RMAN, and in our own experiences, we’ve learned a thing or two that really strike us as important. One of these lessons learned is that when you are using one of the MML API interfaces, it is almost a requirement to use a recovery catalog. Why is the recovery catalog so important, you might ask? Remember that all of the important RMAN metadata is stored in the control file. If you lose the control file, then all of this important metadata is lost. If you are doing automated control file backups (set controlfile autobackup on), then this is one way of making sure that you protect the control file from loss. We have had some cases, however, where restoring the control file from the MML backups was quite complex and time-consuming. For example, we have had a case where the backup was successful, but the control file autobackup was not. In this case, you really want to have a recovery catalog available! Having a recovery catalog would have made the job much easier, and when we are talking about restores, time is a precious component. Many of the MML vendors do not support taking RMAN files directly off of their backup media and restoring them without using the RMAN client. ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 12: RMAN Restore and Recovery 269 Also, getting a list of all the RMAN backup set pieces contained on backup media along with the time/date they were created can be difficult. Finally, you cannot use the catalog command to catalog backup set pieces backed up to an MML device. Thus, if you lose your control file and have to recover it manually, the recovery of backup set pieces is much more complex (possible, but complex). Overall, you have several pretty good reasons to use a recovery catalog. We discuss the recovery catalog in great detail in Chapter 10. Restoring the SPFILE If you are not using Oracle9i Release 2 or later and are not using an SPFILE, then this section really does not apply to you. As a result, you need to restore your SPFILE (or your database parameter file) from an operating system backup. On the other hand, if you have started using SPFILEs and you have backed them up using RMAN’s control file autobackup abilities, then you are in good shape! Recall from Chapter 9 that we suggested that if you are performing RMAN database backups without a recovery catalog, you might want to note the DBID of your database for restore and recovery purposes. This is one of those times that such an action comes in handy, though it is not 100 percent critical. SPFILE recoveries come in several flavors, including recoveries that do not use the flash recovery area (FRA) and those that do use the FRA. RMAN offers other ways to recover the SPFILE, as we will find in the following sections. Recovering the SPFILE from an Autobackup Using RMAN, No FRA If you have lost your SPFILE, you will want to recover it from the control file autobackup set if you are using this feature. As we have already described, Oracle will by default back up the SPFILE (along with the control file) to the $ORACLE_HOME/dbs or to the ORACLE_HOME%\database directory (depending on the operating system). If you choose to use the default location (or if you back up to an alternate disk location), you will probably want to back up these backup sets to another backup medium such as tape (which RMAN can do for you). The general procedure to restore the SPFILE is to first set your ORACLE_SID and then log into RMAN. Then, you need to set the DBID, so that RMAN will know which database SPFILE it is looking for. We have to start the database instance at this point in the operation. The instance of an Oracle Database 10g database will not start on its own without a basic parameter file being present. Having started the instance, if you are using the default location to back up your control file autobackup to, you can simply issue the restore spfile from autobackup command, and RMAN will look for the control file backup set that contains the most current SPFILE backup. Once the SPFILE is recovered, you need to shut down the instance and restart it to allow your new SPFILE parameters to take effect. If you are using a nondefault location, then you will need to allocate a channel pointing to that location, and then you can restore the SPFILE using the same method. When you issue the restore spfile from autobackup command, Oracle looks in the default location for automated control file backup sets (or in the location you defined with the allocate channel command). Since you used the set dbid command, RMAN knows your database’s DBID. It uses the DBID to search through the defined directory to look specifically for the most current control file backup sets for your database. When RMAN creates the control file autobackup pieces, it uses a default naming convention. The following graphic shows an example of an Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 270 Part II: Setup Principles and Practices automated control file backup set piece and how the naming convention is used. Note that this naming convention does not apply to the FRA. Keep in mind that if we are not using a recovery catalog (and if we are not using a control file, which is likely), Oracle doesn’t know for sure what the name of the most current control file backup piece is. Thus, Oracle constructs the name of the control file backup piece based on the default naming standard that is used for those backup sets (which we will document later in this chapter). Oracle will traverse the directory, looking backward in time for a control file backup set for your database. By default, Oracle looks for one created within the last ten days. If it cannot find a backup set created within that period, it generates an error. If Oracle finds a valid backup set, it proceeds to restore the SPFILE for you. You can modify how far back RMAN looks for a control file autobackup by using the maxseq and maxdays parameters of the restore command. Here are a couple of examples of recovering control files. First, we use the default settings of the restore command: set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; restore spfile from autobackup; shutdown immediate; We are not that likely to be using the defaults, of course, so let’s assume we need to define a specific location for the autobackups in the restore command. Here is an example of this type of operation: set oracle sid recover rman target sys/robert set DBID 206232339; startup nomount; run { set controlfile autobackup format for device type disk to 'c:\oracle\backup\%F'; allocate channel c1 device type disk; restore spfile from autobackup; } shutdown immediate; Next, we use the maxseq and maxdays parameters to look back beyond the default ten days: Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 12: RMAN Restore and Recovery 271 set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; run { set controlfile autobackup format for device type disk to 'c:\oracle\backup\%F'; allocate channel c1 device type disk; restore spfile from autobackup maxseq 200 maxdays 100; } shutdown immediate; Restoring an SPFILE to a different location and filename is not terribly complex. In this example, we assume that the database is up and running, so we don’t need to indicate the location of the autobackup file sets: set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; restore spfile to 'c:\oracle\spfile.restore' from autobackup; shutdown immediate; Recovering the SPFILE from an Autobackup Using RMAN and the FRA The process to recover the SPFILE when using the FRA is actually much easier than the process if you don’t use the FRA. First, you don’t need to worry about all the DBID nonsense or allocating channels, which saves time and headaches. All you need to do to recover the SPFILE is to configure your temporary parameter file correctly (make sure the FRA destination directory is properly set), start the Oracle instance, and issue the restore spfile command. Here is an example: set oracle sid recover rman target sys/robert startup nomount; restore spfile from autobackup; shutdown immediate; You can still recover the SPFILE by using the maxseq and maxdays parameters, as shown in this snippet: restore spfile from autobackup maxseq 200 maxdays 100; Recovering the SPFILE from a Specific Backup Set If you used RMAN before Oracle Database 10g, you know that recovery of the SPFILE could be difficult if you did not have autobackups configured. In such cases, you needed to write a nasty bit of PL/SQL in order to restore the SPFILE from the RMAN backups. Oracle Database 10g makes this process much easier. Now the restore command includes a from backup clause that allows you to simply indicate the backup set piece that contains the SPFILE backup in it. Thus, all you need to know is the backup set piece name and where it is, and you can restore your SPFILE. In some cases, it might take a bit of trial and error to find the backup set piece with the SPFILE backup in it, but once you do, the restore should be a snap (of course, it would be best to restore the most current control file backup!). Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 272 Part II: Setup Principles and Practices Thus, to restore the SPFILE, start the database instance and identify the backup set piece that contains the SPFILE (or guess at it). Fire up RMAN. You need to set the DBID of the database also (as we have already discussed). Once you have set the DBID, you also need to allocate a channel to the device you are going to restore from. Having allocated the channel, you issue the restore spfile from command, and pass the backup set piece name in at the end of the command. RMAN will then restore the SPFILE to the correct location. Here is an example of this type of restore in action: set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; run { allocate channel c1 device type disk; restore spfile from 'd:\backup\recover\C-2539725638-20060629-00'; } shutdown immediate; You can now perform any additional recovery activities that might be required. Recovering the SPFILE When Using a Recovery Catalog If you are using a recovery catalog, restoring the most current SPFILE is as simple as issuing the restore spfile command after starting (nomount) the Oracle instance. RMAN will use the recovery catalog to locate the most current control file backup and will extract that backup for your use. Here is an example: set oracle sid recover rman target sys/robert catalog rcat manager/password@robt startup nomount; restore spfile from autobackup; shutdown immediate; Note that we shut down the database after the restore. Again, this is to make sure that the database will be restarted using the correct parameter value settings. Restoring the Backed Up SPFILE with an Operational Database Online Extracting a copy of your SPFILE from a database backup with the database up is really easy regardless of whether you are using a control file or a recovery catalog. You should note that this operation will result in a text parameter file, and not an SPFILE, so you will need to convert it if you wish it to be an SPFILE. If you are not using a recovery catalog and you have enabled automatic backups of control files, just issue the following command: RMAN> restore spfile to pfile 'd:\backup\test.ora' from autobackup; This command restores the SPFILE to a file called test.ora in a directory called d:\backup. Again, with any autobackup restore, RMAN looks only for the past seven days to find a control file autobackup piece unless you supply maxseq and maxdays parameter values. If you are not using a recovery catalog and are not using control file autobackups, or if you are using a recovery catalog, then this is the command you would use: Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 12: RMAN Restore and Recovery 273 RMAN> restore spfile to pfile 'd:\backup\test.ora'; In this case, Oracle uses the control file of the database to locate the most current backup set to restore the SPFILE from. So, now that you have your SPFILE back, you are ready to go out and recover your control file. Restoring the Control File Restoring the control file is not much different from restoring your SPFILE. First, the database needs to be mounted; so to restore the control file, you should have already restored your SPFILE, or have created one, and mounted your database. Once that occurs, you are ready to proceed to recover the control file for your database. Control file recoveries come in several flavors, including recoveries that do not use the FRA and those that do use the FRA. In the following sections, we deal with additional control file recovery situations. Recovering the Control File from an Autobackup Using RMAN, No FRA If you have lost your control file and you are not using the FRA, you will want to recover the file from the control file autobackup set (if you are using this feature, which we strongly recommend). As we have already described, Oracle will by default back up the control file (along with the SPFILE) to the $ORACLE_HOME/dbs or $ORACLE_HOME/database directory (depending on the operating system). If you choose to use the default location (or if you back up to an alternate disk location), you will probably want to back up these backup sets to another backup medium such as tape (which RMAN can do for you). When restoring the control file, it is assumed that the instance parameter file has been restored and that the instance can be started (for example, by using startup nomount). Once the instance is up and running, the general procedure to restore the control file when not using the FRA is to first set your ORACLE_SID and then log into RMAN (if you have not done so already). As with SPFILE restores, you need to set the DBID so that RMAN will know which database control file it is looking for. We are now ready to restore the control file. As with the SPFILE restore, if you are using the default location (not likely) to back up your control file autobackup to, you can simply issue the restore control file from autobackup command, and RMAN will look for the control file backup set that contains the most current control file backup. Once the control file is recovered, you need to shut down the instance and restart it to allow your new control file parameters to take effect. If you are using a nondefault location, then you need to use the allocate channel command to allocate a channel pointing to that location, and then you can restore the control file using the same method. When you issue the restore controlfile from autobackup command, Oracle looks in the default location for automated control file backup sets (or in the location you defined with the allocate channel command). Since you used the set dbid command, RMAN knows your database’s DBID. It uses the DBID to search through the defined directory to look specifically for the most current control file backup sets for your database. See the previous section on SPFILE recoveries for more information about the format of the naming convention that RMAN uses for control file autobackup backup sets. As with SPFILE recoveries, you can modify how far back RMAN looks for a control file autobackup by using the maxseq and maxdays parameters of the restore command. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 274 Part II: Setup Principles and Practices Let’s look at some examples of recovering control files. First, we use the default settings of the restore command: set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; restore controlfile from autobackup; shutdown immediate; Next, we use the maxseq and maxdays parameters to look back beyond the default ten days. This time we assume that we are not backing up to a default location: set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; run { set controlfile autobackup format for device type disk to 'c:\oracle\backup\%F'; allocate channel c1 device type disk; restore controlfile from autobackup maxseq 200 maxdays 100; } shutdown immediate; Restoring a control file to a different location and filename is not terribly complex. In this example, we assume the database is up and running, so we don’t need to define the location of the control file autobackups: set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; run { restore controlfile to 'c:\oracle\control file.restore' from autobackup; } shutdown immediate; Recovering the Control File from an Autobackup Using RMAN and the FRA As was the case with SPFILE recoveries, the process to recover the control file when using the FRA is very easy. First, ensure that the parameters defining the location of the FRA are set correctly. Then, start the database instance; issue the restore controlfile from autobackup command, and the control file will be recovered. Here is an example: set oracle sid recover rman target sys/robert startup nomount; Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 12: RMAN Restore and Recovery 275 restore controlfile from autobackup; shutdown immediate; You can still recover using the maxseq and maxdays parameters, as shown in this snippet: restore controlfile from autobackup maxseq 200 maxdays 100; Recovering Older Control File Backups You may wish to restore a control file backup that was taken some time ago, such that it’s not the most current backup (this is often the case if you issued a resetlogs command). The restore controlfile from autobackup command allows you to do this when coupled with the until time parameter. For example, we can find and restore the control file backup created on or before 12/09/2005 at 04:11 A.M. by issuing this command: restore controlfile from autobackup until time "to date('12/09/2005 13:00:00','MM/DD/YYYY HH24:MI:SS')"; You will want to know which control file backups are available to restore if you are going to use this command. We discuss the list command in more detail in Chapter 18, but for now, you should know that you use the list backup of controlfile command to determine which control file backups are available for you to restore. Here is an example: RMAN> list backup of controlfile; List of Backup Sets BS Key Type LV Size Device Type Elapsed Time Completion Time 38 Full 6.80M DISK 00:00:05 01-JAN-06 BP Key: 39 Status: EXPIRED Compressed: NO Tag: TAG20060108T183828 Piece Name: C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\TESTOEM \AUTOBACKUP\2006 01 08\O1 MF S 579206308 1W3D485F .BKP Control File Included: Ckp SCN: 3568285 Ckp time: 08-JAN-06 BS Key Type LV Size Device Type Elapsed Time Completion Time 40 Full 6.80M DISK 00:00:06 08-JAN-06 BP Key: 41 Status: AVAILABLE Compressed: NO Tag: TAG20060108T183857 Piece Name: C:\ORACLE\PRODUCT\10.2.0\FLASH RECOVERY AREA\TESTOEM \AUTOBACKUP\2006 01 08\O1 MF S 579206337 1W3D5495 .BKP Control File Included: Ckp SCN: 3568311 Ckp time: 08-JAN-06 In the preceding example, we used the list command to discover that we have two different control file backups. The first control file backup (BS Key 38) has a status of EXPIRED because of the current backup retention policy. Since it is expired, RMAN will not try to use it during a restore operation (if the backup set piece is still available, we can change the status with the change command and be able to use it). The second control file backup (BS Key 40) is available. RMAN will be able to restore this backup. Note that the list command is only available if you have the database mounted with a current control file. If you do not have a control file available, then the list command will not work. Also, if you do not have a control file available, then the retention criteria will not be an issue, and you could restore any control file by using the autobackup command. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 276 Part II: Setup Principles and Practices Recover the Control File from a Backup Set If you used RMAN before Oracle Database 10g, you know that recovery of the control file could be difficult if you did not have autobackups configured. In such cases, you needed to write a nasty bit of PL/SQL in order to restore the control file. Since Oracle Database version 10g control file recovery is much easier. Now the restore command includes a from backup clause that allows you to simply indicate the backup set piece that contains the control file backup in it. Thus, all you need to know is the backup set piece name, and where it is, and you can restore your control file. In some cases, it might take a bit of trial and error to find the backup set piece with the control file backup in it, but once you do, the restore should be a snap (of course, it would be best to restore the most current control file backup!). To restore the control file, start the database instance and identify the backup set piece that contains the control file (or guess at it). Fire up RMAN. You will need to set the DBID of the database also (as we have already discussed). Once you have set the DBID, you will also need to allocate a channel to the device you are going to restore from. Having allocated the channel, you issue the restore controlfile from command, and pass the backup set piece name in the end of the command. RMAN will then restore the control file and replicate it to the different CONTROL_ FILE parameter locations. Here is an example of this type of restore in action: set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; run { allocate channel c1 device type disk; restore controlfile from 'd:\backup\recover\C-2539725638-20020629-00'; } shutdown immediate; You can now perform any additional recovery activities that might be required. Recovering a Control File Using a Recovery Catalog If you are using a recovery catalog, restoring the most current control file backup is as simple as issuing the restore controlfile command. RMAN will use the recovery catalog to locate the most current control file backup and will extract that backup for your use. Here is an example: set oracle sid recover rman target sys/robert catalog rcat manager/password@robt # Note - We would issue a startup nomount # and restore control file from autobackup here if we needed to. # shutdown immediate here if we recovered the control file. startup nomount; restore controlfile; # mount the database in preparation for a restore. alter database mount; Database Recovery after Restoring a Control File When you restore a control file with RMAN (and there are no datafiles or online redo logs lost), you have two different things to consider. First, you need to consider how to actually get your Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 12: RMAN Restore and Recovery 277 database up and running after restoring the control file. Second, you need to recover information related to RMAN, such as registering archived redo logs and backup sets in the newly created control file with RMAN. Let’s look at each of these topics in a bit more detail. Opening the Database after a Control File Recovery In the event that only your control file was lost, recovery of the control file and your database is generally pretty straightforward (if any kind of Oracle recovery can be thought of as straightforward). The commands to recover the control file are the same; you just need to simulate incomplete recovery in order to open the database. Note that in some cases, you may need to register archived redo logs or even register backup sets before you can complete recovery. We discuss this process in the next section. If you are running in NOARCHIVELOG mode, you would use the following method (in this example, we assume you are not using the FRA, so we set the DBID): set oracle sid recover rman target sys/robert set DBID 2539725638; startup nomount; restore controlfile from autobackup; alter database mount; recover database noredo; alter database open resetlogs; If you are running in ARCHIVELOG mode, recovery is only slightly different (note in this example, we are assuming you are using the FRA, so we do not set the DBID): set oracle sid recover rman target sys/robert startup nomount; restore controlfile from autobackup; alter database mount; recover database; alter database open resetlogs; Of course, loss of other database physical files can make this complex. Also, if you don’t have a recent control file backup, then things can get quite complicated, and you may end up having to manually re-create the control file with the create control file command. This is a horror we hope you never have to face, and you should not need to face it if your backup and recovery strategy is sound. Restoring RMAN-Related Records to the Control File Once you have restored the control file, you need to consider the distinct possibility that you have lost RMAN-related data. Since RMAN stores all of its data in the control file, there is a good possibility that you have at least lost some records that relate to archived redo logs (which Oracle needs for a full recovery). RMAN makes this problem easier to deal with, because you can register various RMAN- related backup files after the restore of a control file just to ensure that you have everything you need for a recovery in the control file. To re-create RMAN-related archived redo log records, you can use the RMAN catalog command to register archived redo logs in your control file. The catalog command can be used to register a specific backup set piece, as shown in this example: RMAN>Catalog backuppiece 'c:\oracle\product\10.2.0\flash recovery area \testoem\backupset\2005 12 09\O1 MF ANNNN TAG20051209T041150 1SLP386H .BKP'; Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... recovery catalog and you have enabled automatic backups of control files, just issue the following command: RMAN> restore controlfile to 'd: \backup' from autobackup; This command restores the SPFILE to a file called test.ora in a directory called d: \backup Again, with any autobackup restore, RMAN looks only for the past seven days by default to find a control file autobackup piece Use maxseq and maxdays... and it will validate the integrity of those backups You can also use the restore preview command to identify the backups that will be needed to restore the database (much like the list command that we discuss in Chapter 18) NOTE The restore preview command can be quite handy if you are moving backup sets from a storage device that RMAN is not aware of For example, if you back up to disk with RMAN and. .. interface and a command-line interface In this section, we will cover the command-line interface If you wish to use the OEM interface, please refer to Chapter 13, which contains much more information about using OEM and RMAN Using the Data Recovery Advisor Through RMAN To use the manual interface into the Data Recovery Advisor, you simply use the RMAN command-line interface Oracle has added new RMAN commands... files: configure controlfile autobackup on; In this case, we are accepting that the control file backup set pieces will be created in the default location Step 2 Complete a backup of your system (in this case, we assume this is a hot backup) In this workshop, we assume that the backup is to a configured default device: set oracle sid recover rman target rman backup/ password backup database plus archivelog;... newname for datafile and switch commands These commands, when used in concert with restore and recover commands, allow you to tell RMAN where the datafiles need to be placed The set newname command offers several options with respect to relocation of database datafiles In Oracle Database 10g and earlier, you can set the new name for individual datafiles In Oracle Database 11g, new features include the ability... and Practices RMAN Workshop: Recover Your NOARCHIVELOG Mode Database Workshop Notes For this workshop, you need an installation of the Oracle software and an operational test Oracle database NOTE For this workshop, the database is in NOARCHIVELOG mode Step 1 Set the ORACLE_ SID and then log into RMAN Ensure that you have configured automated backups of your control files Because this is an offline backup, ... down and mount the database: set oracle sid recover rman target rman backup/ password configure controlfile autobackup on; shutdown immediate; startup mount; Note that in this case, we are accepting that the control file backup set pieces will be created in the default location Step 2 Complete a cold backup of your system In this workshop, we assume that the backup is to a configured default device: backup. .. automated backups of your control files: set oracle sid recover rman target rman backup/ password configure controlfile autobackup on; Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 12: RMAN Restore and Recovery 291 Note that in this case, we are accepting that the control file backup set pieces will be created in the default location Step 2 Because this is an online backup, ... process The restore command is used to restore SPFILEs and control files from automated backups The restore command can also be used to create a standby control file for a standby database You also use the restore command to restore the database to any point in time, and in that case, it will find the closest backups to that given point in time to restore Without a recovery catalog, RMAN can restore the... the list failure command, then the advise failure command, and finally, the repair failure command, in that order Let’s look at the use of these commands in a bit more detail The list failure Command The RMAN list command now has a new failure parameter that will list detected failures and their priorities (Critical, High, or Low), status (Open or Closed), when they occurred, and a summary of the failure . files from RMAN backups in preparation for recovery. RMAN and the restore command are quite intelligent, and they will choose the most recent backup to. control file autobackup to, you can simply issue the restore control file from autobackup command, and RMAN will look for the control file backup set that