Learn Oracle - Highlights
You can use RMAN or operating system commands to make an inconsistent backup or a consistent backup. An inconsistent backup is a backup of one or more database files that Oracle DBA make while the database is open or after the database has shut down abnormally. A consistent backup is a backup of one or more database files that Oracle DBA make after the database has been closed with a clean SHUTDOWN command. Unlike an inconsistent backup, a consistent, whole database backup does not require recovery after it is restored.
Whether Oracle DBA make consistent or inconsistent backups depends on a number of factors. If your database must be open and available all the time, then inconsistent backups are your only option. If there are recurring periods of minimal use, then Oracle DBA may decide to take regular consistent backups of the whole database and supplement them with online backups of often-used tablespaces.
Learn Oracle - Consistent Backups
A consistent backup of a database or part of a database is a backup in which all read/write datafiles and control files have been checkpointed with respect to the same system change number (SCN). In addition, every online, read/write datafile is not a fuzzy file, that is, does not contain changes beyond the SCN in the datafile header. Oracle determines whether a restored backup is consistent by checking the datafile headers against the datafile header information contained in the control file.
Oracle makes the control files and datafiles consistent to the same SCN during a database thread checkpoint. The only tablespaces in a consistent backup that are allowed to have older SCNs are read-only and offline normal tablespaces, which are still consistent with the other datafiles in the backup because no changes have been made to them. If the checkpoint SCN in the datafile header matches the offline-start SCN in the control file, then Oracle knows that the datafile needs no recovery.
The important point is that Oracle DBA can open the database after restoring a consistent whole database backup without applying redo because the data is already consistent: no action is required to make the data in the restored datafiles correct. Hence, you can restore a year-old consistent backup of your database without performing media recovery and without Oracle performing instance recovery.
The only way to make a consistent whole database backup is to shut down the database with the NORMAL, IMMEDIATE, or TRANSACTIONAL options and make the backup while the database is closed. If a database is not shut down cleanly, for example, an instance fails or Oracle DBA issue a SHUTDOWN ABORT statement, then the database's datafiles are always inconsistent--unless the database is a read-only database. Instance recovery will be required at open time.
A consistent whole database backup is the only valid backup option for databases operating in NOARCHIVELOG mode, because otherwise redo will need to be applied to create consistency. In NOARCHIVELOG mode, Oracle does not archive the redo logs, and so the required redo logs may not exist on disk.
Back to Top
Learn Oracle -Inconsistent Backups
An inconsistent backup is a backup in which all read/write datafiles and control files have not been checkpointed with respect to the same SCN. For example, one read/write datafile header may contain an SCN of 100 while other read/write datafile headers contain an SCN of 95 or 90. Oracle cannot open the database until all of these header SCNs are consistent, that is, until all changes recorded in the online redo logs have been applied to the datafiles on disk.
If the database must be up and running 24 hours a day, 7 days a week, then you have no choice but to perform inconsistent backups of a whole database. For example, a backup of an offline tablespace in an open database is inconsistent with other tablespaces because portions of the database are being modified and written to disk while the backup of the tablespace is progressing. The datafile headers for the online and offline datafiles may contain inconsistent SCNs. Oracle DBA must run your database in ARCHIVELOG mode to make online backups of online datafiles.
If you run the database in ARCHIVELOG mode, then Oracle DBA can construct a whole database backup using backups of online datafiles taken at different times. For example, if your database contains seven tablespaces, and if Oracle DBA back up the control file as well as a different tablespace each night, then in a week you will back up all tablespaces in the database as well as the control file. You can consider this staggered backup as a whole database backup.
Learn Oracle - Inconsistent Closed Backups
Oracle DBA have the option of making inconsistent closed backups if a database is backed up after a system crash or SHUTDOWN ABORT. This type of backup is valid if the database is running in ARCHIVELOG mode, because both online and archived redo logs are available to make the backup consistent.
If you run the database in NOARCHIVELOG mode, then only back it up when you have closed it cleanly with the IMMEDIATE, NORMAL, or TRANSACTIONAL options. Inconsistent whole database backups of databases running in NOARCHIVELOG mode are usable only if the redo logs containing the changes made prior to the backup are available when you restore it--an unlikely occurrence.
The reason that NOARCHIVELOG inconsistent backups are not recommended is that the datafile headers of the backed up files contain different SCNs (a normal shutdown guarantees the consistency of these SCNs), and because the database is in NOARCHIVELOG mode, no archived redo logs are available to apply the lost changes. For this reason, RMAN does not allow Oracle DBA to back up a database that has been running in NOARCHIVELOG mode and shut down abnormally because the backup is not usable for recovery.
The basic guideline is: if you run your database in NOARCHIVELOG mode, always have a backup that is usable without performing any recovery. This aim is defeated if you need to apply redo from logs to recover a backup.
learn Oracle - Archiving Unarchived Redo Log Files
After an online backup or inconsistent closed backup, always ensure that Oracle DBA have the redo necessary to recover the backup by archiving the unarchived redo logs. When the database is open, run the following SQL statement to force Oracle to switch out of the current log and archive it as well as all other unarchived logs:
ALTER SYSTEM ARCHIVE LOG CURRENT;
When the database is mounted, open, or closed, you can run the following SQL statement to force Oracle to archive all noncurrent redo logs:
ALTER SYSTEM ARCHIVE LOG ALL;
When the database is mounted, open, or closed, Oracle DBA can run the following SQL statement to archive a specific group, where integer is the number of the group:
ALTER SYSTEM ARCHIVE LOG GROUP integer;
Learn Oracle - Backing Up the Archived Logs and the Control File
After open or inconsistent closed backups, Oracle recommends backing up all archived logs produced during the backup, and then backing up the control file after the backup completes. If you do not have all archived redo logs produced during the backup, then you cannot recover the backup because you do not have all the redo records necessary to make it consistent. Having a control file backup generated after the completion of the database backup is helpful when using RMAN because the control file contains a record of the backup (in V$BACKUP_SET).
Back to Top
