CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY 474 Now, let’s look at the table. SQL> SELECT TO_CHAR(the_time, ‘mm/dd/yyyy hh24:mi:ss’) FROM time_table; TO_CHAR(THE_TIME,’M 04/29/2001 00:24:52 04/29/2001 00:24:54 04/29/2001 00:27:26 04/29/2001 00:27:26 Shut down the database. SQL> SHUTDOWN IMMEDIATE Database closed. Database dismounted. ORACLE instance shut down. Recover the last backup. SQL> HOST COPY d:\oracle_backup\hot\*.* d:\oracle\oradata\recover d:\oracle_backup\hot\RECOVER_RBS_01.DBF d:\oracle_backup\hot\RECOVER_USERS_01.DBF d:\oracle_backup\hot\RECOVER_DATA_01.DBF d:\oracle_backup\hot\RECOVER_INDEX_TBS_01.DBF d:\oracle_backup\hot\RECOVER_TEMP_01.DBF d:\oracle_backup\hot\RECOVER_TEST_TBS_01.DBF d:\oracle_backup\hot\SYSTEM01.DBF Mount the database. SQL> STARTUP MOUNT ORACLE instance started. Total System Global Area 92280076 bytes Fixed Size 70924 bytes Variable Size 87937024 bytes Database Buffers 4194304 bytes Redo Buffers 77824 bytes Database mounted. We begin the change-based recovery. Notice we use automatic application of archived redo logs in response to the recovery prompt. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 475 Change 35936 is the first change in the online redo log after we forced the log switch, thus we will recover up to but not including that point. SQL> RECOVER DATABASE UNTIL CHANGE 35936; We open the database. Note the use of RESETLOGS. SQL> ALTER DATABASE OPEN RESETLOGS; We query the table, and see only two records! SQL> SELECT TO_CHAR(the_time, ‘mm/dd/yyyy hh24:mi:ss’) FROM time_table; TO_CHAR(THE_TIME,’M 04/29/2001 00:24:52 04/29/2001 00:24:54 Cancel-Based Recovery Cancel-based recovery allows you to manually apply archived redo logs to the data- base during a recovery, but be able to stop the recovery after the application of each archived redo log and open the database. This is handy in cases where you have lost a control file or the online redo log, and you need to recover the database as much as possible. To use cancel-based recovery, use the command RECOVER DATABASE UNTIL CANCEL. Then, as you are prompted for archived redo logs to apply, enter CANCEL to stop the recovery process. We will demonstrate the use of cancel-based recovery in the next section. Recovery from Loss of Online Redo Logs A special case is recovery from the loss of the online redo log. This is a particular prob- lem if the online redo log that is lost is the current online redo log and no other members exist. In this case, if your database crashes along with the loss of the redo log, you will likely lose some data. NOTE As noted earlier, the online redo log is the Achilles heel of Oracle. This is why you must protect it by creating at a minimum two different members of each redo log group (and I prefer three). Each of these should be on a separate disk and use a separate con- troller, if possible. RECOVERIES IN ARCHIVELOG MODE Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY 476 Should you lose the online log file and the database doesn’t crash, you may find that it hangs. In this case, you can try to issue the ALTER DATABASE CLEAR LOGFILE command, and this may solve the problem. Suppose that you accidentally deleted the online redo log during maintenance, after shutting down the database with the SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE command. In this case, you can perform an easy bit of magic to solve the problem, as shown in Listing 10.9. Listing 10.9: Recovering from the Loss of the Online Redo Logs after a Normal Database Shutdown In this first case, we shut down our database to do some maintenance. Unfortunately, we didn’t test our script and we accidentally deleted our online redo logs. We shut down the database normally with a SHUTDOWN IMMEDIATE command, so recovery in this case is a snap. All we need to do is issue a recover database until cancel command, and then open the database with RESETLOGS. (RESETLOGS will re-create the redo logs!) SQL> STARTUP ORACLE instance started. Total System Global Area 92280076 bytes Fixed Size 70924 bytes Variable Size 87937024 bytes Database Buffers 4194304 bytes Redo Buffers 77824 bytes Database mounted. ORA-00313: open failed for members of log group 1 of thread 1 ORA-00312: online log 1 thread 1: ‘D:\ORACLE\ORADATA\RECOVER\REDO01.LOG’ SQL> RECOVER DATABASE UNTIL CANCEL; Media recovery complete. SQL> ALTER DATABASE OPEN RESETLOGS; Database altered. If you issued SHUTDOWN ABORT, or some other problem caused a database crash (such as a power failure), then you have a bigger problem. Assuming that you have lost one or more of the online redo logs required to get the database up and going again, you will need to restore all database datafiles from the last good backup and recover the database. In this kind of recovery situation, complete database recovery will not be possible. After you have completed the recovery, you will need to issue the ALTER DATABASE OPEN RESETLOGS command. The use of the RESETLOGS command will C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 477 cause new online redo logs to be created. Listing 10.10 provides an example of such a situation. Listing 10.10: Recovering from Loss of the Online Redo Logs after an Abnormal Database Shutdown A slightly different problem. This time we crashed the database (via a SHUTDOWN ABORT perhaps), so recovery is more complicated. In this situation, there is a likelihood of data loss. We performed another hot backup before this exercise. SQL> SELECT count(*) FROM time_table; COUNT(*) 4096 SQL> ALTER SYSTEM SWITCH LOGFILE; System altered. SQL> INSERT INTO time_table SELECT * FROM time_table; 4096 rows created. SQL> SELECT COUNT(*) FROM time_table; COUNT(*) 8192 SQL> COMMIT; Commit complete. SQL> connect / as sysdba Connected. Oh no!! System crash big time! SQL> SHUTDOWN ABORT ORACLE instance shut down. Restart the database. SQL> STARTUP ORACLE instance started. Total System Global Area 92280076 bytes Fixed Size 70924 bytes RECOVERIES IN ARCHIVELOG MODE Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY 478 Variable Size 87937024 bytes Database Buffers 4194304 bytes Redo Buffers 77824 bytes Database mounted. ORA-00313: open failed for members of log group 3 of thread 1 ORA-00312: online log 3 thread 1: ‘D:\ORACLE\ORADATA\RECOVER\REDO03.LOG’ ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. We lost our online redo log file. It is nowhere to be found. So, we need to recover the database. Can we do a regular recovery? SQL> RECOVER DATABASE; ORA-00283: recovery session canceled due to errors ORA-00313: open failed for members of log group 3 of thread 1 ORA-00312: online log 3 thread 1: ‘D:\ORACLE\ORADATA\RECOVER\REDO03.LOG’ ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. No way … that missing redo log is murder. We need to do cancel- based recovery or change-based recovery. Let’s do cancel-based. What log sequences do we have available? SQL> ARCHIVE LOG LIST Database log mode Archive Mode Automatic archival Enabled Archive destination D:\Oracle\oradata\Recover\archive Oldest online log sequence 2 Next log sequence to archive 4 Current log sequence 4 So, the lost log sequence number is 4 (this shows as the current log file). We need to recover to log sequence number 3, which we should have available. Let’s do that with cancel-based recovery. Apply log sequence 1. SQL> RECOVER DATABASE UNTIL CANCEL; ORA-00279: change 56033 generated at 04/29/2001 00:52:37 needed C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 479 ORA-00289: suggestion : D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00001.ARC ORA-00280: change 56033 for thread 1 is in sequence #1 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00279: change 56047 generated at 04/29/2001 00:53:53 needed ORA-00289: suggestion : D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00002.ARC ORA-00280: change 56047 for thread 1 is in sequence #2 ORA-00278: log file ‘D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00001.ARC’ no longer needed for this recovery Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00279: change 56056 generated at 04/29/2001 00:55:02 needed ORA-00289: suggestion : D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00003.ARC ORA-00280: change 56056 for thread 1 is in sequence #3 ORA-00278: log file ‘D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00002.ARC’ no longer needed for this recovery Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00279: change 56065 generated at 04/29/2001 00:56:44 needed ORA-00289: suggestion : \D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00004.ARC ORA-00280: change 56065 for thread 1 is in sequence #4 ORA-00278: log file ‘D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00003.ARC’ no longer needed for this recovery Specify log: {<RET>=suggested | filename | AUTO | CANCEL} cancel Media recovery canceled. SQL> ALTER DATABASE OPEN RESETLOGS; Database altered. Note the data loss. We have only half the number of rows in time_table that we should have!! SQL> SELECT COUNT(*) FROM time_table; RECOVERIES IN ARCHIVELOG MODE Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY 480 COUNT(*) 4096 WARNING While using SHUTDOWN ABORT may work 99.99 percent of the time, you should realize that there is some risk to your database in doing this. If you do a SHUT- DOWN ABORT, and you lose your online redo log file, you will likely suffer some data loss. To reduce this risk, issue an ALTER SYSTEM SWITCH LOGFILE command and then an ALTER SYSTEM CHECKPOINT command before forcing a SHUTDOWN ABORT. It will make the shutdown take a bit longer, but it reduces your risk somewhat (but not completely). Control File Backups Control file backups come in two flavors: • Backup control files are generated through the use of the ALTER SYSTEM BACKUP CONTROL FILE TO ‘filename’ command, as in this example: ALTER DATABASE BACKUP CONTROL FILE TO ‘d:\oracle_backup\control\backup_control_01.ctl’; • Trace files can be created that contain the DDL required to re-create the current control file. This is facilitated through the use of the ALTER SYSTEM BACKUP CONTROL FILE TO TRACE command. Both methods are useful when you need to recover the database. The trace file gen- erated by the ALTER SYSTEM BACKUP CONTROL FILE TO TRACE command also serves as a good piece of documentation for your database, because it lists various database configuration information. NOTE The backup control file itself is not readable. It is in the same format as the Oracle control file. Using the Backup Control File for Database Recovery If you use the backup control file to recover a database, you must use the USING BACKUP CONTROL FILE syntax of the RECOVER command. Listing 10.11 provides C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 481 an example of using a backup control file to recover a database. Note that when recovering with a backup control file, you will need to use RESETLOGS to open the database. NOTE In many cases, when you use the CREATE CONTROL FILE command to recover from a lost control file, you will not need to issue a RESETLOGS command. You always need to use RESETLOGS when recovering with a backup control file. Listing 10.11: Using a Backup Control File when Recovering a Database First, create a backup control file. SQL> ALTER DATABASE BACKUP CONTROLFILE TO 2 ‘d:\oracle_backup\control\backup_control_01.ctl’; Database altered. Shut down the database. SQL> SHUTDOWN IMMEDIATE Database closed. Database dismounted. ORACLE instance shut down. Now, remove the existing control files. SQL> HOST DEL d:\oracle\oradata\recover\*.ctl Try to start up the database. SQL> STARTUP ORACLE instance started. Total System Global Area 92280076 bytes Fixed Size 70924 bytes Variable Size 87937024 bytes Database Buffers 4194304 bytes Redo Buffers 77824 bytes ORA-00205: error in identifying controlfile, check alert log for more info A snippet from the alert log looks like this: ORA-00202: controlfile: ‘D:\Oracle\oradata\Recover\control01.ctl’ CONTROL FILE BACKUPS Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY 482 ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. The database won’t start due to missing control files. Shut it down again. SQL> SHUTDOWN ORA-01507: database not mounted ORACLE instance shut down. Copy backup control file into place. SQL> HOST COPY d:\oracle_backup\control\backup_control_01.ctl d:\oracle\oradata\recover\control01.ctl SQL> HOST COPY d:\oracle_backup\control\backup_control_01.ctl d:\oracle\oradata\recover\control02.ctl SQL> HOST COPY d:\oracle_backup\control\backup_control_01.ctl d:\oracle\oradata\recover\control03.ctl Now, startup mount the database. SQL> STARTUP MOUNT ORACLE instance started. Total System Global Area 92280076 bytes Fixed Size 70924 bytes Variable Size 87937024 bytes Database Buffers 4194304 bytes Redo Buffers 77824 bytes Database mounted. Now, determine the current online log file sequence numbers. We may have to recover using an online sequence number. SELECT a.group#, a.member, b.sequence# FROM v$logfile a, v$log b WHERE a.group#=b.group#; GROUP# MEMBER SEQUENCE# 1 D:\ORACLE\ORADATA\RECOVER\REDO01.LOG 10 C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 483 2 E:\TESTRECOVER\REDO02.LOG 11 3 D:\ORACLE\ORADATA\RECOVER\REDO03.LOG 9 Now, recover the database. SQL> RECOVER DATABASE USING BACKUP CONTROLFILE; ORA-00279: change 136287 generated at 04/29/2001 22:48:45 needed for thread 1 ORA-00289: suggestion : D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00011.ARC ORA-00280: change 136287 for thread 1 is in sequence #11 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} e:\testrecover\redo02.log Log applied. Media recovery complete. Note that we had to apply the current online redo log (redo02.log) instead of taking the prompted archive log sequence number. This isn’t always going to be required, but it does happen. Now, we open the database with RESETLOGS. SQL> ALTER DATABASE OPEN RESETLOGS; Database altered. Using a Trace File If you are going to use a trace file resulting from the BACKUP CONTROL FILE TO TRACE command, you will need to edit it first, because Oracle adds a trace file header on the trace file before generating the RECOVERY command. The trace file will con- tain a CREATE CONTROL file command. Review the command and make sure it is suitable. Once you are satisfied that the command is correct, connect to the database and start the instance with STARTUP NOMOUNT command. Following that, run the script with the CREATE CONTROL FILE inside of it to re-create the control file. Depending on the condition of your online redo logs, RESETLOGS may or may not be required. If the online redo logs are intact, you should not need to issue a RESETLOGS command. In fact, if the database was shut down cleanly, you won’t even need to recover the database. Listing 10.12 provides an example of using the results of the ALTER DATABASE BACKUP CONTROL FILE TO TRACE command to recover a database. CONTROL FILE BACKUPS Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.