OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P67 pps

OCA/OCP Oracle Database 11g All-in-One Exam Guide 616 This command will locate all cumulative and differential incremental level 1 backups and apply them. The NOREDO qualifier is needed to instruct RMAN not to attempt to apply any redo data—because, in noarchivelog mode, there is none to apply. Recovery of a Noncritical File in Archivelog Mode In an Oracle database, the datafiles that make up the SYSTEM tablespace and the currently active undo tablespace (as specified by the UNDO_TABLESPACE parameter) are considered to be “critical.” Damage to any of these will result in the instance terminating immediately. Furthermore, the database cannot be opened again until the damage has been repaired by a restore and recover exercise. Damage to the other datafiles, which make up tablespaces for user data, will not as a rule result in the instance crashing. Oracle will take the damaged files offline, making their contents inaccessible, but the rest of the database should remain open. How your application software will react to this will depend on how it is structured and written. TIP Is it safe to run your application with part of the database unavailable? This is a matter for discussion with your developers and business analysts, and an important point to consider when deciding on how to spread your segments across tablespaces. If your backups were done with RMAN, the restore and recovery operation of a damaged datafile will be completely automatic. RMAN will carry out the restore in the most efficient manner possible, making intelligent use of full and incremental backups and then applying the necessary archive logs. If RMAN is linked to a tape library through SBT channels, it will load the tapes automatically to extract the files it needs. The restore and complete recovery of a datafile can succeed only if all the archive log files generated since the last backup of the datafile are available. Either they must still be on disk in the archive log destination directories, or if they have been migrated to tape, they must be restored during the recovery operation. RMAN will do the extract from a backup set and restore to disk automatically. If for some reason an archive log file is missing or corrupted, the recovery will fail, but since archive log destinations and RMAN backup sets can and should be multiplexed, you should never find yourself in this situation. If you do, the only option is a complete restore, and an incomplete recovery up to the missing archive, which will mean loss of all work done subsequently. Exercise 16-3: Recover from Loss of a Noncritical Datafile with Database Control First, create a tablespace and a segment within it, and back it up. Then simulate damage to the datafile. Diagnose the problem and resolve it. The database will stay open for use throughout the whole exercise. At various points you will be asked to supply host operating system credentials, if you have not saved them in previous exercises: give a suitable Windows or Unix login, such as the Oracle owner. Chapter 16: Restore and Recover with RMAN 617 PART III 1. Connect to your database as user SYSTEM using SQL*Plus, and create a tablespace. For example, on Windows, SQL> create tablespace noncrit datafile 'C:\APP\ORACLE\ORADATA\ORCL\noncrit.dbf' size 2m; or on Unix, SQL> create tablespace noncrit datafile '/app/oracle/oradata/orcl/noncrit.dbf' size 2m; 2. Create a table within the new tablespace and insert a row into it: SQL> create table ex16 (c1 date) tablespace noncrit; SQL> insert into ex16 values(sysdate); SQL> commit; 3. Using Database Control, connect to your database as user SYSTEM. 4. From the database home page, take the Availability tab, then the Schedule Backup link in the Manage section. 5. In the Schedule Backup window, select the Tablespaces radio button in the Customized Backup section. Click SCHEDULE CUSTOMIZED BACKUP. 6. In the Schedule Backup: Tablespaces window, click ADD. 7. In the Tablespaces: Available Tablespaces window, select the radio button for your new NONCRIT tablespace, and click SELECT. 8. In the Schedule Customized Backup: Tablespaces window, click NEXT. 9. In the Schedule Customized Backup: Options window, leave everything on defaults and click NEXT. 10. In the Schedule Customized Backup: Settings window, leave everything on defaults and click NEXT. 11. In the Schedule Customized Backup: Schedule window, select One Time (Immediately) radio button and click NEXT. 12. In the Schedule Customized Backup: Review window, study the script and click SUBMIT JOB to run the backup. 13. Simulate a disk failure by corrupting the new datafile. On Windows, open the file with Windows Notepad, delete a few lines from the beginning of the file, and save it; it is important to use Notepad because it is one of the few Windows utilities that will ignore the file lock that Oracle places on datafiles. On Unix you can use any editor you please, such as vi. Make sure that the characters deleted are at the start of the file, to ensure that the file header is damaged. 14. Flush the buffer cache, so that the next read of ex16 will need to read from disk: alter system flush buffer_cache; OCA/OCP Oracle Database 11g All-in-One Exam Guide 618 15. Confirm that the file is damaged by attempting to query the table: SQL> select * from ex16; select * from ex16 * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 7, block # 9) ORA-01110: data file 7: 'C:\APP\ORACLE\ORADATA\ORCL\NONCRIT.DBF' 16. In your Database Control session, take the Availability tab from the database home page, and then the Perform Recovery link in the Manage section. 17. In the Perform Recovery: Type window, take the link for Datafiles With Error. 18. In the Perform Object Level Recovery: Datafiles window, the new datafile will be listed. Select it, and click NEXT. 19. In the Perform Object Level Recovery: Rename window, click NEXT. 20. In the Perform Object Level Recovery: Review window, click SUBMIT. 21. In the Perform Recovery: Result window, study the output of the operation, as shown in the illustration. 22. Confirm that the tablespace and the tables within it are now usable, with no loss of data. SQL> select * from ex16; C1 21-OCT-08 Of the four steps for complete recovery, the first step (taking the damaged file offline) will be automatic if the file is noncritical. The following two steps (restore Chapter 16: Restore and Recover with RMAN 619 PART III and recovery) are accomplished with RMAN commands, and the final step (bringing the datafile online) can be done with either SQL*Plus or RMAN. The scripts generated by Database Control automate the entire procedure. If an incremental backup strategy has been used, a restore and recover operation will make use of a level 0 incremental backup, then apply any incremental level 1 backups that may be available, and then apply redo data to complete the recovery. The logic behind this method (which keeps use of redo to a minimum) is that it is always faster to apply an incremental backup than to apply redo, because an incremental backup can be applied in a single sequential pass through the datafile, whereas applying redo (which consists of change vectors in chronological order) will involve random access to the datafile. The presence or absence of incremental backups does not lead to any syntactical difference in the use of the RECOVER command; RMAN, by interrogating its repository, will work out the best way to perform the operation. EXAM TIP RMAN will always apply incremental backups in preference to applying redo data, if they are available. Recovering from Loss of a Critical Datafile The datafiles that make up the SYSTEM and currently active undo tablespace are considered critical by Oracle, meaning that it is not possible to keep the database open if they are damaged. If any portion of the SYSTEM tablespace were not available, parts of the data dictionary would be missing. Oracle cannot function without a complete data dictionary. If parts of the undo tablespace were not available, it would be possible that undo data required for maintaining transactional integrity and isolation would not be available, and Oracle can’t take that chance either. Therefore, damage to these datafiles will cause the instance to terminate immediately. TIP The critical datafiles should be on disk systems with hardware redundancy, such as RAID level 1 disk mirroring, so that in the case of media failure the files will survive and the database will remain open. If the database does crash because of damage to critical datafiles, as ever, the first action is to attempt a startup. This will stop in mount mode, with error messages written to the alert log showing the extent of the damage. To recover, follow the same routine as that for a noncritical file, and then open the database. The restore and recover process is identical to that for a noncritical file, but it must be carried out in mount mode. Of the four steps for complete recovery, if the damaged file is a critical file only the second and third steps are necessary: as the database cannot be opened, there is no need to take the damaged file offline and bring it back online afterward. EXAM TIP Loss of a critical data file will not mean loss of data, but it will mean loss of time. OCA/OCP Oracle Database 11g All-in-One Exam Guide 620 Incomplete Recovery An incomplete recovery means losing data. The whole database is taken back in time by a restore of all the datafiles, and then it is not completely recovered. Rather than applying all the redo generated since the backup was taken, you deliberately stop the application of redo at some point, to produce a version of the database that is not up-to-date. All work done from that point is lost. There are only two reasons for performing an incomplete recovery: either complete recovery is impossible or you deliberately decide to lose data. Complete recovery will not be possible unless all archive logs generated from the time of the backup are available, as well as the online redo logs. If an archive log is missing or corrupted, then recovery will stop at that point. Complete recovery should never fail because of missing archive or online log files, as both file types can and should be multiplexed to different devices, making their total loss impossible, but it can happen. If so, incomplete recovery up to the point at which the missing or damaged redo data occurs is your only option. EXAM TIP Incomplete recovery is necessary if there is a missing archive log, or if all copies of the current online redo log file group are missing. To decide to lose data deliberately is a course of action taken after user error. It may be that a user has committed a transaction that is inappropriate to the business requirements. Such errors could include perfectly normal mistakes—we all make mistakes—while using package software, but more commonly they are errors made using tools such as SQL*Plus. Omitting a WHERE clause when issuing an UPDATE or DELETE statement will result in the whole table being affected, not just one row; if this change is committed, perhaps by exiting from the tool, then the changes are irreversible. As far as Oracle is concerned, it is a committed transaction and can never be rolled back. Worse still is issuing DDL commands. These include an implicit COMMIT statement. It is frighteningly easy, for example, to drop a table or even a schema when you think you are connected to the development database when in fact you are connected to production. Following a user error, you can restore the whole database and recover it up to the point just before the error, thus producing a version of the database without the mistake, but also, without all the correct work done since. TIP There are several “flashback” technologies that may make it possible to recover from user errors without resorting to an incomplete recovery. EXAM TIP It is not possible to skip the recovery of a bad transaction and recover all other work. Chapter 16: Restore and Recover with RMAN 621 PART III A special case of incomplete recovery is recovery of the controlfile. Ideally, all recovery operations will be conducted using the current controlfile, but there are circumstances when this isn’t possible and a backup of the controlfile must be restored. There are two possible reasons for this: either all copies of the current controlfile have been lost and it is not possible to run a CREATE CONTROLFILE command to recreate it, or the current controlfile does not accurately describe the version of the database you want to restore, typically, because changes such as dropping tablespaces have occurred since taking the backup. There are four steps for incomplete recovery: • Mount the database. • Restore all the datafiles. • Recover the database until a certain point. • Open the database with reset logs. The first contrast with complete recovery is that complete recovery can be done with the database open, unless the damaged files are critical. Incomplete recovery can be done only in mount mode. Second, for a complete recovery, you restore only the damaged datafiles; incomplete recovery operations begin with a restore of all datafiles. The datafiles do not have to be restored from the same backup, but they must all be older than the point to which you wish to recover. The controlfile will have to be restored as well as the datafiles if the physical structure of the current database is different from the structure of the version being restored. For example, if a tablespace has been accidentally dropped, the current controlfile will know nothing about it. Restoring the datafiles that make up the tablespace won’t help: the current controlfile will ignore them, and not include them in the recovery. Do not restore the controlfile unless you have to; it may complicate matters if you do. The third step is to apply redo from archive and (if necessary) online logs to the desired point. This contrasts with complete recovery, where you apply all the redo to bring the database right up-to-date; for incomplete recovery, you stop the recovery at whatever point you want prior to the latest time. There are several options for specifying the point to which you want to recover. Finally, open the database with RESETLOGS. This will reinitialize the online redo log files, creating a new incarnation of the database. An incarnation of a database is a version of the database with a new thread of redo, beginning at log sequence number 1. This is the final contrast with complete recovery. After a complete recovery, the database is exactly as it was before the problem occurred, but after an incomplete recovery it is a different incarnation. Backups and archive logs are specific to an incarnation and those generated by one incarnation must be kept separate from those generated by a previous incarnation. EXAM TIP You must be connected AS SYSDBA to do an incomplete recovery. No normal user, and not even a SYSOPER user, can do this. OCA/OCP Oracle Database 11g All-in-One Exam Guide 622 Having mounted the database and restored all the datafiles and (if necessary) the controlfile, you have three options for incomplete recovery: • Until time • Until system change number (SCN) • Until log sequence number The UNTIL TIME option will apply redo to roll the datafiles forward until a particular time. The precision is to the second. This option would usually be used to correct user error. If a user made an irreversible mistake and the time the mistake was made is known, then a time-based recovery to just before the mistake may be the best option. The UNTIL SCN option can be used if the exact system change number when the error was made is known. By using advanced tools such as the Log Miner utility or by using the Flashback capability to be detailed in Chapter 19, it may be possible to identify exactly the SCN at which a transaction was committed. The recovery can be stopped precisely before the problem, thus losing the minimum possible amount of data. The UNTIL SEQUENCE option is used if an archive log file or an online log file group is missing; it will recover all work up to the log switch into the missing file or group. EXAM TIP The syntax for incomplete recovery differs between SQL*Plus and RMAN. SQL*Plus uses UNTIL CANCEL and UNTIL CHANGE, where RMAN would use UNTIL SEQUENCE and UNTIL SCN. They both use UNTIL TIME. By default, RMAN will restore the most recent backup, and apply all available redo. Incomplete recovery must modify this behavior: the restore must be from backups that are older than the point in time to which the recovery is to be made, and the recovery must be stopped at that time. To ensure that the restore and recover both use the same UNTIL TIME, it is considered best practice to execute both commands within a single run block. For example, 1 run {startup mount; 2 set until time = "to_date('27-10-08 10:00:00','dd-mm-yy hh24:mi:ss')"; 3 restore database; 4 recover database; 5 alter database open resetlogs;} This example, with line numbers added for clarity, shows the four steps for incomplete recovery: • Line 1 The database must be started in mount mode. It is of no significance whether the preceding shutdown were orderly or an abort. • Line 2 The SET UNTIL command specifies a time that will be applied to all subsequent commands. The example includes a format string that will eliminate any ambiguity in interpreting the date and time. An alternative is Chapter 16: Restore and Recover with RMAN 623 PART III to rely on matching the NLS_DATE_FORMAT environment variable. Note the use of double quotes around the entire string, and single quotes within it. • Line 3 The RESTORE command will extract datafiles from backups that are at least as old as the time specified in the SET UNTIL command. • Line 4 The RECOVER command will apply redo from archive log files and (if necessary) online log files, stopping at the specified time. • Line 5 The RESETLOGS clause instructs Oracle to initialize the online redo log files and reset the log switch sequence number. An alternative syntax is to specify the UNTIL value with each command. For example, restore database until time 'sysdate - 7'; recover database until time '27-OCT-08'; The first of these commands instructs RMAN to restore the database from backups that are at least seven days old. The second command will perform an incomplete recovery up to the beginning of October 27, 2008, assuming that the NLS_DATE_ FORMAT environment variable is set to dd-MON-rr. Autobackup and Restore of the Controlfile For a complete recovery, it should always be possible to use the current controlfile. The only case where this will not be possible is if all copies have been lost—typically, because it was not multiplexed and the one copy was damaged. The database is critically dependent on the controlfile: it will crash if the controlfile is damaged. RMAN makes the situation even worse: the RMAN repository, which stores details of all backups, is stored in the controlfile. So if the controlfile is damaged, the database will crash—but RMAN will not be able to restore it, because the information it needs will not be available. There are two ways around this recursive problem: either use an RMAN catalog database (as described in Chapter 17) or enable the AUTOBACKUP facility. Because the controlfile is vital not only to the running database but also to RMAN, an automatic backup can be enabled. From the RMAN prompt, configure controlfile autobackup on; Having executed this command, every RMAN operation will conclude with an automatic backup of the controlfile and the spfile into a backup set stored in a well- known location. Then if necessary, with the database in nomount mode, you can use this: restore controlfile from autobackup; This command instructs RMAN to go to the well-known filename in a well-known location and extract the controlfile from the most recent autobackup. The restore will be to the locations given in the spfile. Then mount the database using the restored OCA/OCP Oracle Database 11g All-in-One Exam Guide 624 controlfile, and RMAN will be able to locate the backups needed to restore the rest of the database. The well-known location will be in the flash recovery area if this has been enabled. The well-known filename is based on the DBID; the DBID (a ten-digit number) should be part of your most basic documentation, and will have been displayed whenever you connect to the database with RMAN. It is also visible as the column DBID in the V$DATABASE view. If the spfile has also been lost, start the instance with a dummy initialization file: a pfile with just one parameter, DB_NAME. Then connect with RMAN, and issue these commands, substituting your DBID number for that given: set dbid 1234567890; restore spfile from autobackup; The restore of an spfile will be to the default location, in $ORACLE_HOME/dbs for Unix or %ORACLE_HOME%\database for Windows. Then restart the instance in nomount mode, which will use the restored spfile, and restore the controlfile. Mount the controlfile, and RMAN will then have access to its repository and can locate and restore the datafile backups. EXAM TIP The commands restore controlfile from autobackup and restore spfile from autobackup can be executed in nomount mode. All other RMAN commands can be executed only in mount or open mode. Exercise 16-4: Enable Controlfile Autobackup In this exercise, enable the controlfile autobackup facility and observe it in operation. 1. Connect to the database with RMAN: rman target / 2. Confirm that autobackup is not enabled: show controlfile autobackup; This will show that autobackup is not enabled. 3. Enable autobackup, and confirm: configure autobackup on; show all; Note that the default format for autobackups is ‘%F’. 4. Carry out a backup operation: backup datafile 1; Observe that following the requested backup, there is a second backup set created for the controlfile and the spfile. 5. Determine the location of autobackup of the controlfile and the spfile: list backup of controlfile; list backup of spfile; Chapter 16: Restore and Recover with RMAN 625 PART III In both cases, the most recent backup set listed will be to a file in the flash recovery area. This can be overridden by configuring a format other than the ‘%F’ shown in Step 3, but if this is done, the automatic location of the autobackups will no longer function. This script accomplishes the complete restore and recovery of a database, assuming that everything was lost: 1 run{startup nomount pfile=dummy.pfile; 2 set dbid=1196323546; 3 restore spfile from autobackup; 4 shutdown abort; 5 startup nomount; 6 restore controlfile from autobackup; 7 alter database mount; 8 restore database; 9 recover database; 10 alter database open resetlogs;} Taking this script line by line, 1 Start the instance, using a dummy parameter file with just one parameter: DB_NAME. 2 Tell RMAN the DBID of the database on which you are working. 3 Extract the spfile from the most recent autobackup, relying on defaults for its name and location. 4 Abort the instance, because (having been started with a dummy pfile) it is not of any further use. 5 Start the instance, using the restored spfiles. 6 Extract the controlfile from the most recent autobackup. 7 Mount the controlfile. 8 Restore all the datafiles. 9 Carry out a complete recovery by applying any incremental backups, followed by archive log files and online log files. 10 Open the database, and reinitialize the online redo log files. A RESETLOGS is always required after restoring the controlfile. Exercise 16-5: Perform Incomplete Recovery with RMAN, Using a Backup Controlfile In this exercise, which continues from Exercise 16-3, you will drop a tablespace and then perform an incomplete recovery to a time just before it was dropped. This is possibly the most complex operation that may ever be necessary. It must be performed in several stages: first a version of the controlfile that dates from the time the tablespace existed must be restored, and the database must be mounted with this controlfile. Only then can the rest of the database be restored and recovered. Before launching RMAN or SQL*Plus, ensure that your operating system date format is set to a known value. For example, on Windows: set NLS_DATE_FORMAT=dd-mm-yy hh24:mi:ss . of data, but it will mean loss of time. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 620 Incomplete Recovery An incomplete recovery means losing data. The whole database is taken back in. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 616 This command will locate all cumulative and differential incremental level 1 backups and apply them. The NOREDO qualifier is. restored OCA/ OCP Oracle Database 11g All-in-One Exam Guide 624 controlfile, and RMAN will be able to locate the backups needed to restore the rest of the database. The well-known location will