Steps to perform Open Database Backup using Oracle

For a business that requires constant access to its data, it is mandatory that backups be performed while the database is operating. Oracle provides full access to the database, allowing modifications to all data, while the online database backup is operating. These "hot" backups can then be used for recovery as effectively as "cold" backups. There are several steps to follow to successfully perform an open database backup.

The backup database command backs up 1) all data files and 2) the control file but not the archived redo logs. If you take a consistent backup of the database, you can later use this backup to restore and recover without performing media recovery. That is, you will not have to apply any changes from the archived redo logs before opening the database. To take a consistent backup, you must satisfy the following two conditions: You must first shut down the database normally, that is, use one of the following statements:

1. shutdown,
2. shutdown normal,
3. shutdown immediate, or
4. shutdown transactional.

1. You must start up the database in mount state before taking the backup. If you are recovering a database using inconsistent backups, you must first make the database consistent through applying the archived redo logs before you can open it. Backups taken under the following conditions are inconsistent:
2. If you create a backup of a database after restarting a database that was shut down abruptly (say, because of a power failure) or with the shutdown abort command
3. If you create a backup of the database while the database is open

There is nothing wrong with inconsistent backups by definition, all open database backups are inconsistent. You can safely use inconsistent backups as the foundation of your backup and recovery strategy. Since database uptime is critical, most production databases depend on inconsistent backups. All you have to do is to make sure you are running your database in archive log mode and that you are backing up your archived redo logs along with your data files. The series of images below demonstrates how to perform an open database backup.

Before beginning a backup on an entire tablespace, identify all of the tablespace's datafiles using the DBA_DATA_FILES data dictionary view. If a specific datafile is to be backed up, use the fully specified filename of the datafile. Mark the beginning of the online tablespace backup by issuing the

ALTER TABLESPACE... BEGIN BACKUP

command. This command causes a checkpoint and freezes the datafile header. This freeze prevents the sequence number in the datafile header from changing. In case a future recovery on the datafile is needed, logs are applied from the backup start time (as found in the frozen datafile header). If the DBA forgets to mark the beginning of an online tablespace backup properly, (for example, forgetting to enter the BEGIN BACKUP command), the backup datafiles will not be useful for recovery operations unless the tablespaces being backed up are read-only tablespaces.

The first block of each datafile is called the datafile header. It contains critical information used to maintain the overall integrity of the database. One of the most critical pieces of information in this header is the checkpoint structure. This is a logical timestamp that indicates the last point at which changes were written to the datafile. This timestamp is critical during an Oracle recovery process as the timestamp in the header determines which redo logs to apply in bringing the datafile to the current point in time.

The DBA uses the operating system command COPY to copy all datafiles in the tablespace to the back up storage.

To avoid performing any unnecessary media recovery, the DBA must end an open database backup properly. Mark the end of the tablespace backup by issuing the

ALTER TABLESPACE...END BACKUP

command. If you forget to indicate the end of an online tablespace backup and an instance failure or SHUTDOWN ABORT happens, Oracle will assume that media recovery is necessary at the next instance start up. Repeat the above steps for all tablespaces, including SYSTEM, temporary tablespaces, and rollback segment tablespaces. During the process of open database backup, the database remains available for normal transactions. When a datafile is in backup mode, more redo records may be generated because the LGWR writes to the redo logs and the block images of the changed blocks in backup mode, instead of just writing the row information. The time between the commands

ALTER TABLESPACE...BEGIN BACKUP

and

ALTER TABLESPACE...END BACKUP

must be minimized. Therefore, you should perform a backup of one tablespace at a time.

The log writer is the background process responsible for writing transaction information from the redo log buffer (in the SGA) to the online redo log files (on disk). The Log writer flushes the contents of the redo log buffer when any of the following are true:

1. A COMMIT or ROLLBACK issued.
2. A log switch occurs.
3. Three seconds go by.
4. The redo log buffer is one-third full.
5. The redo log buffer fills to one megabyte.

The online redo log group that the log writer is actively writing to is the current online redo log group^[1]. The log writer writes simultaneously to all members of a redo log group and needs to successfully write to only one member in order for the database to continue operating. The database ceases operating if the log writer cannot write successfully to at least one member of the current group.
When the current online redo log group fills up, a log switch occurs, and the log writer starts writing to the next online redo log group. The log writer writes to the online redo log groups in a round-robin fashion. Because you have a finite number of online redo log groups, eventually the contents of each online redo log group are overwritten. If you want to save a history of the transaction information, you must place your database in archivelog mode.
When your database is in archivelog mode, after every log switch the archiver background process copies the contents of the online redo log file to an archived redo log file. In the event of a failure the archived redo log files allow you to restore the complete history of transactions that have occurred since your last database backup.

Click the Quiz link below to review your understanding of basic database backup concepts.
Performing Backup - Quiz

[1]archived redo log:An archived redo log in Oracle is a copy of a filled online redo log file, stored offline for safekeeping. These archived logs, along with database backups, are crucial for performing complete database recoveries from disk failures or instance crashes. In addition to recovery, archived redo logs can also be used to update standby databases and analyze database history through the LogMiner utility.

[2]current online redo log group: The current online redo log group in Oracle is the group of redo log files that the database is currently writing to. The database maintains a list of online redo log groups, and it cycles through these groups as it writes redo logs.