Backup Types in oracle 11G

An Oracle database offers several types of backups. We summarize the main types of backups in the following sections.

Physical and Logical Backups

· Physical backup: Copy physical database files using os commands.

· Logical Backup: Backup using exp-imp or Data-Pump utility

Whole and Partial Backups

· A whole-backup of a database is the backup of the entire database; A whole-database backup includes all the datafiles plus the control files.
· A partial backup refers to backups of a tablespace or datafile in a database. You can also back up the control file just by itself by making either a text or a binary copy of it.

Online and Offline Backups

· An offline backup, also called a cold backup, is one made after shutting down the database using the shutdown command or the shutdown command with the immediate or transactional clause.

· An offline backup, provided you make one after the database is shut down gracefully, is always consistent, whether you’re operating in archivelog or noarchivelog mode.

· When making an offline backup with RMAN, you must, however, start the database you want to back up in the mount mode.

· An online backup, also called a hot or warm backup, is one made while the database instance is still open. By definition, an online backup is always inconsistent.

· During a recovery, the application of the necessary archived redo logs will make the backup consistent. Thus, you can make online backups of any database you’re operating, and the resulting inconsistent backups can be made consistent with the application of archived redo logs.

Full and Incremental Backup

· A full backup of a database will contain complete backups of all the datafiles.

· Incremental backups contain only the changed data blocks in the datafiles.You can make incremental backups only with the help of RMAN—you can’t make incremental backups using user-managed backup techniques.

Concept of SCN and Consistent/Inconsistent Backups

· To understand the crucial difference between consistent and inconsistent backups, you must first understand the concept of the system change number (SCN).

System change number (SCN)

· The SCN is an Oracle server–assigned number that indicates a committed version of the database. It’s quite possible that different datafiles in the database might have a different SCN at any given point in time.

· If the SCNs across all the datafiles are synchronized, it means that the data across the datafiles comes from a single point of time and, thus, is consistent.

· During each checkpoint, the server makes all database file SCNs consistent with respect to an identical SCN.In addition, it updates the control file with that SCN information.

· This synchronization of the SCNs gives you a consistent backup of your database. Not only does each of the datafiles in the database have the same SCN, it must also not contain any database changes beyond that common SCN.

Consistent and Inconsistent Backups

· If you back up your database while it’s running, you may end up with backups of the various datafiles at various time points and different SCNs. This means your backups are inconsistent, since the SCNs aren’t identical across all the datafiles.

· If you’re operating the database in noarchivelog mode, you can use only consistent backups to restore your database.

· If you’re operating in archivelog mode, however, you can use consistent or inconsistent backups to restore the database.

· If you’re using a consistent backup, you can open a whole-database backup without recovery and without using the open resetlogs command.

· If you’re using inconsistent backups, however, you must use archived redo logs to make the data current and synchronize the SCNs across the datafiles.

· The key fact here is that the recovery process will make your inconsistent backups consistent again by using the data from the archived redo logs and the online redo log files to apply

· All the necessary changes across the datafiles to make them all consistent with reference to a single SCN.

· If you’re running the database in noarchivelog mode, the recommended approach to backing up the database is to shut down the database cleanly first and then to back up all the datafiles.

· If you’re using RMAN to perform an offline backup, the database must be mounted before you can actually perform the RMAN backup. This is because RMAN needs to update the target database control file.

· If you’re running the database in archivelog mode, you can back up a whole database in any of the following ways:

· Closed and consistent
· Closed and inconsistent
· Open and inconsistent

The ability to back up a database while it is open and in use is a key benefit of running a database in archivelog mode.

The only part of the database that is not backed up using RMAN is the "Online Redo Log" files: these are protected by multiplexing.