Backing Up a NOARCHIVELOG Database

If you operate your database in NOARCHIVELOG mode, Oracle does not archive filled groups of online redo log files. Therefore, the only protection against a disk failure is the most recent whole backup of the database.

Plan to make whole database backups regularly, according to the amount of work that you can afford to lose.

Whenever you alter the physical structure of a database operating in NOARCHIVELOG mode, immediately take a consistent whole database backup. A whole database backup fully reflects the new structure of the database.

Backing Up an ARCHIVELOG Database

Perform a whole database backup of the entire database after you create it. This initial whole database backup is the foundation of your backups because it provides backups of all datafiles and the control file of the associated database.

Make open database or tablespace backups to keep your database backups up-to-date.

.In particular, back up the datafiles of extensively used tablespaces frequently to reduce database recovery time.

Make a control file backup every time you make a structural change to the database. If you are operating in ARCHIVELOG mode and the database is open, use either RMAN or the ALTER DATABASE statement with the BACKUP CONTROLFILE option.

Performing Backups When You Make Structural Changes

Administrators as well as users make changes to a database. If you make any of the following structural changes, then perform a backup of the appropriate portion of your database immediately before and after completing the alteration:

• Create or drop a tablespace.
• Add or rename a datafile in an existing tablespace.
• Add, rename, or drop an online redo log group or member.

The part of the database that you should back up depends on your archiving mode:

Backing Up Often-Used Tablespaces

Many administrators find that regular whole database backups are not in themselves sufficient for a robust backup strategy. If you run in ARCHIVELOG mode, then you can back up the datafiles of an individual tablespace or even a single datafile. This option is useful if a portion of a database is used more extensively than others, for example, the SYSTEM tablespace and tablespaces that contain rollback segments.

By making more frequent backups of the extensively used datafiles of a database, you avoid a long recovery time. For example, you may make a whole database backup once a week on Sunday.

Performing Backups After Unrecoverable/Unlogged Operations

If users are creating tables or indexes using the UNRECOVERABLE option, make backups after the objects are created. When tables and indexes are created as UNRECOVERABLE, Oracle does not log redo data, which means that you cannot recover these objects from existing backups.

Performing Whole Database Backups After Opening with the RESETLOGS Option

After you have opened a database with the RESETLOGS option, Oracle recommends that you immediately perform a whole database backup. If you do not, and a disaster occurs, then you lose all changes made after opening the database.

After you open the database with the RESETLOGS option, you cannot use existing backups for subsequent recovery beyond the time when the logs were reset. You should therefore shut down the database and make a consistent whole database backup. Doing so will enable recovery of database changes after using the RESETLOGS option.

Exporting Data for Added Protection and Flexibility

Because the Oracle Export utility can selectively export specific objects, consider exporting portions or all of a database for supplemental protection and flexibility in a database's backup strategy. This strategy is especially useful for recovery catalog backups when using RMAN.

Avoiding the Backup of Online Redo Logs

Although it may seem that you should back up online redo logs along with the datafiles and control file, this technique is dangerous. You should not back up online redo logs for the following reasons:

• The best method for protecting the online logs against media failure is by multiplexing them, that is, having multiple log members per group, on different disks and disk controllers.
• If your database is in ARCHIVELOG mode, then ARCn is already archiving the redo logs.
• If your database is in NOARCHIVELOG mode, then the only type of backups that you should perform are closed, consistent, whole database backups. The files in this type of backup are all consistent and do not need recovery, so the online logs are not needed.

The danger in backing up online redo logs is that you may accidentally restore them while not intending to, thus overwriting the current logs with the older, useless backups. This action forces you to perform an incomplete recovery instead of the intended complete recovery, thereby losing the ability to recover valuable transactions contained in the overwritten redo logs.