OCA/OCP Oracle Database 11g All-in-One Exam Guide 686 Exercise 18-3: Recover a Lost Multiplexed Online Log File This exercise will simulate loss of a log file member and then, while the database is open, diagnose the problem and clear it. 1. Using SQL*Plus, connect to your database as user SYS with SYSDBA privilege: SQL> connect / as sysdba; 2. Observe the state of your online logs with the following query: SQL> select group#,status,member from v$logfile order by 1,3; GROUP# STATUS MEMBER 1 /u01/app/oracle/oradata/orcl/redo01a.log 1 /u01/app/oracle/oradata/orcl/redo01b.log 2 /u01/app/oracle/oradata/orcl/redo02a.log 2 /u01/app/oracle/oradata/orcl/redo02b.log 3 /u01/app/oracle/oradata/orcl/redo03a.log 3 /u01/app/oracle/oradata/orcl/redo03b.log 6 rows selected. Confirm that you do have at least two members of each group and that all the members have the STATUS column on NULL, as in the example here. If any groups do not have two members, multiplex them immediately by following the steps provided in Chapter 14, Exercise 14-1. If any members do not have a STATUS of NULL, execute the command SQL> alter system switch logfile; a few times to cycle through the groups, and then rerun the query. 3. Shut down the database: SQL> shutdown immediate; Figure 18-3 Clearing a log file group with SQL*Plus Chapter 18: User-Managed Backup, Restore, and Recovery 687 PART III 4. Using an operating system command, simulate media failure by deleting one of the members. For example, on Windows, SQL> host del C:\ORACLE\PRODUCT\11.1.0\ORADATA\ORCL\REDO01A.LOG or on Unix, SQL> host rm /u01/app/oracle/oradata/orcl/redo01a.log 5. Start up the database and simulate user activity by performing a few log switches: SQL> startup; SQL> alter system switch logfile; SQL> alter system switch logfile; SQL> alter system switch logfile; 6. Check the state of your log file members: SQL> select group#,status,member from v$logfile order by 1,3; GROUP# STATUS MEMBER 1 INVALID /u01/app/oracle/oradata/orcl/redo01a.log 1 /u01/app/oracle/oradata/orcl/redo01b.log 2 /u01/app/oracle/oradata/orcl/redo02a.log 2 /u01/app/oracle/oradata/orcl/redo02b.log 3 /u01/app/oracle/oradata/orcl/redo03a.log 3 /u01/app/oracle/oradata/orcl/redo03b.log Note that the missing file is now marked as being INVALID, but that the database opened without (apparently) any problem. 7. Connect to your database as user SYSTEM, using Database Control. 8. From the database home page, take the Server tab, and then the Redo Log Groups link in the Storage section to bring up the window shown in the illustration. OCA/OCP Oracle Database 11g All-in-One Exam Guide 688 9. If the group with the problem (group number 1 in the example shown) is not INACTIVE, use the Switch Logfile choice in the Actions drop-down list and click Go to force log switches until it is inactive. 10. Clear the log file group by selecting its radio button using the Clear Logfile choice in the Actions drop-down list, and clicking Go. 11. In your SQL*Plus session, confirm that the problem has been fixed by running the query from Step 6. EXAM TIP Damage to a multiplexed online log file results in neither downtime nor data loss; damage to a nonmultiplexed log file group (or every member of a multiplexed group) may result in both. Recovery from Loss of a Tempfile If a tempfile is damaged, the database will remain open. It can also be opened, if the damage occurred while the database was closed. Users will only become aware of the problem when they attempt to use the tempfile: when their server process finds it necessary to write some temporary data, because of insufficient space in the session’s PGA. As a DBA, you should, however, be aware of any such damage: it will be reported in the alert log. To fix a problem with a tempfile, add another tempfile to the temporary tablespace and drop the original: alter tablespace temp add tempfile '/u01/app/oracle/oradata/orcl/temp02.dbf' size 50m; alter tablespace temp drop tempfile '/u01/app/oracle/oradata/orcl/temp01.dbf'; Recovery from Loss of Datafiles Media failure resulting in damage to one or more datafiles requires use of restore and recover routines: a backup of the datafile must be restored, and then archive redo logs applied to it to synchronize it with the rest of the database. There are various options available, depending on whether the database is in archivelog mode or not, and whether the file damaged is one that is critical to Oracle’s functioning or a noncritical file containing “only” user data. In all cases you must determine the extent of the damage. This is done by querying the view V$RECOVER_FILE, which will list all datafiles found to be damaged or missing. This view is available when the database is in mount mode (necessary if a critical file has been damaged) or open mode (if the damage is limited to noncritical files). Recovery of Datafiles in Noarchivelog Mode There is no concept of recovery when in noarchivelog mode, because the archive log files needed for recovery do not exist. Therefore, only a restore can be done. But if a Chapter 18: User-Managed Backup, Restore, and Recovery 689 PART III restored datafile is not synchronized with the rest of the database by application of archive redo log files, it cannot be opened. The only option when in noarchivelog mode is therefore to restore the whole database: all the datafiles, and the controlfile. Provided that all these files are restored from a whole offline backup, after the restore you will have a database where all these files are synchronized, and thus a database that can be opened. But you will have lost all the work done since the backup was taken. Once the full restore has been done, the database will still be missing its online redo log files, unless they were backed up and restored as well. For this reason, the post-restore startup will fail, with the database being left in mount mode. While in mount mode, issue ALTER DATABASE CLEAR LOGFILE GROUP <group number> commands to recreate all the log file groups. Then open the database. In noarchivelog mode, loss of any one of possibly hundreds of datafiles can be corrected only by a complete restore of the last backup. The whole database must be taken back in time, with the loss of users’ work. Furthermore, that last backup must have been a whole, offline backup, which will have entailed downtime. It should by now be apparent that the decision to operate your database in noarchivelog mode should not be taken lightly. EXAM TIP If in noarchivelog mode, your only option following loss of a datafile is a whole database restore. There can be no recovery. Recovery of a Noncritical Datafile 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. 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. If for some reason an archive log file is missing or corrupted, the recovery will fail and 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. OCA/OCP Oracle Database 11g All-in-One Exam Guide 690 There are four steps for open recovery of a noncritical datafile: 1. Take the damaged file offline. 2. Restore the file. 3. Recover the file. 4. Bring the file online. Exercise 18-4: Recover from Loss of a Noncritical Datafile In this exercise you will restore and recover the datafile created in Exercise 18-1. 1. 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. 2. Confirm that the file is damaged by attempting to query the table created in the tablespace: SQL> select * from t1; select * from * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 7, block # 9) ORA-01110: data file 7: '/u01/app/oracle/oradata/orcl/ex181.dbf' 3. From a SQL*Plus prompt, take the file offline: alter database datafile '/u01/app/oracle/oradata/orcl/ex181.dbf' offline; 4. From an operating system prompt, restore the backup made in Exercise 18-1. For example, on Unix, cp /tmp/ex181.dbf.bak /u01/app/oracle/oradata/orcl/ex181.dbf 5. Issue the recover command: recover datafile '/u01/app/oracle/oradata/orcl/ex181.dbf'; When prompted, hit the ENTER key to apply the archived redo logs from their default locations. The number to apply will depend on how you completed the previous exercises, but eventually you will see the message “Media recovery complete.” 6. Bring the file online: alter database datafile '/u01/app/oracle/oradata/orcl/ex181.dbf' online; 7. Confirm that the table is now accessible by running the query from Step 2. Recovering a Critical Datafile in Archivelog Mode The datafiles that make up the SYSTEM and the currently active undo tablespace are considered critical by Oracle, meaning that it is not possible to keep the database Chapter 18: User-Managed Backup, Restore, and Recovery 691 PART III open if they are damaged. The recovery technique is the same as that for a noncritical datafile, with the exception that the recovery must be done in mount mode because the database will have crashed and it will not be possible to open it. It is not necessary to offline the damaged file. The steps are therefore: 1. Mount the database. 2. Restore the file. 3. Recover the file. 4. Open the database. Another scenario where complete recovery can be done only in mount mode is if the entire database needs to be recovered. This would be the case if the damage were so extensive that a large proportion of the datafiles had to be restored. The syntax for this, in mount mode, is recover database; This command will roll all the restored datafiles forward in parallel, prompting for archive log files as necessary. User-Managed Incomplete Recovery There are four steps to incomplete recovery: 1. Mount the database. 2. Restore all the datafiles (and the controlfile if necessary). 3. Recover the database until a certain point. 4. Open the database with resetlogs. At Step 2, only restore the controlfile if the current physical structure of the database does not correspond to the physical structure at the time from which the restore is made. If the physical structure is still the same (that is, no tablespaces have created or dropped), then do not restore the controlfile; using the current controlfile, which is aware of all recent log switches and archives, will make recovery simpler. Do not under any circumstances restore the online redo log files: data from the current online log files will be needed if the recovery is to be up to a very recent time. At Step 3, you have three options: stop the recovery at a certain time, at a certain SCN (system change number), or at a certain log switch sequence number. The time option is most commonly used. The SCN option would usually only be used for instantiating a copy of a database to an exact point for some reason, such as establishing a streamed (replicated) database. The last option would usually be used only if an archive log file is missing or damaged, making it impossible to recover further. Examples of the commands are recover database until time '2008-12-21:13:50:00' ; recover database until change 93228650 ; recover database until cancel; OCA/OCP Oracle Database 11g All-in-One Exam Guide 692 Points to note are, first, that there is no permitted variation in the date format. It must be yyyy-mm-dd:hh24:mi:ss no matter what your SQL*Plus session has its NLS_ DATE_FORMAT set to. Second, the syntax for recovery up to a certain archive log file does not allow you to specify which log file: you must stop the recovery interactively, when prompted for the log file that you do not wish to (or cannot) apply. Third, in all cases the recovery will be to the change vector immediately before that requested stopping point: the nominated SCN will not be applied. Finally, if the recovery includes applying changes for transactions that had not been committed at the point at which recovery ceases, these changes will be rolled back. EXAM TIP A RECOVER DATABASE UNTIL . . . will stop immediately before applying the change vector of the nominated time or SCN, not immediately after. If RMAN has been configured, then a user-managed incomplete recovery must be terminated with a fifth step: updating the RMAN repository with details of the RESETLOGS operation. The problem is that without this, RMAN will observe that the log switch sequence number recorded in the controlfile has dropped to 1, and will not know if this is because you deliberately reset it (in which case RMAN should do nothing) or because you have restored an old controlfile (in which case RMAN should recover it). From an RMAN prompt, the command to do this is RESET DATABASE. Exercise 18-5: Perform an Incomplete Recovery In this exercise, back up your database; drop the tablespace created in Exercise 18-1; and perform an incomplete recovery to a point just before this—thus restoring the tablespace. Then the final step: inform RMAN of what you have done. 1. Connect to your database with SQL*Plus, and put the whole database into backup mode: SQL> alter database begin backup; 2. Identify all the datafiles: select name from v$datafile; 3. Copy the datafiles to some safe destination, using whatever operating system utility you wish. 4. Take the database out of backup mode: alter database end backup; 5. Simulate some user activity by executing this command a few times to force some log switches and archives: alter system switch logfile; 6. Determine the exact time: select to_char(sysdate,'yyyy-mm-dd:hh24:mi:ss') from dual; 7. Drop the tablespace: drop tablespace ex181 including contents and datafiles; Chapter 18: User-Managed Backup, Restore, and Recovery 693 PART III Confirm that the tablespace is gone by attempting to query the table t1. 8. Terminate the instance: shutdown abort 9. Using an operating system utility, restore all the datafiles from the backup made in Step 3. Note that under Windows, you may need to stop and start the Windows service in order to release file locks. 10. Start up the database in mount mode: startup mount 11. Recover the database until the time identified in Step 6. Remember that there are no options regarding the format. For example, recover database until time '2008-12-21:18:20:45'; You will receive several prompts for archive log files (the number will depend on Step 5). You can press ENTER each time, or enter AUTO to allow Oracle to attempt to locate the archive logs automatically. This will succeed, unless you have deliberately moved them. 12. Open the database, with the RESETLOGS option: alter database open resetlogs; 13. Confirm that the tablespace has been restored, by querying the table t1. 14. Launch RMAN, and connect to both the target and the catalog. From an operating system prompt: rman target / catalog rman/rman@catdb 15. Update the repository: RMAN> reset database; Two-Minute Drill Recover from a Lost TEMP File • A temporary tablespace cannot be placed in backup mode. • Tempfiles would not usually be restored—it is quicker to drop and recreate them. Recover from a Lost Redo Log Group • Damaged log file members, or entire groups, can be dropped and recreated, or cleared (which comes down to the same thing). • Online redo log files must not be backed up for an open backup, and they need not be backed up for a closed backup—if the database is shut down cleanly. OCA/OCP Oracle Database 11g All-in-One Exam Guide 694 Recover from the Loss of a Password File • As a rule, the password file need not be backed up. Keep a copy of the command used to create it, and recreate if necessary. Perform User-Managed Complete Database Recovery • The SQL*Plus command is RECOVER DATAFILE (in open mode, unless the datafile is critical) or RECOVER DATABASE (in mount mode only). • The steps for complete recovery of a noncritical datafile are Take the file offline. Restore the file. Recover the file. Bring the file online. • The steps for complete recovery of a critical datafile are Mount the database. Restore the file. Recover the file. Open the database. Perform User-Managed Incomplete Database Recovery • The options are Until a specified time Until an SCN Until the cancel command is submitted at the recovery prompt • The steps are Mount the database. Restore all datafiles (and the controlfile if necessary). Recover the database UNTIL . . . . Open the database with RESETLOGS. • If using RMAN, the repository must be updated with RESET DATABASE. Perform User-Managed Backups • In noarchivelog mode, a complete backup while the database is shut down is the only option. • In archive log mode, there are three steps to an open backup: ALTER DATABASE BACKUP CONTROLFILE. Archive the online redo logs. Copy the datafiles, while their tablespace is in backup mode. Chapter 18: User-Managed Backup, Restore, and Recovery 695 PART III Identify the Need for Backup Mode • In backup mode, datafiles can be safely copied. • When backup mode is enabled: The datafile header is frozen. The tablespace is checkpointed. The redo generation algorithm switches from change vectors to complete blocks. • An open backup may contain fractured blocks, but these can be replaced with read-consistent blocks from the redo stream. Back Up and Recover a Controlfile • Unless the database is closed, the controlfile can only be backed up with the ALTER DATABASE BACKUP CONTROLFILE command. • The easiest way to recover from the loss of a controlfile copy is to use another copy. • A binary backup of the controlfile can be restored. • A controlfile can be recreated with the CREATE CONTROLFILE command, if all the relevant information regarding datafiles and online redo log files is available. Self Test 1. How could you diagnose problems with a multiplexed online log file group member? (Choose the best answer.) A. Query the V$LOG view. B. Query the V$LOGFILE view. C. Query the V$LOGFILE_MEMBER view. D. You do not need to diagnose it; the instance will crash when the problem occurs. 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 ocp11g (thread 1).” What could be an explanation for this? (Choose the best answer.) A. Log file group 2 has not been archived. B. Log file group 2 is being used for recovery. C. Log file group 2 is active. D. The group is not multiplexed. . /u01/app /oracle/ oradata/orcl/redo0 1a. log 1 /u01/app /oracle/ oradata/orcl/redo01b.log 2 /u01/app /oracle/ oradata/orcl/redo0 2a. log 2 /u01/app /oracle/ oradata/orcl/redo02b.log 3 /u01/app /oracle/ oradata/orcl/redo0 3a. log . # 9) ORA-01110: data file 7: '/u01/app /oracle/ oradata/orcl/ex181.dbf' 3. From a SQL*Plus prompt, take the file offline: alter database datafile '/u01/app /oracle/ oradata/orcl/ex181.dbf'. until change 93228650 ; recover database until cancel; OCA/ OCP Oracle Database 11g All-in-One Exam Guide 692 Points to note are, first, that there is no permitted variation in the date format. It