CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY 434 Shut down and remount the database. This is required to put the database in ARCHIVELOG mode. Once the database is shut down, proceed to mount it again. After you remount it, the ARCH process should be running. Put the database in ARCHIVELOG mode and open it. At this point, you can put the database in ARCHIVELOG mode by using the ALTER DATABASE ARCHIVELOG command. Then open the database by issuing the ALTER DATABASE OPEN command. Next, you will want to test the configuration of the ARCH process. Why? Well, if you incorrectly set up ARCH so that it is writing to a directory that doesn’t exist, guess what will happen soon: The database will come to a screeching halt. This hap- pens because Oracle will not allow you to overwrite the online redo log file until ARCH can write out the archived redo logs successfully. If you are trying to archive to a destination that doesn’t exist, these attempts to create the archived redo logs will fail. To test your configuration, issue an ALTER DATABASE SWITCH LOGFILE com- mand. Then check the archived log destinations a few moments later. You should see an archived redo log file created in those directories. If these files are created, you are in good shape. After you put the database in ARCHIVELOG mode and test your configuration, you should proceed to perform a hot backup as quickly as possible. Then you will be able to recover your database using the archived redo logs, if necessary. Considering Online Redo Log Groups In NOARCHIVELOG mode, there is only one basic rule that Oracle follows in relation to redo log switches: Before an online redo log can be used, the changes represented within the redo it contains from its last use must have been written to the database datafiles. Thus, Oracle will not reuse a redo log if its previous contents have not been written to the database datafiles. This rule is in place to facilitate crash and instance recovery of the database. In ARCHIVELOG mode, things get a bit more complicated. When a log switch occurs, Oracle will first update the control file, indicating that the redo log needs to be archived. It will then signal the ARCH process, indicating that it has a redo log to process. The ARCH process will wake up (assuming it’s not processing another online redo log file already) and begin to copy that online redo log to the archived redo log directory defined in the init.ora file (by the ARCHIVE_LOG_DEST_n parameter). During the ARCH copy process, Oracle will proceed to the next available online redo log and continue database activity as normal. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 435 If Oracle proceeds through the remaining redo log groups and returns to the redo log group you are archiving, it will not reuse that online redo log until the archiving process has completed successfully for that online redo log file. If Oracle cannot use that online redo log, it will look for another available online redo log. If no online redo log is available, then the Oracle database will be suspended until the ARCH process has completed its moves. Once ARCH completes the move of the online redo log, it will update the control file, indicating that the online redo log has been archived. At that point, LGWR will be able to open and use the online redo log. The log switch process in ARCHIVELOG can pose a problem if you don’t have enough online redo log files (and/or if they are too small), because Oracle may not be able to write out the archived redo logs fast enough to keep up with the redo creation within the online redo logs. Thus, you may find that your database activity becomes suspended quite often—not a condition that users or managers desire. Something else to consider is the number of archive log destinations you will have. Adding a destination will increase the time it takes to archive your online redo logs. If you add a network destination, that will further erode the performance of the archiv- ing process. There are several possible solutions to this problem: • Add enough log file groups of sufficient size to reduce contention with the archiving process. • Reduce the number of archiving destinations. • Carefully tune the I/O. Try to separate the archived logs onto their own disks to reduce the I/O contention that ARCH might incur. Backup and Recovery in NOARCHIVELOG Mode With the database in NOARCHIVELOG mode, the online redo logs are overwritten without regard to recoverability of the database. Thus, the only backup option is a cold backup. A cold backup of a database is a backup that takes place while the data- base is shut down. Thus, during the period that the cold backup takes place, users will have no access to the database or the data within it. When you perform a cold backup in NOARCHIVELOG mode, you simply back up the entire physical structure of the database. A cold backup in NOARCHIVELOG mode includes backups of the following: • All database datafiles • All database control files BACKUP AND RECOVERY IN NOARCHIVELOG 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 436 • All online database redo logs • Other required database files such as init.ora The following sections describe the procedures for backing up and recovering a database in NOARCHIVE mode. Performing Cold Backups in NOARCHIVELOG Mode To perform a cold backup, you simply identify the database files to be backed up, shut down the database, and back up the physical files to the backup medium. Then you can start the database again. You might wonder why you need to shut down the database for a cold backup if you can ensure that nobody will make any changes to the database while it is up. As explained in Chapter 5, one method that Oracle uses to determine that the database is in a consistent state is by virtue of a fuzzy file flag maintained in each database datafile. If the fuzzy datafile flag is set when the database starts, the database will con- sider the datafile to be fuzzy. Thus, if you recover a datafile that was backed up while the database was running, even if the database had no activity, that backup is not usable for recovery purposes. This is because the fuzzy flag will have been set in the open position. There are some ways to force the database open in these cases (as you will learn later in this chapter), but these methods are not recommended. Identifying the Files to Back Up To locate the database datafiles, control files, and online redo logs to back up, you can use some data dictionary queries. Use the DBA_DATA_FILES data dictionary view to find the database datafiles, as in this example: SELECT tablespace_name, file_name, file_id FROM dba_data_files ORDER BY tablespace_name, file_name; TABLESPACE_NAME FILE_NAME FILE_ID IDX D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF 4 RBS D:\ORACLE\ORADATA\RECOVER\RECOVER_RBS_01.DBF 2 SYSTEM D:\ORACLE\ORADATA\RECOVER\SYSTEM01.DBF 1 TEMP D:\ORACLE\ORADATA\RECOVER\RECOVER_TEMP_01.DBF 5 USERS D:\ORACLE\ORADATA\RECOVER\RECOVER_USERS_01.DBF 3 To find the database control files, query the V$CONTROL_FILE data dictionary view: SQL> SELECT * FROM v$controlfile; C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 437 STATUS NAME D:\ORACLE\ORADATA\RECOVER\CONTROL01.CTL D:\ORACLE\ORADATA\RECOVER\CONTROL02.CTL D:\ORACLE\ORADATA\RECOVER\CONTROL03.CTL Finally, use a query to the V$LOGFILE data dictionary view to locate the database online redo log files: SQL> SELECT * FROM v$logfile; GROUP# STATUS MEMBER 1 D:\ORACLE\ORADATA\RECOVER\REDO01.LOG 2 STALE D:\ORACLE\ORADATA\RECOVER\REDO02.LOG 3 D:\ORACLE\ORADATA\RECOVER\REDO03.LOG Running the Backup After you’ve identified the database files, you’re ready to perform a cold backup. To do so, you must first shut down the database. When shutting down the database for a cold backup, it is strongly recommended that you use either the normal SHUTDOWN command or the SHUTDOWN IMMEDIATE command. This will cause DBWn to flush all dirty buffers to the database datafiles. As long as you have issued either a SHUT- DOWN or SHUTDOWN IMMEDIATE command, you will not need to recover (or back up) the online redo log files for the database. Now, you can proceed to back up the physical database files that you identified. To shorten the time of the overall outage required to back up the database, you may wish to back up the datafiles to disk, open the database, and then back up the other files to slower backup medium, such as tape. It is often advisable to include in your final backup image a copy of a backup control file (aside from the backup of the current control file). A backup control file is a backup of the control file that can be used to recover the control file in the event that it is lost. We will discuss the creation of a backup control file later in this chapter, in the “Control File Backups” section. When you’re finished backing up the database, you can open the database again. Listing 10.1 shows an example or running a cold backup in NOARCHIVELOG mode. NOTE All of the examples in this chapter were done on Windows NT. The principles are the same, regardless of the operating system. Only the operating system commands (such as copy, cp, tar, or tape backup) are different. BACKUP AND RECOVERY IN NOARCHIVELOG 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 438 Listing 10.1: Performing a Cold Backup in NOARCHIVELOG Mode D:\ORACLE\ORA816\DATABASE>sqlplus “sys/robert as sysdba” SQL> SHUTDOWN IMMEDIATE Database closed. Database dismounted. ORACLE instance shut down. Now we are going to back up the database. Note that we have a pretty poorly set up database here, because everything is on one drive. We did that mostly just to keep the example easy and to save page space. SQL> HOST MKDIR d:\backup_oracle SQL> HOST COPY d:\oracle\oradata\recover\*.* d:\backup_oracle\*.* d:\oracle\oradata\recover\CONTROL01.CTL d:\oracle\oradata\recover\CONTROL02.CTL d:\oracle\oradata\recover\CONTROL03.CTL d:\oracle\oradata\recover\REDO01.LOG d:\oracle\oradata\recover\REDO02.LOG d:\oracle\oradata\recover\REDO03.LOG d:\oracle\oradata\recover\SYSTEM01.DBF d:\oracle\oradata\recover\RECOVER_RBS_01.DBF d:\oracle\oradata\recover\RECOVER_USERS_01.DBF d:\oracle\oradata\recover\RECOVER_TEMP_01.DBF d:\oracle\oradata\recover\afiedt.buf d:\oracle\oradata\recover\recover_idx_01.dbf.backup d:\oracle\oradata\recover\RECOVER_IDX_01.DBF 13 file(s) copied. Backup is complete, restart 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 Database mounted. Database opened. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 439 NOTE Listing 10.1 and many other examples start SQL*Plus or connect to the database using the ”/ as sysdba” or “sys/robert as sysdba” string. This is done for two reasons. First, Oracle will be dropping support for CONNECT INTERNAL in Oracle9i, so we are trying to prepare for that eventuality. Second, with Oracle release 8.1.6, we are forced to put the username and password on the command line. This is due to a bug in 8.1.6 that was fixed in 8.1.7. If you are running 8.1.7, you can use “system as sysdba” with SQL*Plus, and then respond to the password prompt that follows. Recovering Cold Backups in NOARCHIVELOG Mode Recovering a database from a cold backup taken in NOARCHIVELOG mode is fairly simple. Issue a SHUTDOWN ABORT command on the database instance to make sure that all the database processes are stopped and all operating system locks on files that might remain are released. Then recover all of the database files to their original loca- tions, if possible. If this is not possible, record the new location of the database files for later use. If any of the files were recovered to a different location, you will need to reset the location as follows: • If the control files were recovered to a different location, edit the database param- eter file to reflect the new location for the control files. Change any other direc- tory paths that might have changed as a result of the recovery process. • If the database datafiles or the redo logs were recovered to another location, you will need to mount the database by issuing a STARTUP MOUNT command. Issue the ALTER DATABASE RENAME FILE command for each datafile that was recovered to another location. • If the online redo logs were recovered to another location, issue the ALTER DATABASE RENAME FILE command to reset the location of the database online redo logs. When all of the database files have been recovered, issue the STARTUP command, and the database should open normally. Listing 10.2 provides an example of recover- ing a database that was backed up in NOARCHIVELOG mode. (Note that due to book page line-length restrictions, some code is broken into multiple lines.) Listing 10.2: Performing a Cold Backup Recovery in NOARCHIVELOG Mode D:\ORACLE\oradata\RECOVER>sqlplus “sys/robert as sysdba” SQL> STARTUP BACKUP AND RECOVERY IN NOARCHIVELOG 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 440 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-01157: cannot identify/lock datafile 4 - see DBWR trace file ORA-01110: datafile 4: ‘D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF’ SQL> SHUTDOWN ABORT ORACLE instance shut down. Recover the database from the backup we made earlier. SQL> HOST COPY d:\backup_oracle\*.* d:\oracle\oradata\recover\recover_idx_01.dbf d:\backup_oracle\CONTROL01.CTL d:\backup_oracle\CONTROL02.CTL d:\backup_oracle\CONTROL03.CTL d:\backup_oracle\REDO01.LOG d:\backup_oracle\REDO02.LOG d:\backup_oracle\REDO03.LOG d:\backup_oracle\SYSTEM01.DBF d:\backup_oracle\RECOVER_RBS_01.DBF d:\backup_oracle\RECOVER_USERS_01.DBF d:\backup_oracle\RECOVER_TEMP_01.DBF d:\backup_oracle\afiedt.buf d:\backup_oracle\recover_idx_01.dbf.backup d:\backup_oracle\RECOVER_IDX_01.DBF 1 file(s) copied. 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. Database opened. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 441 If you were not able to recover the online redo logs from the backup medium, you can still recover the database in many cases. First, if you were able to recover at least one member of each redo log group, you can create a copy of that online redo log, naming it with the name of the missing online redo log. If none of the online redo logs are avail- able, as long as you shut down your database normally (or with the IMMEDIATE option), all you need to do is open the database with the following command: ALTER DATABASE OPEN RESETLOGS; We will discuss the RESETLOGS command in more detail later in this chapter, in the “RESETLOGS and Recovery” section. For now, suffice it to say that issuing this command will cause the database to create new redo logs. Also, if the control file is missing, you can recover using the backup control file, as described in the “Control File Backups” section later in this chapter. Backups in ARCHIVELOG Mode The principle difference between NOARCHIVELOG mode and ARCHIVELOG mode is the creation of archived redo logs, and associated with that, the ability to back up the database while it is still running and recover the database to point of failure, or some point prior to that failure. It is this functionality and reliability that make Oracle the most popular database in the world. Performing Cold Backups in ARCHIVELOG Mode Cold backups in ARCHIVELOG mode are much the same as those in NOARCHIVELOG mode, except that you don’t need to back up the online redo logs or the control files. It is best not to back up online redo logs during backups in ARCHIVELOG mode (unless you are not saving the archived redo logs), because you do not want to acciden- tally recover them over existing online redo logs during a recovery. Also, overwriting the existing control file will hamper your ability to recover the database to the point of failure. Instead, create a backup control file, as discussed later in this chapter in the “Control File Backups” section. The steps for performing a cold backup in ARCHIVELOG mode are as follows: 1. Identify the database datafiles to be backed up. 2. Shut down the database. 3. Back up the physical datafiles to the backup medium. 4. Start the database. BACKUPS 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 442 5. Back up the existing archived redo log. (This is not really a requirement at this point if you shut down the database normally, but it’s good practice.) 6. Back up the archived redo logs on a regular basis. All of these steps, except the last two, are the same as those for a cold backup in NOARCHIVE mode. Steps 5 and 6 pertain to backing up archived redo logs, which is covered in the next section. Backing Up Archived Redo Logs When you are doing any backup in ARCHIVELOG mode, it is assumed (and in the case of hot backups, required) that the archived redo logs created during the time of the backup are themselves backed up. It is the backup of these logs (and subsequent backups of newly created archived redo logs) that allows an Oracle database in ARCHIVELOG mode to be recovered. When recovering from hot backups, all of the archived redo logs generated during the hot backup are required during the recovery process. In addition, if you wish to recover the database to a point beyond the point of recovery, you will need all of the generated archived redo logs as well. As explained earlier in this chapter, the location of the archived redo logs is defined in the init.ora file using the LOG_ARCHIVE_ DEST_n parameter. You can query the V$ARCHIVE_DEST data dictionary view to determine the current location of the archived log directories, as follows: SELECT destination FROM v$archive_dest; DESTINATION D:\Oracle\oradata\Recover\archive NOTE The V$ARCHIVE_DEST data dictionary view contains a row for each destination, even if the destination is not defined. How often should archived redo logs be backed up? The answer to the question is really another question: How much data loss can you tolerate? Since the archived redo logs are typically stored on the same system as the database that generated them, there is some risk of loss of these files. When configuring your database, you should give careful consideration to using alternative storage locations, such as network appliances or other options, to reduce the risk of datafile loss. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 443 Also keep in mind the performance implications of your archived redo log configu- rations. The more archived redo log destinations you configure, the longer the ARCH process will take to copy each archived redo log. If you are copying these over the net- work (to a standby database in Net8), this may even further impact the overall perfor- mance of the ARCH process. Remember that Oracle will not be able to reuse an online redo log until all required copies to archive locations are complete. NOTE Besides being useful for recovery, archived redo logs can also be run through the Oracle8i utility called LogMiner, which we will cover in Chapter 14. LogMiner allows you to review the archived redo logs for security audits and other purposes. Archived redo logs are also used to keep standby databases current, as explained in Chapter 26, which dis- cusses high-availability options. Performing Hot Backups in ARCHIVELOG Mode Now we reach the big time—hot backups in ARCHIVELOG mode. When you imple- ment hot backups in your database, you enter a whole new world of recovery options. When doing hot backups, you simply do not back up control files and online redo logs. What you do is put tablespaces in hot backup mode. These tablespaces are asso- ciated with the datafiles that you have chosen to back up. When you put tablespaces in hot backup mode, Oracle generates block-level redo to the online redo logs, as opposed to the normal atomic redo records that are created when the tablespaces are not in hot backup mode. This means that all redo generated for the tablespace is generated as an image of the entire block, rather than as just redo records. Thus, redo generation is substantially increased during hot backup operations (however, this is not true with RMAN hot backups, which are discussed in Chapter 13). Block images are recorded in the redo logs to avoid problems with operating sys- tem block splitting. Since Oracle continues to write to database datafiles during hot backups, there is a possibility that the backed up image of the datafile will contain fractured blocks. This is because the operating system write batch size may be smaller than the block size of the database, so the backup image of a given datafile may con- tain a block that is of two different versions. The generation of block images in the online redo logs solves this problem by allowing the block to be restored during the backup process. BACKUPS 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.