1
Why Perform Backups?

This chapter introduces database concepts that are fundamental to backup and recovery, and explains why taking backups is crucial for successful database operations. The following topics are included:

What Is a Backup?

Simply speaking, a database backup is a representative copy of data. When the original data is lost, you can use the backup to reconstruct lost information (the physical files that constitute your Oracle database). This copy includes important parts of your database, such as the control file, archive logs and datafiles-structures described later in this chapter and throughout this book. In the event of a media failure, your database backup is the key to successfully recovering your data.

Why Are Backups Important?

Imagine the magnitude of lost revenue (not to mention the degree of customer dissatisfaction!) if the production database of a catalog company, express delivery service, bank or airline suddenly became unavailable, even for just 5 or 10 minutes; or, if you lose datafiles due to media failure and cannot restore or recover them because you do not have a backup. From your enterprise's perspective, the results may be quite grim. You must restore and recover your data quickly to resume operations. The key to your success in this situation is a well-defined backup and recovery strategy.

When to Take Backups

You should tailor your backup strategy to the needs of your business. For example, if it is acceptable to lose data in the event of a disk failure, you may not need to perform frequent backups. What if your database must be available twenty-four hours a day, seven days a week? In this case, your database would have to be frequently backed up. The frequency of your backups and types of backups performed is determined in large part by the needs of your business.

Types of Failures

An unfortunate aspect of every database system is the possibility of a system or hardware failure. The most common types of failure are described below.

statement and process failure	Statement failure occurs when there is a logical failure in the handling of a statement in an Oracle program (for example, the statement is not a valid SQL construction). When statement failure occurs, the effects (if any) of the statement are automatically undone by Oracle and control is returned to the user. A process failure is a failure in a user process accessing Oracle, such as an abnormal disconnection or process termination. The failed user process cannot continue work, although Oracle and other user processes can. h minimal impact on the system or other users.
instance failure	Instance failure occurs when a problem arises that prevents an instance (system global area and background processes) from continuing work. Instance failure may result from a hardware problem such as a power outage, or a software problem such as an operating system crash. When an instance failure occurs, the data in the buffers of the system global area is not written to the datafiles.
user or application error	User errors can require a database to be recovered to a point in time before the error occurred. For example, a user might accidentally delete data from a table that is still required (for example, payroll taxes). To allow recovery from user errors and accommodate other unique recovery requirements, Oracle provides for exact point-in-time recovery. For example, if a user accidentally deletes data, the database can be recovered to the instant in time before the data was deleted.
media (disk) failure	An error can arise when trying to write or read a file that is required to operate the database. This is called disk failure because there is a physical problem reading or writing physical files on disk. A common example is a disk head crash, which causes the loss of all files on a disk drive. Different files may be affected by this type of disk failure, including the datafiles, the redo log files, and the control files. Also, because the database instance cannot continue to function properly, the data in the database buffers of the system global area cannot be permanently written to the datafiles.

Physical Database Structures

The following sections give a brief overview of the physical database structures of an Oracle database. These topics will be covered in more detail in subsequent chapters of this book.

Control Files

Every Oracle database has a control file. A control file is an extremely important datafile that contains entries specifying the physical structure of the database, and provide database consistency information used during recovery. For example, it contains the following types of information:

database name
names and locations of a database's datafiles and redo log files
time stamp of database creation
backup information (when using the Recovery Manager utility)

Like the redo log, Oracle allows the control file to be mirrored for protection of the control file.

Use of Control Files

Every time an instance of an Oracle database is mounted, its control file is used to identify the datafiles and redo log files that must be opened for database operation to proceed. If the physical makeup of the database is altered (for example, a new datafile or redo log file is created), the database's control file is automatically modified by Oracle to reflect the change.

You should back up the control file any time there are structural changes to the database.

Online Redo Log Files

Every Oracle database has a set of two or more redo log files. The set of redo log files for a database is collectively known as the database's redo log. Oracle uses the redo log to record all changes made to data. For example, a failure has prevented modified data from being permanently written to the datafiles. In this situation, you can obtain the modified data from the redo log and permanently write it to the datafiles, all-the-while preventing loss of work.

Redo log files are critical in protecting a database against failures. To protect against a failure involving the redo log itself, Oracle allows the redo log to be multiplexed. This means Oracle will maintain two or more copies of the redo log on different disks.

You do not need to back up the online redo log, nor should you ever need to restore it.

See Also: For more information about online redo logs, see "The Online Redo Log" on page 2-2.

The Use of Redo Log Files

The information in a redo log file is used only to recover the database from a system or media failure that prevents database data from being written to a database's datafiles.

For example, if an unexpected power outage abruptly terminates database operation, data in memory cannot be written to the datafiles and the data is lost. After power is restored, any lost data is recovered when the database is opened. By applying the information in the most recent redo log files to the database's datafiles, Oracle restores the database to the time at which the power failure occurred.

The process of applying the redo logs to datafiles and control files in order to recover them is called rolling forward.

Datafiles

Every Oracle database has one or more physical datafiles. A database's datafiles contain all the database data. The data of logical database structures such as tables and indexes is physically stored in the datafiles allocated for a database.

The following are characteristics of datafiles:

A datafile can be associated with only one database.
Database files can have certain characteristics set to allow them to automatically extend when the database runs out of space.
One or more datafiles form a logical unit of database storage called a tablespace.

The Use of Datafiles

The data in a datafile is read, as needed, during normal database operation and stored in the memory cache of Oracle. For example, assume that a user wants to access some data in a table of a database. If the requested information is not already in the memory cache for the database, it is read from the appropriate datafiles and stored in memory.

Modified or new data is not necessarily written to a datafile immediately. To reduce the amount of disk access and increase performance, data is pooled in memory and written to the appropriate datafiles all at once, as determined by the DBWR background process of Oracle.

Rollback Segments

Every database contains one or more rollback segments, which are portions of the database that record the actions of transactions in the event that a transaction is rolled back. You use rollback segments to provide read consistency, rollback transactions, and to put a database in a transaction-consistent state as part of recovery.

The Use of Rollback Segments

Rollback segments are used for a number of functions in the operation of an Oracle database. In general, the rollback segments of a database store the old values of data changed by ongoing transactions (that is, uncommitted transactions). Among other things, the information in a rollback segment is used during database recovery to "undo" any "uncommitted" changes applied from the redo log to the datafiles. Therefore, if database recovery is necessary, the data is in a consistent state after the rollback segments are used to remove all uncommitted data from the datafiles.

Archived Logs

Archived log files are redo logs that have been filled with redo, made inactive and copied or archived to a backup location. You can archive online redo files before reusing them; this creates the archived log. The presence or absence of an archived redo log is determined by the mode that the database is using:

ARCHIVELOG	The filled online redo log files are archived before they are reused in the cycle.
NOARCHIVELOG	The filled online redo log files are not archived.

When in ARCHIVELOG mode, the database can be completely recovered from both instance and disk failure. The database can also be backed up while it is open and available for use. However, additional administrative operations are required to maintain the archived redo log.

Typically, your only recovery option for databases operating in NOARCHIVELOG mode is to restore the whole database. Your only backup option is to back up the database while it is completely closed. Because no archived redo log is created, no extra work is required by the database administrator.

Note: The only time you can recover a database while operating in NOARCHIVELOG is when you have not already overwritten the online log files that were current at the time of the most recent backup.

1 Why Perform Backups?