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.

Database export in oracle 11g

• Database export
You can use Oracle's export utility to supplement a full backup. If changes are made to a known set of data objects between full backups, you can export the objects.
However, the export utility should only be used on data objects that are not changing during the export and on all data objects that are closely related. For example, if you use export to back up a business table, you should also capture the related spatial index, feature, and delta tables in the same backup.
ESRI does not recommend that you use the export utility as your only backup method.
You can also back up the entire Oracle database with the Oracle export utility, then make cumulative and incremental backups.
For more information on the export utility, refer to the Oracle utilities manual for your Oracle release.

You should make regular full backups of the Oracle database. A full backup should include the Oracle database, control files, data files, redo log files, and, if you have started an ArcSDE service, the giomgr.defs, dbinit.sde, and services.sde files.

If your Oracle database is operating under ARCHIVELOG mode, you can add several variations to your backup strategy in addition to the periodic full backup. Databases operating under the NOARCHIVELOG mode are restricted to full backups with the possible addition of Oracle export files.

You should make at least three copies of the control files with each backup because of their importance in ensuring database consistency. Because control files are comparatively small, there is negligible cost in doing so.

The redo log files are essential for bringing the data files from an earlier state to a later state. Between any two points in time, the redo logs must be found in an unbroken sequence if database recovery is to succeed.

ESRI recommends that you maintain at least two copies of all archived redo logs for as far back in time as may be reasonably necessary for database recovery. The two copies should be stored on physically distinct media-separate disk drives, for example, or a disk drive and a tape drive.

If you intend to purge the archived redo log files from their location on disk, be sure that you have a second backup copy of each archived redo log file before purging.

This strategy of multiple backups of the archived redo log files helps guard against multiple media failure, which is not as rare as it might seem. Some tape drives, for example, fail to detect bit errors until you attempt to restore a file, when it may be too late.

You only need to make a single copy of each data file with each backup as long as you carefully maintain multiple copies of archived redo logs.

NOTE: The online redo log files are not necessary for backup. If the current online redo log file fails, committed information still exists in memory, which Oracle writes to the data files when a checkpoint is issued. Oracle issues a checkpoint automatically when you shut down a database instance with NORMAL, IMMEDIATE, or TRANSACTIONAL priority. Before shutting down a database with ABORT priority, you should force a checkpoint with the ALTER SYSTEM > CHECKPOINT command if at all possible.

Hot and Cold backup in oracle 11g

• Hot backup

Backing up an Oracle database while the database instance is running is a hot backup. If you plan to perform a hot backup, you must operate your database in ARCHIVELOG mode.
Enter the ALTER TABLESPACE > BEGIN BACKUP command prior to the backup of each tablespace; this tells Oracle that a hot backup is being performed. If this command is not issued, the hot backup appears to succeed but may be useless for restoring the database. To finish the hot backup, for each tablespace, enter the ALTER TABLESPACE > END BACKUP command.
Changes to data are recorded and held in the rollback segment until they are no longer needed by any outstanding transaction. Taking a hot backup prevents the release of rollback segment data until the ALTER TABLESPACE … END BACKUP command is issued. Therefore, the rollback segment must be large enough to accommodate changes made during the hot backup. If the rollback segment runs out of space, a transaction will fail with an ORA-1555 error:

ORA-1555: snapshot too old (rollback segment too small) 



While the hot backup succeeds despite this error, changes made to the database may need to be reentered.
You can avoid this error by performing a hot backup during times of low database activity or by ensuring that your rollback segments are large enough to accommodate data changes made during backup.
You do not need to shut down the ArcSDE server process (giomgr) prior to making a hot backup.
For details on hot backup, refer to the Oracle Backup and Recovery Guide for your Oracle release.
• Cold backup
Creating a backup of an Oracle database while the database instance is shut down is a cold backup. Managing a cold backup is simpler than a hot backup and less prone to error.
If you run the database in NOARCHIVELOG mode, a cold backup is your only option. Running the database in ARCHIVELOG mode enables you to use a cold backup to recover a database to the latest committed transaction.