0074-0076

Previous Table of Contents Next

Page 74

Again, no manual intervention is required in all but the most serious cases. The database administrators of the instances involved in the distributed transaction can manually force the commit or rollback of the changes on their databases, but I recommend that you leave the recovery to the RECO background process if possible. This might not be possible if the links between the databases are not available for the RECO processes on all the instances to communicate.

Disk Failure/File Loss

The only time you really need to concern yourself with recovery is when you lose one or more of the files making up the databasethe database files themselves , the control file, and the redo logs. Some type of manual recovery is necessary.

If you lose one or more of the files (database, redo, control), you have available the options highlighted in the following sections. In every situation, you must work with a previous backup of the database.

Cold Backup

A cold backup is when you copy the three sets of files (database files, redo logs, and control file) when the instance is shut down. This is a straight file copy, usually from the disk directly to tape. You must shut down the instance to guarantee a consistent copy. (It is possible to back up the files without bringing the instance down; see the section titled "Hot Backups .")

If you only perform a cold backup, the only option available in the event of data file loss is restoring all the files from the latest backup. All work performed on the database since the last backup is lost.

Archiving

If you've set up the database to run in Archive Log mode (easily done by the DBA), the database changes recorded in the redo logs are archived to an archive destination whenever the redo logs fill. Using this option, you have a complete record of changes made to the database files in the offline and online redo log files.

If you lose one or more of the database files, you could restore them from the last backup and reapply the changes since the last backup from the online and offline redo log files. You must have some kind of backup of the files and the complete set of online and offline redo logs from which to reapply all the changes made to the database.

With the archiving option, you lose no changes in the database if the complete set of redo logs is available. All the changes committed before the file was lost are reapplied. It is also possible to perform recovery if the control or redo log files are lost.

Hot Backups

Some sites (such as worldwide airline reservations systems) cannot shut down the database while making a backup copy of the files. The cold backup is not an available option.

Page 75

You can use a different means of backing up your databasethe hot backup. Issue a SQL command to indicate to Oracle, on a tablespace-by-tablespace basis, that you want to back up the files of the tablespace. The users can continue to make full use of the files, including making changes to the data. Once you have indicated that you want to back up the tablespace files, you can use your operating system to copy those files to your backup destination.

The database must be running in Archive Log mode for the hot backup option.

If a data loss failure does occur, you can restore the lost database files using the hot backup and the online and offline redo logs created since the backup was done. The database is restored to the most consistent state without any loss of committed transactions.

Backup Catalog

The Oracle Backup and Recovery Manager tool (which comes as part of Enterprise Manager) maintains a backup and recovery catalog which contains information to allow (nearly) automatic backup and recovery operations.

The catalog contains the following information:

• Information about when datafiles were backed up and recovered
• Information about the archived redo logs
• Information on the physical structure of the database

The catalog is maintained automatically by the Backup and Recovery Manager in a set of Oracle database tables. Another database (other than the one being backed up) should be used to store the recovery catalog. This database in turn should be backed up.

If all else fails, information in the control file can still be used to recover the database.

The recovery catalog reduces much of the human-risk element in performing backup and recovery operations.

Incremental Backups

One of the problems with large databases is the time taken to back up and restore the database files. If an operating system copy of the database files is taken for a large database, the backup (and recovery operations) can take many hours.

In Oracle8, incremental backups can be performed that will back up only those Oracle blocks that have changed since the last backup. The DBA has options to specify which blocks are backed up in this incremental approachfor example, those since the last full monthly backup, those since the last weekly backup, and those since the last daily backup.

Using incremental backups reduces the time taken to back up and restore a large database. However, for small databases, where backup time is less relevant than the integrity of the database, a full database backup would be simpler and easier to perform.

Page 76

Export and Import

Along with the RDBMS software, Oracle provides two utilities that you can use to back up and restore the database. These utilities are useful to database administrators for system-wide backups and recoveries and also application developers for temporary backups of their own data and object recovery into their own user accounts.

The Export utility dumps the definitions and data for the specified part of the database to an operating system binary file. The Import utility reads the file produced by an export, re-creates the definitions of objects, and inserts the data.

For a full database import, you must have an existing template database already created.

If you use Export and Import as a means of backing up and recovering the database, you cannot recover all the changes made to the database since the export was performed. This is similar to the situation with the cold backup. The best you can do is recover the database to the time when the export was last performed.

On large, data-filled databases, the Export and Import utilities can take a long time to run; many hours is not unusual. However, the utilities do provide an option to selectively export and import different user accounts and even objects within an Oracle user account.

Multiplexing

In this part, I discuss the options available for Oracle to duplicate data to provide an extra level of protection in the event of data loss.

Control Files

To protect against control file loss, the Oracle RDBMS software can maintain more than one copy of the control file. You do this by making a consistent copy of the existing control file and modifying an INIT.ORA parameter. This does not significantly impact the performance of the database. If all copies of the control file are lost, you can manually re-create them using the CREATE CONTROLFILE command.

Redo Logs

Redo logs record all the changes made to data blocks on the database. If the database is running in Archive Log mode and only the offline redo logs are lost, you should shut down the database and make another backup of the three sets of files for the database.

If the online redo logs are lost, however, you could lose some work because some of the information required to reapply changes to the database files is in the online redo log files. To guard against this, you can multiplex (mirror) the online redo log files in the same way as the control files. When the RDBMS software writes changes to one redo log, the exact same information is written to an exact copy of the redo log.

Previous Table of Contents Next