OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P69 docx

OCA/OCP Oracle Database 11g All-in-One Exam Guide 636 12. To do an incomplete recovery, what mode must the database be in? (Choose the best answer.) A. Incomplete recovery can be done only with the database SHUTDOWN. B. Incomplete recovery can be done only in NOMOUNT mode. C. Incomplete recovery can be done only in MOUNT mode. D. Incomplete recovery can be in OPEN mode, if the database is in archivelog mode. E. SQL*Plus can do incomplete recovery only in CLOSED mode; RMAN can do it in any mode. 13. When using RMAN to restore a controlfile autobackup, what piece of information might you need to supply? (Choose the best answer.) A. The database name B. The approximate time of the latest backup C. The database ID D. The instance name E. The instance number 14. You are using RMAN to perform incomplete recovery. Which of the following is the best sequence to follow? (Choose the best answer.) A. shutdown abort / startup mount / restore / recover / open resetlogs B. shutdown immediate / startup mount / restore / open resetlogs / recover C. shutdown immediate / restore / recover / open resetlogs D. shutdown immediate / startup nomount / restore / recover / open resetlogs 15. After a RESETLOGS, what will have changed? (Choose all that apply.) A. There will be a new database incarnation number. B. The system change number will be reset. C. The log switch sequence number will be reset. D. The database ID will be changed. E. The instance number will be changed. F. All previous backups and archivelogs will be invalid. 16. Which of the following statements are correct about block media recovery (BMR)? (Choose two answers.) A. BMR can be performed only with RMAN. B. BMR can be performed only with SQL*Plus. C. Both RMAN and SQL*Plus can be used for BMR. D. BMR is always a complete recovery. E. BMR is always an incomplete recovery. F. BMR can be either complete or incomplete; the DBA decides. Chapter 16: Restore and Recover with RMAN 637 PART III 17. If, during an RMAN backup, a corrupt block is encountered, what will happen? (Choose the best answer.) A. The backup will fail. B. The backup will succeed. C. It depends on the MAXCORRUPT setting. D. If the corruption is in the SYSTEM tablespace, the backup will fail; otherwise, it will continue, but the address of the corrupt block will be written to the RMAN repository. 18. To what file types is BMR applicable? (Choose the best answer.) A. Archive log files B. Controlfiles C. Datafiles D. Online log files E. Tempfiles F. All of the above 19. What will be the effect of issuing this command: blockrecover corruption list until time sysdate - 7; (Choose the best answer.) A. The recovery will be up to but not including the system change number of the time specified. B. The recovery will be up to and including the system change number of the time specified. C. The recovery will be complete, but the restore will be from before the time specified. D. The recovery will be of all blocks entered onto the corruption list before the time specified. E. The recovery will be of all blocks entered onto the corruption list after the time specified. Self Test Answers 1. þ A, D, and G. Damage to any controlfile copy will terminate the instance, as will damage to the critical tablespaces: SYSTEM and the current undo tablespace. ý B, C, E, F, and H. All these are noncritical files, damage to which will not cause the instance to terminate. OCA/OCP Oracle Database 11g All-in-One Exam Guide 638 2. þ A. An active log file group contains change vectors referring to blocks that have not yet been written to the datafiles by the DBWn, and cannot be cleared. ý B, C, and D. B is wrong because you cannot issue a CLEAR command while a recovery is progress, and D because multiplexing is not relevant to this. C is relevant because following a checkpoint the group would no longer be active, but this is not the best answer. 3. þ C. This is the only option in noarchivelog mode. ý A, B, and D. These are all attempts at a partial restore, which is not possible in noarchivelog mode. 4. þ A. This is a sequence that will work. ý B, C, and D. None of these sequences is feasible. 5. þ B. This is a sequence that will work. ý A, C, and D. Advice will be generated only for problems discovered by a previous List command, and repair scripts will be generated by the Advise stage. 6. þ A, D, and E. The DRA cannot run against a database that is shut down, nor against any RAC or Data Guard standby database. ý B and C. The DRA can run against a single instance database that is in nomount, mount, or open mode. 7. þ D. The repository exists as operating system files in the location specified by the DIAGNOSTIC_DEST instance parameter. ý A, B, C, and E. The repository is not stored in any database tables, nor by Enterprise Manager. 8. þ A. The ADVISE FAILURE will refer only to failures previously listed. ý B, C, and D. ADVISE FAILURE can run only following LIST FAILURE in the same session, and will refer to the information gathered at that time. 9. þ C. Noncritical datafiles can be restored and recovered while the database is open, if it is running in archivelog mode. ý A, B, and D. Damage to any controlfile copy will cause the instance to terminate, and it cannot be mounted or opened until the damage is repaired. A current multiplexed online log file cannot be repaired, though it can be cleared when no longer current or active. The DRA cannot repair anything—it can only advise. Chapter 16: Restore and Recover with RMAN 639 PART III 10. þ D. An incomplete recovery is required, and the restore can be from the most recent backup of each datafile. ý A, B, and C. A is wrong because an incomplete recovery can follow only a restore of the complete set of datafiles (though in this case, a TSPITR might also have been an option). B is wrong because while it will work, it is less efficient than A: the recovery would take longer because more redo would have to be applied. C is wrong because there is no way to cancel the application of one archive log file, and then continue. 11. þ A and E. Loss of all copies of the current log file group necessitates an incomplete recovery, as does the reversion of the database to a time when a dropped tablespace still existed. ý B, C, and D. The SYSTEM and UNDO tablespaces can be completely recovered, even though they are critical to the running of the database. An uncommitted transaction can never be recovered—it will always be rolled back. 12. þ C. Incomplete recovery can be accomplished only in MOUNT mode. ý A, B, D, and E. MOUNT is necessary, whether you are using RMAN or SQL*Plus. 13. þ C. The DBID will be needed to allow RMAN to identify an autobackup of that particular database. ý A, B, D, and E. The database name will be read from the controlfile, as will details of the last backup. The instance name and number are not relevant. 14. þ A. This is the correct sequence. An IMMEDIATE shutdown would be acceptable but would take longer. ý B, C, and D. These sequences are not possible. 15. þ A and C. A RESETLOGS generates a new database incarnation number and returns the log sequence number to zero. ý B, D, E, and F. The SCN continues to increment following a RESET LOGS, and the DBID remains the same. The instance number is not relevant. Previous backups and archive logs will still be usable (though this was not the case with releases prior to 10g). 16. þ A and D. The BMR capability is a strong reason for using RMAN, but it must be complete. ý B, C, E, and F. SQL*Plus cannot do BMR, and an incomplete BMR is not possible. OCA/OCP Oracle Database 11g All-in-One Exam Guide 640 17. þ C. The MAXCORRUPT setting can be used to allow a backup to skip over one or more corrupted blocks. ý A, B, and D. By default, a corrupt block will cause a backup to fail, but this behavior can be changed. It makes no difference in which tablespace the corrupt block is found. 18. þ C. Only datafile blocks can be recovered with BMR. ý A, B, D, E, and F. Neither log files (of any kind) nor tempfiles can be recovered. BMR cannot be applied to the controlfile: it must be restored and recovered as a whole. 19. þ C. The UNTIL clause in this context determines the latest backup that may be restored. ý A, B, D, and E. A and B are wrong because BMR can be only complete. D and E are wrong because the entire corruption list is always restored and recovered by this command. CHAPTER 17 Advanced RMAN Facilities Exam Objectives In this chapter you will learn to • 053.3.1 Identify Situations That Require an RMAN Recovery Catalog • 053.3.2 Create and Configure a Recovery Catalog • 053.3.3 Synchronize the Recovery Catalog • 053.3.4 Create and Use RMAN Stored Scripts • 053.3.5 Back Up the Recovery Catalog • 053.3.6 Create and Use a Virtual Private Catalog • 053.8.1 Create a Duplicate Database • 053.8.2 Use a Duplicate Database • 053.7.5 Restore a Database onto a New Host • 053.7.7 Perform Disaster Recovery • 053.9.1 Identify the Situations That Require TSPITR • 053.9.2 Perform Automated TSPITR • 053.10.1 Monitor RMAN Sessions and Jobs • 053.10.2 Tune RMAN • 053.10.3 Configure RMAN for Asynchronous I/O 641 OCA/OCP Oracle Database 11g All-in-One Exam Guide 642 Using RMAN for basic backup, restore, and recovery operations has been covered in Chapters 15 and 16. This chapter deals with some more advanced capabilities. First is the recovery catalog: a storage structure for the RMAN repository that, while not essential, will make many operations much simpler. Second, there are facilities for creating databases. Third is tablespace point-in-time recovery: a technique for performing an incomplete recovery on just a part of the database. Finally, we’ll cover some considerations regarding performance and monitoring. The Recovery Catalog RMAN requires a repository in which to store details of all the backups it has made. The repository is a store of metadata about the target database and its backups. It contains details of the physical structure of the database: the locations of the datafiles; details of all the backups that have been made; and RMAN’s persistent configuration settings. The repository is always stored in the controlfile of the target database, and optionally in a recovery catalog as well. EXAM TIP The RMAN repository always exists in the target database controlfile, but it only has data going back as far as the CONTROLFILE_ RECORD_KEEP_TIME parameter. The recovery catalog is an additional store that can retain data indefinitely. If the repository is lost, then RMAN is crippled. Your backups will be fine, but RMAN won’t know where they are. However, it should still be possible to rebuild the repository and continue to work, provided appropriate precautions have been taken. TIP To avoid dependency on the target database controlfile, use a recovery catalog, or if this is not possible, you must enable the controlfile autobackup facility. The Need for a Recovery Catalog RMAN’s repository is always written to the target database’s controlfile, but it can also be written out to a schema in a separate Oracle database. This database is known as the recovery catalog. Using RMAN with a recovery catalog enhances its capabilities substantially. First, and perhaps most important, with a recovery catalog you are no longer dependent upon the target database controlfile. What if all copies of the controlfile are destroyed? Your backups are perfect, but without a repository, RMAN will never be able to find them. In fact, it may be possible to survive this situation: you can instruct RMAN to scan your backup devices and locate and identify any backups, but a far preferable situation is to have the repository always available in a recovery catalog database, on a separate machine from the target. Second, the recovery catalog can store RMAN scripts. Without a recovery catalog, you can still use scripts but they have to be stored as operating system files on the machine where you are running the RMAN executable. Chapter 17: Advanced RMAN Facilities 643 PART III Third, if you are supporting many databases, one recovery catalog can be used to store metadata about all of them. It becomes a centralized repository of all your backup and restore information. Note that one catalog can be used with databases on any platform. You could, for example, run the RMAN executable on a Windows PC and connect to a recovery catalog in a database on a Unix host, and then connect to a series of target databases on Windows, Unix, Open VMS, and any other platform. Fourthly, some operations are greatly simplified with a recovery catalog. For example, the target database need not be in MOUNT mode, as is required for all RMAN operations otherwise (with the one exception of RESTORE . . . FROM AUTOBACKUP). While connected to a recovery catalog, RMAN can locate backups of the spfile and controlfile and restore them, greatly simplifying the bootstrapping process of recovering a severely damaged database. Related to this is the ability to create a new database from a backup of the original. And last, there is no limit to the length of time for which a recovery catalog can retain this metadata. The controlfile-based repository will retain data for only the time specified by the instance parameter CONTROL_FILE_RECORD_KEEP_TIME. This defaults to just seven days. You can certainly increase the value of this parameter, but to increase it to, for example, several months would be to use the controlfile for a purpose for which it was never intended: it is meant to be a store of currently relevant information, not a long-term storage place. The recovery catalog database will usually not be a particularly large or busy database, and it will not have very demanding resource requirements, but it will improve RMAN functionality significantly. Creating and Connecting to the Catalog The RMAN executable can connect, concurrently, to up to three database instances: • A target database, to which a backup or restore and recover operation will be applied • A recovery catalog database, where metadata describing the target and all available backups is stored • An auxiliary database, which is a database to be created using backups of the target The catalog must be created. This entails identifying (or creating) a database to use and then creating a tablespace where the catalog objects will be stored and a user to whose schema they will belong. The user should be granted the RECOVERY_CATALOG_ OWNER role, which includes the necessary object privileges. For example, run these commands in the database to be used for the catalog: create tablespace rmancat datafile 'rmancat01.dbf' size 200m; create user rman identified by rman default tablespace rmancat quota unlimited on rmancat; grant recovery_catalog_owner to rman; OCA/OCP Oracle Database 11g All-in-One Exam Guide 644 TIP There is nothing special about the RECOVERY_CATALOG_OWNER role: it is just a few system privileges. Run this query to see what it can do: select privilege from dba_sys_privs where GRANTEE='RECOVERY_CATALOG_OWNER'; Then to create the catalog, connect with the RMAN executable and run the CREATE CATALOG command, as in Figure 17-1. The first command in Figure 17-1 runs the RMAN executable from an operating system prompt, specifying that the connection should be to a database containing an RMAN catalog. The connection will be made as the user RMAN identified by the password rman, through a TNS connect string catdb. The first command executed at the RMAN prompt is CREATE CATALOG. This will generate the catalog objects. If there were already a catalog in that schema, the command would return an error. The second command at the RMAN prompt connects to a target database as user SYS, using the TNS connect string ORCL. The third RMAN command registers the target in the catalog: the registration process copies all relevant information from the target database’s controlfile into the catalog; if the target database were already registered, this would return an error. From this point it is possible to connect to both catalog and target with one command from an operating system prompt: rman target / catalog rman/rman@catdb EXAM TIP RMAN connections to a target will usually be as SYS because of the common need to issue startup and shutdown commands. There is no need to specify AS SYSDBA—this is assumed by the tool. Figure 17-1 Creating a catalog and registering a database Chapter 17: Advanced RMAN Facilities 645 PART III The syntax in the preceding example is the most commonly used. It uses operating system authentication to connect as user SYS to a local database, and then connects to a remote catalog database as user RMAN using Oracle Net. The RMAN executable must be the same release as the target database, which will always be the case if it is run locally from the target, using the same Oracle Home. The RMAN executable need not be the same version as the RMAN catalog, so there will not be a problem with connecting to it across a network. Alternative syntax would be rman target sys/oracle@orcl catalog rman/rman This syntax connects to the target as SYS using password file authentication and Oracle Net, and to the catalog in a local database as user RMAN. This will often work but is not always advisable because of the possibility of version incompatibilities between the executable and target. The catalog must be created with a version of RMAN that is equal to or higher than the version of any database that will be registered in it. It is therefore possible to create a single catalog of version 11.1.0.6 (11g release 1 patch set 6, the first production release of 11g) and use this to register 11g, 10g, and 9i databases. For each target, use the version of the RMAN executable installed in the target’s Oracle Home. EXAM TIP The RMAN executable must be the same version as the target database, and less than or equal to the version of RMAN used to create the catalog. The Virtual Private Catalog One catalog can register details of all databases in an organization, but in some circumstances it will be desirable to create one or more virtual private catalogs. Security rules may require a separation of duties: some DBAs will be responsible for some databases; other DBAs will be responsible for other databases. To assist in this, RMAN has the capacity to create virtual private catalogs: as a DBA, you can register your own databases in what appears to be your own, private, catalog, and you will not be able to see any databases registered in any other private catalogs. This feature allows the consolidation of several catalogs into one, without compromising security. The steps to create and use virtual private catalogs are 1. Create the catalog as normal. 2. Create an additional schema, and grant it the RECOVERY_CATALOG_OWNER role and the CREATE_SESSION system privilege. 3. Connect to the catalog as the catalog owner with RMAN, and issue this command: grant register database to vpcowner; where vpcowner is the name of the user created in Step 2. This will allow vpcowner to register his own databases. . restore and recover operation will be applied • A recovery catalog database, where metadata describing the target and all available backups is stored • An auxiliary database, which is a database. it can also be written out to a schema in a separate Oracle database. This database is known as the recovery catalog. Using RMAN with a recovery catalog enhances its capabilities substantially. First,. authentication to connect as user SYS to a local database, and then connects to a remote catalog database as user RMAN using Oracle Net. The RMAN executable must be the same release as the target database,