The difference between consistent and inconsistent backups is simple. A consistent backup doesn’t
need to go through a recovery process. When a backup is used to recover a database or a part of a
database (such as a tablespace or a datafile), first you need to restore the backup, and then you recover the database. In the case of a consistent backup, you don’t have to perform any recovery steps.
An inconsistent backup, on the other hand, always needs to undergo a recovery.
Oracle assigns every transaction a unique system change number (SCN). Each commit, for
example, will advance the SCN forward. Each time Oracle performs a checkpoint, all the changed
data in the online datafiles is written to disk. And each time there is a checkpoint, the thread checkpoint in the control file is updated by Oracle.
During this thread checkpoint, Oracle makes all the read/write datafiles and the control files consistent to the same SCN.
A consistent database means that the SCNs stored in all the datafile headers are identical and are also the same as the datafile header information held in the control files. The important thing is that the same SCN number must appear in all the datafiles and the control file(s). The identical SCN means that the datafiles contain data taken from the same point in time. Since the data is consistent, you don’t need to perform any recovery steps after you restore (or copy back) a set of backup files.
To make a consistent backup, either the database needs to be closed (with a normal SHUTDOWN or
SHUTDOWN TRANSACTIONAL command, not a SHUTDOWN ABORT command) or it needs to be in a mount position after being started (again, after a clean shutdown).
An inconsistent backup is a backup in which the files contain data from different points in time.
Most production systems can’t be shut down for a consistent backup. Instead, you need to operate
those databases on a 24/7 basis. You thus must back up the datafiles of these databases online; that
is, while the database is open for transactions. Since the datafiles are being modified by users while
you are backing them up, you end up with an inconsistent backup. Inconsistent backups don’t mean
there is anything wrong with your backups. However, during a recovery process, it isn’t sufficient to
merely restore these backups. In addition to restoring these backups, you must also supply all archived and online redo logs from the time of the backup to the time to which you want to recover the database. Oracle will read these log files and apply all necessary changes to the restored backup files. Since you can make an inconsistent backup of a database while it’s open, most production databases use inconsistent backups as the foundation of their backup strategy.
Backup Levels
Following are the levels at which you can perform Oracle database backups:
need to go through a recovery process. When a backup is used to recover a database or a part of a
database (such as a tablespace or a datafile), first you need to restore the backup, and then you recover the database. In the case of a consistent backup, you don’t have to perform any recovery steps.
An inconsistent backup, on the other hand, always needs to undergo a recovery.
Oracle assigns every transaction a unique system change number (SCN). Each commit, for
example, will advance the SCN forward. Each time Oracle performs a checkpoint, all the changed
data in the online datafiles is written to disk. And each time there is a checkpoint, the thread checkpoint in the control file is updated by Oracle.
During this thread checkpoint, Oracle makes all the read/write datafiles and the control files consistent to the same SCN.
A consistent database means that the SCNs stored in all the datafile headers are identical and are also the same as the datafile header information held in the control files. The important thing is that the same SCN number must appear in all the datafiles and the control file(s). The identical SCN means that the datafiles contain data taken from the same point in time. Since the data is consistent, you don’t need to perform any recovery steps after you restore (or copy back) a set of backup files.
To make a consistent backup, either the database needs to be closed (with a normal SHUTDOWN or
SHUTDOWN TRANSACTIONAL command, not a SHUTDOWN ABORT command) or it needs to be in a mount position after being started (again, after a clean shutdown).
An inconsistent backup is a backup in which the files contain data from different points in time.
Most production systems can’t be shut down for a consistent backup. Instead, you need to operate
those databases on a 24/7 basis. You thus must back up the datafiles of these databases online; that
is, while the database is open for transactions. Since the datafiles are being modified by users while
you are backing them up, you end up with an inconsistent backup. Inconsistent backups don’t mean
there is anything wrong with your backups. However, during a recovery process, it isn’t sufficient to
merely restore these backups. In addition to restoring these backups, you must also supply all archived and online redo logs from the time of the backup to the time to which you want to recover the database. Oracle will read these log files and apply all necessary changes to the restored backup files. Since you can make an inconsistent backup of a database while it’s open, most production databases use inconsistent backups as the foundation of their backup strategy.
Backup Levels
Following are the levels at which you can perform Oracle database backups:
- Whole database: You back up all files including the control file. This level is applicable to both archivelog and noarchivelog modes of operation.
- Tablespace backups: You back up all the datafiles belonging to a tablespace. Tablespace backups are applicable only in archivelog mode.
- Datafile backups: You back up a single datafile. Datafile backups are valid in archivelog mode only.
No comments:
Post a Comment