12.1 What Are the Backup Options? There are several different forms of backups that can be performed to ensure the recovery of data to a database. With the release of Oracle8, even more options become available. The backup options now available are: -
Cold backups performed with the database shut down -
Hot backups (available for Oracle version 7 forward) performed with the database up and available -
Logical backups (exports) a snapshot in time, performed with the database up and available -
The Enterprise Backup Utility (EBU) for UNIX version 7 users only -
Backup set (new with Oracle8) performed using the Recovery Manager with the database up and available -
Image copy (new with Oracle8) performed using the Recovery Manager with the database up and available Hot and cold backups capture an image of the database by making a copy of the files comprising the database and saving the copy of the files to another disk on your system or to tape. If you use a file-level hot or cold backup, you'll be able to recover your database to the point in time at which the copies of the files were made. You replace the damaged datafiles on your system with the copies of the files you have made. Logical backups are created using an Oracle-supplied utility called EXPORT . The utility enables you to capture a snapshot of the database as it appears at the time when you performed the export. Using an export, you can recover just a table or two if you need to, without having to restore the entire database, or you can recover an entire tablespace. For UNIX platforms using version 7 databases, Oracle provides the Enterprise Backup Utility. This utility is configured to work with a media management product to provide a high-performance, robust backup and restore solution for large database managers. One of the key features of the EBU is its ability to perform online recovery to only the affected areas while enabling unaffected areas to remain available. Backup sets and image copies are new with the Oracle8 RDBMS and are created using the new Oracle-supplied Recovery Manager utility. Like hot and cold backups, backup sets are copies of the database files. The difference is that the Recovery Manager controls the making of the copies and keeps track of when the copies were made and where they are stored. As the name implies, you use the Recovery Manager not only to create the backups automatically, but also to perform database recovery in an automated manner. We'll discuss each of these backup mechanisms in more detail and look at the recovery options available to you. 12.1.1 About Archivelog Mode As we mentioned earlier in Chapter 2, Oracle uses redo log files to capture changes made to the database. The redo log files are written to in a circular manner and, when all of the available redo log files have been filled up, the log writer (LGWR) begins to overwrite the first redo log file, thus destroying the old changes stored there. Oracle provides you with the ability to save off the redo log files before they are reused and overwritten with new data. The mechanism used to save off the redo log files is called archivelog mode . When you have enabled archivelog mode, the redo log file information is saved off to separate archive log files either on a disk on your system or to a tape. If you enable archivelog mode, you can recover your database to a point in time other than the time at which your backups were created. Archivelog mode is enabled using a two-step process. The default INIT.ORA file contains several archivelog mode parameters commented out. The first step in enabling archivelog mode is to uncomment the parameters: log_archive_start = true log_archive_dest = %ORACLE_HOME%\database\archive log_archive_format = "%%ORACLE_SID%%T%S.ARC" - LOG_ARCHIVE_START
-
Tells Oracle to logically begin the archivelog mode process. However, just uncommenting these parameters and "bouncing" the database will not completely enable archivelog mode. You must set the other archivelog parameters as well. - LOG_ARCHIVE_DEST
-
Tells Oracle where to write the archive logs. This value can be either a disk on the operating system or a tape drive and is operating system-dependent. - LOG_ARCHIVE_FORMAT
-
Tells Oracle what format the archive log file names should be (i.e., what the names should look like). The "%T" is the thread number while the "%S" is the log sequence number. A capital "S" tells Oracle that the log sequence number should be a fixed length and padded with zeros. The three parameters shown above are the basic archive log parameters already present in the INIT.ORA parameter file. There are other parameters available for the archivelog mode, but these three are the ones you must set in order to successfully enable archivelog mode on your database. The second step, using svrmgrl , is to STARTUP MOUNT your database but do not OPEN it. From svrmgrl , issue the command: ALTER SYSTEM ARCHIVE LOG START; After you have issued this command, specify: ALTER DATABASE OPEN; Your database is now in archivelog mode. Each time a redo log is filled or a checkpoint is reached, the data from the redo log file is saved to an archive log file by the ARCH process. You can use the archive log files to recover your database to a point in time later than the time the last hot or cold backup was taken. 12.1.2 Cold Database Backups A cold database backup , also referred to at times as an image backup , derives its name from the fact that the database is shut down to perform this action. You must ensure that no processes are active within the database when the attempt is made to shut the database down. A good shutdown procedure includes verification that all processes have been stopped before a SHUTDOWN NORMAL command (the Oracle recommended shutdown) is issued to shut the database down. If there are any connected users, the database cannot be shut down with the NORMAL option. After the database is shut down, each file that makes up the database is copied either to another disk or to tape. This process is referred to as a file-level copy . The files copied should include all datafiles, redo logs, control files, and the INIT.ORA file. There are many different system-dependent utilities that can be used to perform the actual backing up of the files. Among them are the following: -
UNIX: obackup , tar , dd , fbackup , or cpio -
VMS: BACKUP -
Windows NT: Backup Manager or OCOPY -
MAC: GUI Finder to copy to disk, third-party software such as Dantz Retrospect -
OS/2: Standard DOS/OS2 copy -
NetWare: NetWare NBACKUP utility, third-party software -
MVS: DFDSS or IDCAMS using EXPORT (not REPRO) After the file-level copy is completed, the database is restarted. When the copy is completed, if a disaster occurs, the database can be recovered to the condition it was in when the copy was made. The disadvantage of performing a file-level copy is that it is very difficult, though not impossible , to recover one or more individual tables easily. When a cold backup is used in conjunction with archive logging, the database can be recovered to a "point in time" or "until cancel." For example, suppose that the database is backed up at midnight on Sunday and archive logging is enabled. The system suffers a catastrophic event on Tuesday at 2:30 P.M. The DBA would first save off the current redo log files and control files to a separate area and then restore the files from the backup. The DBA would then replace the older log files with the current saved ones and roll forward through the archive log files until 2:29 P.M. on Tuesday just prior to the disaster. The result is that the organization would lose only the uncommitted transactions in process at the time the recovery was discontinued. 12.1.3 Hot Database Backups Hot database backups are essential for a 24- hour -a-day, 7-day-a-week environment. They derive their name from the fact that the database remains up and running while the backup is performed. Essentially, file-level copies are made of the datafiles (as with the cold database backups). Archivelog mode must be enabled to ensure that effective backups are captured. To begin a hot backup of a tablespace's datafile(s), issue the command: ALTER TABLESPACE <ts_name> BEGIN BACKUP where ts_name is the tablespace name. Once you have issued this command from svrmgrl or SQL*Plus, return to the operating system level and copy the datafiles corresponding to the tablespace to another disk or to tape just as you would for a cold database backup. There are some procedures that must be followed if effective hot backups are to be made. You must: -
Be sure to use ALTER TABLESPACE ts_name END BACKUP after completing each tablespace's file copies -
Capture the current log file by using ALTER SYSTEM SWITCH LOGFILE; -
Capture all archive logs from the time the backup was started until the backup is completed -
Back up the controlfile using the ALTER DATABASE BACKUP CONTROLFILE TO `filespec'; command As with cold backups, individual tables cannot easily be recovered but the database can be recovered to a "point in time" or until cancel. Oracle recommends doing hot backups during periods when less DML is occurring on the system. 12.1.4 Logical Database Backups (Exports) An export is actually a "snapshot in time." There are several forms of export you can perform: A full database export captures a snapshot of the entire database at a particular point in time. Every object within the database is captured, including all tablespace definitions, users, tables, views, etc. You can perform an export to capture all of the objects owned by one or more particular users or schemas, or you can export a specific table or set of tables owned by a particular user or schema. Unlike a hot or cold backup, which captures complete datafiles and their contents, an export captures random pieces of the database or a complete copy of the entire database to one compressed file. To perform an export of a database, the database must be up and running. One advantage of having an export is that it allows you to easily recover a single table or set of tables. If a full database export has been performed, you can subsequently produce a file containing the complete documentation of the composition of the database by issuing the import command in conjunction with the parameters "show=y log=<filename>". Since anyone who has a privileged account in a database can run the import command and view the composition of the database that has been exported, you must ensure that the export files are kept in a restricted-access area of the operating system. Although the show command used in conjunction with a log file name produces what appears to be a usable SQL script, the output generated is not formatted properly to enable running the commands directly from the log file output. Using an export file, the database can only be recovered to the time at which the export was performed. The database cannot be recovered to a specific point in time. Although archive logging can be used with any database if enough disk or tape storage is available for that system, archive logs cannot be used in conjunction with an export to restore a database. Export files are very portable and can be used to move or copy a database from one system to another. However, the process of exporting can be very slow and may not be feasible for very large databases. An interesting characteristic of the export process is that it identifies any data block corruption; it does so by failing. There are several different forms of export that can be performed using the parameter "INC_TYPE="; you can specify: - COMPLETE
-
For a full database export - INCREMENTAL
-
Captures what has changed from the last increment (but can't be specified as read-consistent) - CUMULATIVE
-
Captures what has changed since the last full export In all of these cases, you must also specify the "FULL=Y" parameter. The information about an export that has been performed using "INC_TYPE=" can be seen from SQL*Plus by performing a SELECT from: - SYS.INCEXP
-
For objects in specific exports - SYS.INCFIL
-
For incremental and cumulative exports - SYS.INCVID
-
EXPID used to determine next EXPID To see the full list of the available export parameters, specify the command "EXP HELP=Y" at the operating system command prompt. 12.1.5 Enterprise Backup Utility As we mentioned earlier. Oracle began providing a utility with version 7 for UNIX platforms. This utility, the Enterprise Backup Utility, is intended to solve the problem of providing backup and restore functions for a very large database in a timely and effective manner. EBU works with several media management products, including: -
Epoch EpochBackup -
IBM Adstar Distributed Storage Manager -
Legato Systems NetWorker -
Hewlett-Packard Omniback II -
SprectraLogic Alexandria -
StorageTek REEL Backup and REEL Librarian -
Open Vision NetBackup Not all products listed here work on all platforms for which EBU is available. The EBU consists of software programs and a Backup Catalog. Oracle recommends that the EBU software and Backup Catalog be placed on a disk separate from the systems to be backed up. That way, if a media failure occurs, you can recover using the product from a separate area. If you have placed the software and Backup Catalog in a separate area and you have more than one database to back up, you can use this central area as the location for all your database backups. The utility creates and runs processes for each backup or recovery job and requires a separate set of executables for each database to be protected. There are several processes that run for each database being backed up: - BRD (Instance Manager)
-
This is a daemon process that monitors the Backup Catalog and obackup . The Instance Manager handles the cleanup work for all backup and restore operations which terminate abnormally. - obackup
-
Monitors all the other processes and communicates with both the database being backed up and the Backup Catalog. obackup will spawn the Instance Manager process if it terminates abnormally. - BRDK
-
Handles reads and writes of disk files. There is one BRDK process per file. - BRTP
-
Handles the reads and writes to tape files. There is one BRTP per I/O stream. - BRIO
-
Coordinates between the obackup , BRDK, and BRTP processes. There is one BRIO process per parallel I/O stream. During backups, BRDK reads the database files into a backup buffer area. After the BRDK process puts the backup information into the backup buffer area, the BRTP process writes the backup information to tape using the third-party media management system. During restoration operations, the BRTP process reads the information from tape via the third-party media management system and places the information in a restoration buffer area. The BRDK process takes the buffered information and writes it back to the database file. The other processes act in a managerial capacity, performing cleanup and processing errors. The Backup Catalog tracks state information about each backup and restore job. The Backup Catalog also retains history information for browsing and reporting functions. When you run the EBU, the first thing the utility does is verify your current database configuration against the Backup Catalog information. If your database configuration has changed you've added a new tablespace with two datafiles, for example the Backup Catalog will be updated to reflect the changes and then the backup will be run. The EBU supports both raw devices and file systems. You can perform partial or complete backups, and EBU will use whatever files it needs from both partial and full backups to restore the database files. You can even restore files to a point in time. The EBU is really a forerunner of the Oracle8 Recovery Manager, which we will discuss next. | 
