OCA/OCP Oracle Database 11g All-in-One Exam Guide 626 or on Unix or Linux: export NLS_DATE_FORMAT=dd-mm-yy hh24:mi:ss 1. Connect to the database with RMAN, and perform a full whole backup: rman target / RMAN> backup as compressed backupset database; 2. Connect to the database with SQL*Plus as user SYSTEM, and force a few log switches and archives by executing this command a few times: alter system switch logfile; 3. Connect to the database with RMAN, and back up the archive logs while removing them from the archivelog destinations: backup archivelog all delete all input; 4. Repeat Step 2. 5. Note the current time: select sysdate from dual; 6. Wait a few seconds, and insert a second row into the ex16 table: insert into ex16 values(sysdate); commit; 7. Drop the tablespace, and attempt to query the ex16 table: drop tablespace noncrit including contents and datafiles; select * from ex16; 8. In your RMAN session, execute this run block to restore the controlfile, substituting the time you noted in Step 5 for that shown, and using a suitable name for the restored controlfile: run {shutdown abort; startup mount; set until time = '26-10-08 15:35:33'; restore controlfile to '/u01/app/oracle/oradata/orcl/control04.ctl';} It is not possible to restore the controlfile over the current controlfile copies, because they are already in use to mount the database. 9. In your SQL*Plus session, adjust the CONTROL_FILES parameter so that the restored controlfile will be used for the next mount: SQL> alter system set control_files='/u01/app/oracle/oradata/orcl/control04.ctl' scope=spfile; SQL> shutdown abort; SQL> startup mount; 10. In your RMAN session, run {allocate channel d1 type disk; allocate channel d2 type disk; set until time = '26-10-08 15:35:33'; restore database; Chapter 16: Restore and Recover with RMAN 627 PART III recover database; alter database open resetlogs}; 11. Study the output of running the block in Step 8. In particular, note these points: • Two channels were used, to parallelize the operation. • The date given must conform to that specified by the NLS_DATE_FORMAT environment variable. • The restore will have been from the most recent backup earlier than the UNTIL time. • The recovery uses a combination of archive logs on disk, and archive logs extracted from a backup set. 12. Connect to the database with SQL*Plus as user SYSTEM, and confirm that while the restore and recovery has succeeded, the row inserted after the UNTIL time is gone: select * from ex16; 13. Confirm that the log sequence number has been reset to 1: select * from v$log; Using Image Copies for Recovery If your backup strategy includes creating image copies as well as (or instead of) backup sets, then you have another option available for restore operations: do not restore at all. As an image copy is byte-for-byte the same as the source datafile, it can be used immediately if it is still available on disk. All that is necessary is to tell the database the location of the image copy, and then recover the copy. This can result in massive time savings when compared with the delays involved in extracting a datafile from a backup set. To facilitate the use of image copies, use the following RMAN command: RMAN> backup as copy database; This command will copy every datafile to the flash recovery area, as image copies. To use an image copy, first take the original datafile offline (which will have happened automatically in many cases) and then update the controlfile to point to the copy, and recover it. For example, if a copy has been made as follows: RMAN> backup as copy datafile 4 format '/u02/df_copies/users.dbf'; Then it can be brought into use like this: RMAN> run {sql 'alter database datafile 4 offline'; set newname for datafile 4 to '/u02/df_copies/users.dbf'; switch datafile 4; recover datafile 4; sql 'alter database datafile 4 online';} OCA/OCP Oracle Database 11g All-in-One Exam Guide 628 This accomplishes a complete recovery, without actually needing to restore. The SWITCH command is equivalent to the ALTER DATABASE RENAME FILE command that can be executed in SQL*Plus. If the whole database has been copied to the flash recovery area then the whole database can be “restored” with one command: RMAN> switch database to copy; EXAM TIP Any SET commands, such as SET UNTIL, SET NEWNAME, and SET DBID, can be executed only within a run block, never as stand-alone commands at the RMAN prompt. TIP Maintaining a reasonably up-to-date image copy of the database will mean that the downtime involved in any restore and recover operation is substantially reduced. If you have the disk space available, you should consider doing this. Another use of image copies is to update them by applying incremental backups. This technique of updating copies with incremental backups takes a full copy as its starting point, and then rolls the copy forward by applying the incrementals. This requires as a starting point a complete copy of the database (which can be made while the database is open), followed by creating incremental backups with the syntax that will permit them to be applied to the copy. This simple script, just two commands, can accomplish the entire process: run { backup incremental level 1 for recover of copy with tag 'inc_copy' database; recover copy of database with tag 'inc_copy' ; } The first time the script is run, the BACKUP command will attempt a level 1 backup, but as there is no level 0 backup on which to base the level 1, it will perform a level 0 backup instead. The syntax will cause RMAN to make this as a copy, rather than as a backup set. The RECOVER command will fail, because there will be neither a copy of the database nor an incremental backup to apply. The second time the script is run, the first command will perform a level 1 backup, extracting all changed blocks since the first run. The second command will apply this incremental backup to the copy. This behavior will continue for all subsequent runs. A strategy based on incrementally updated backups can result in very fast recovery times, with minimal backup workload on the live database: there is only ever one full backup, and (if the script is run daily) the worst case is that the copy would be one day behind. It will be necessary to back up the copy (with, for example, BACKUP RECOVERY AREA if the copy has been directed to the flash recovery area) and the archive log files, because without this a point-in-time recovery to any time earlier than the most recent run of the script will be impossible. Chapter 16: Restore and Recover with RMAN 629 PART III Block Recovery In all the restore and recover operations described so far in the chapter, the granularity of the restore has been the file: every example has restored a complete file, and recovered it. While this is necessary if a file has been completely destroyed (by accidental deletion, perhaps), in many cases damage is limited to just a small range of blocks: the file remains usable, but certain blocks will have been corrupted. In this case, the file will remain online, and the end users may not be aware that there is a problem. They will only find out when they attempt to read the damaged blocks: if a session hits a corrupted block, it will return an error to the user process, and a message will be written to the alert log. RMAN can also detect corrupted blocks, and furthermore it can repair them. Detection of Corrupt Blocks RMAN will detect corrupt blocks as it performs backup operations. Unless instructed otherwise, it will terminate the backup as soon as it hits a corrupt block. If you wish, you can run RMAN backups that specify a tolerance for corrupted blocks. If this is done, then rather than throwing an error and terminating the backup immediately when a corruption is detected, RMAN will continue to back up the datafile but will record the addresses of any corruptions it encounters in its repository. This example instructs RMAN to continue a backup as long as no more than 100 corrupt blocks are encountered: RMAN> run { set maxcorrupt for datafile 7 to 100; backup datafile 7;} The details of corrupt blocks are visible in two places. The view V$DATABASE_ BLOCK_CORRUPTION shows the address of the cause of the problem: the datafile file number and block number. The address of the block in the backup is also visible in V$BACKUP_CORRUPTION for corruptions encountered by backup set backups, or in V$COPY_CORRUPTION if the backup were to an image copy. In normal running, you would not use the SET MAXCORRUPT keywords. Without them, the backup will fail and you will thus be made aware of the problem immediately. Then rerun the backup with SET MAXCORRUPT and after completion query the views to determine the extent of the damage. By default, RMAN will always check for physical corruption, known as “media corruption” in the non-RMAN world. An example of this would be a block that Oracle cannot process at all: an invalid checksum, or a block full of zeros. RMAN can also be instructed to check for logical corruption, also known as “software corruption,” as well. These checks will occur whenever a file is backed up, whether as an image copy or into a backup set. To override the defaults, RMAN> backup nochecksum datafile 7; OCA/OCP Oracle Database 11g All-in-One Exam Guide 630 will not check for physical corruption, but RMAN> backup check logical datafile 6; will check for logical as well as physical corruption. Block Media Recovery If RMAN has detected a block corruption, it can do Block Media Recovery, or BMR. BMR changes the granularity of a restore and recover operation from the datafile to just the damaged blocks. This has two huge advantages over file restore and recover: first, the file does not have to be taken offline; normal DML can continue. Second, the mean time to recover is much reduced, since only the damaged blocks are involved in the operation, not the whole file. The only downtime that will occur is if a session happens to hit a block that is actually damaged and has not yet been recovered. The BMR mechanism provides RMAN with a list of one of more blocks that need recovery. RMAN will extract backups of these blocks from a backup set or an image copy and write them to the datafile. Then RMAN will pass through the archive logs generated since the backup and extract redo records relevant to the restored blocks and apply them. The recovery will always be complete—it would be logically impossible to do an incomplete recovery; incomplete recovery of just one block would leave the database in an inconsistent state. If a session hits a corrupted block before the BMR process has completed, then it will still receive an ORA-01578 error, but it is quite possible that the BMR operation will be complete before any users are aware of the problem. The BLOCK RECOVER Command The BLOCK RECOVER command always specifies a list of one or more blocks to be restored and recovered, and it optionally specifies the backup from which the restore should be made. For example, this command, RMAN> block recover datafile 7 block 5; instructs RMAN to restore and recover the one specified block from the most recent backup set or image copy of the file. The syntax would also accept a list of blocks in several files: RMAN> block recover datafile 7 block 5,6,7 datafile 9 block 21,25; There may be doubt regarding the integrity of the backups. In that case, you can instruct RMAN to restore the block(s) from a backup that is known to be good: RMAN> block recover datafile 7 block 5 from backupset 1093; will restore from the nominated backup set, which could also be specified by a tag: RMAN> block recover datafile 7 block 5 from tag monthly_whole; Chapter 16: Restore and Recover with RMAN 631 PART III If the damage is more extensive, then two other options for BMR will simplify the process. First, provided that RMAN has populated the view V$DATABASE_BLOCK_ CORRUPTION by running a backup with MAXCORRUPT set to greater than zero, then the CORRUPTION LIST option will instruct RMAN to restore and recover every block listed in the view. Second, to ensure that the backup(s) used for the restore are from a time before the corruption occurred, there is the UNTIL option. For example, RMAN> block recover corruption list until time sysdate - 7; instructs RMAN to restore and recover every block that has been discovered to be damaged by a previous backup operation, using only backups made at least one week ago. TIP In the BMR context, the keyword UNTIL does not denote an incomplete recovery! It means that the restore must be from a backup made before a particular date (or sequence number or SCN). Two-Minute Drill Describe the Data Recovery Advisor • The Automatic Diagnostic Repository (ADR) is a set of files in the DIAGNOSTIC_DEST directory. • The DRA can repair damage to datafiles and controlfile, and replace missing log file groups. • Restore and recovery of the controlfile or a critical datafile can be done only in mount mode. • Restore and recovery of a noncritical datafile can be done while the database is open. Use the Data Recovery Advisor to Perform Recovery (Control File, Redo Log File, and Datafile) • Failures must be listed before they can be advised upon. • The DRA can be accessed through the RMAN executable or with Enterprise Manager. • The DRA is available in all modes: in nomount mode it can repair the controlfile; in mount or open mode it can repair datafiles. Perform Complete Recovery from a Critical or Noncritical Data File Loss Using RMAN • Only the datafiles that make up the SYSTEM and the current undo tablespaces are critical. Damage to other datafiles will not cause the database to crash. OCA/OCP Oracle Database 11g All-in-One Exam Guide 632 • Restore and complete recovery of noncritical datafiles can be carried out with the database open; critical datafiles must be restored and recovered in mount mode. • RMAN will recover by applying incremental backups if possible, and archive log files when necessary. Perform Incomplete Recovery Using RMAN • Incomplete recovery can be accomplished only in mount mode. • If all copies of the current online log file group are lost, an incomplete recovery will be required. • The complete set of datafiles must be restored. • Recovery will be stopped by use of the UNTIL clause, up to (but not including) a nominated time, archive log sequence number, or system change number. • Following incomplete recovery, the database must be opened with RESETLOGS to reinitialize the online log files. Recover Using Incrementally Updated Backups • An image copy of a datafile (or the whole database) can be updated by applying incremental backups. • The incremental backup must be made with the syntax: BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY • The incremental backup can be applied with the syntax: RECOVER COPY OF Switch to Image Copies for Fast Recovery • Image copies are immediately usable; there is no need to restore them. • The SET NEWNAME command informs RMAN that the copy is to be used; the SWITCH command updates the target database controlfile accordingly. Recover Using a Backup Control File • A backup controlfile must be used if an incomplete recovery is to a time when the physical structure was different from that at present. • If all copies of the controlfile are lost, the controlfile can be restored, in nomount mode, from an autobackup. • If no datafiles or online log files are damaged, complete recovery using a backup controlfile is possible—but an OPEN RESETLOGS will be necessary. Chapter 16: Restore and Recover with RMAN 633 PART III Perform Block Media Recovery • A backup operation will fail if it encounters a corrupt block, unless SET MAXCORRUPT has been specified. • BMR can be accomplished with the database open and the datafile online. • Corrupted blocks detected by RMAN will be visible in the V$DATABASE_ BLOCK_CORRUPTION view. • The BLOCK RECOVER command can recover a nominated list of blocks, or all blocks listed the V$DATABASE_BLOCK_CORRUPTION view. Self Test 1. Loss of which of these files will cause an open database to crash? (Choose all correct answers.) A. A multiplexed controlfile B. A multiplexed online log file C. A multiplexed archive log file D. An active undo tablespace datafile E. An active temporary tablespace tempfile F. A datafile from the SYSAUX tablespace G. A datafile from the SYSTEM tablespace H. A datafile containing critical user data 2. You issue the command ALTER DATABASE CLEAR LOGFILE GROUP 2, and it fails with the message “ORA-01624: log 2 needed for crash recovery of instance orcl11g (thread 1).” What could be an explanation for this? (Choose the best answer.) A. Log file group 2 is active. B. Log file group 2 is being used for recovery. C. The database has not been checkpointed. D. The group is not multiplexed. 3. Your database is in noarchivelog mode, and you lose a noncritical datafile. What can you do to minimize loss of data? (Choose the best answer.) A. Restore the one damaged file, and leave the rest of the database up-to-date. B. Restore all the datafiles, but leave the controlfile up-to-date. C. Restore the whole database, and clear the online redo logs. D. Restore the one damaged file, and apply the online redo logs. OCA/OCP Oracle Database 11g All-in-One Exam Guide 634 4. What sequence will allow you to add a multiplexed controlfile copy? (Choose the best answer.) 1. Adjust the CONTROL_FILES parameter. 2. Copy the controlfile. 3. Mount the database. 4. Open the database. 5. Recover the controlfile. 6. Recover the database. 7. Shut down the database. A. 7, 2, 1, 3, 4 (5 and 6 not necessary) B. 7, 1, 3, 2, 6, 4 (5 not necessary) C. 2, 1, 5 (3, 4, 6 and 7 not necessary) D. 7, 1, 6, 3, 4 (2 and 5 not necessary) 5. These are three DRA commands: ADVISE FAILURE; LIST FAILURE; REPAIR FAILURE; In what order must they be run to fix a problem? (Choose the best answer.) A. ADVISE, LIST, REPAIR B. LIST, ADVISE, REPAIR C. LIST, REPAIR (ADVISE is not necessary) D. ADVISE, REPAIR (LIST is not necessary) 6. On what type or state of database can the DRA not be used? (Choose all correct answers.) A. A single-instance database that is shut down B. A single-instance database in nomount mode C. A single-instance database in mount mode D. An open RAC database E. A mounted standby database 7. Where is the Automatic Diagnostic Repository stored? (Choose the best answer.) A. In the Automatic Workload Repository B. In the SYSAUX tablespace C. In the data dictionary D. In operating system files E. In the Enterprise Manager repository Chapter 16: Restore and Recover with RMAN 635 PART III 8. If you issue the LIST FAILURE command with the DRA and then another failure occurs, when you run ADVISE FAILURE for what will you receive advice? (Choose the best answer.) A. For the original failures only B. For the new failure only C. For all the failures D. For none of the failures until you run a new LIST FAILURES 9. Which file types can be repaired while the database is open? (Choose the best answer.) A. A damaged multiplexed controlfile copy B. A current multiplexed online log file C. A damaged noncritical datafile, if the database is in archivelog mode D. All of the above, if the DRA is used and server-managed backups are available 10. It is now 15:00, on Tuesday. A bad transaction was committed in your database at about 14:30. Investigation shows that the tables and indexes affected were in just two tablespaces: the rest of the database is fine. The two tablespaces and several others were backed up last night, but some tablespaces are backed up only on the weekend. Your database is in archivelog mode, with log switches about every 10 minutes. Which of the following statements is correct? (Choose the best answer.) A. You can do an incomplete restore and recovery to 14:29, of just the two tablespaces. The loss of data will be about 30 minutes of work in those tablespaces. B. You must restore the whole database from the weekend backup and recover to 14:29. You will lose about 30 minutes of work. C. You must restore the whole database and do an incomplete recovery canceling the application of the archive log that was active at 14:30. You will lose about 10 minutes of work. D. You can restore some tablespaces from last night, the others from the weekend, and recover to 14:29. You will lose about 30 minutes of work. 11. Under which of the following circumstances is an incomplete recovery necessary? (Choose two answers.) A. You lose all copies of your current online log file group. B. You lose a critical tablespace: SYSTEM, and/or the currently active UNDO tablespace. C. A user makes a bad transaction, and the instance crashes before he can issue the ROLLBACK statement. D. A datafile is created, used, and destroyed before it gets backed up. E. You back up a tablespace, drop it, and then want to get to the objects that were in it. . {sql 'alter database datafile 4 offline'; set newname for datafile 4 to '/u02/df_copies/users.dbf'; switch datafile 4; recover datafile 4; sql 'alter database datafile. online';} OCA/ OCP Oracle Database 11g All-in-One Exam Guide 628 This accomplishes a complete recovery, without actually needing to restore. The SWITCH command is equivalent to the ALTER DATABASE. Noncritical Data File Loss Using RMAN • Only the datafiles that make up the SYSTEM and the current undo tablespaces are critical. Damage to other datafiles will not cause the database to crash. OCA/ OCP