[Laskey99] Section 4.3. Database Recovery

来源:百度文库 编辑:神马文学网 时间:2024/10/02 18:06:28

4.3.

The whole purpose of backups is to be able to recover the database.This section discusses the various reasons why you may need toperform a recovery and provides an overview of the new tablespacepoint-in-time recovery process.

4.3.1. Recovery Scenarios

Thefollowing sections briefly describe how you can recover fromdifferent types of failure.

4.3.1.1. System failure

A system failure means that the entiresystem is unavailable. A failure of this kind may be the result ofeither a site outage (caused by fire or natural disaster) or a totalfailure of the server.

It is standard practice to have at least two copies of your backup tapes, with one copy stored at a different location. This way, you not only do not have a single point of failure if the tape containing your archive file breaks, but you also are able to get at your tapes in the event of a disaster. Even storing a single copy of your tapes in a fireproof vault will not work if you cannot cross a police line after an explosion.


In the case of a system failure, you have three options:

  • Recover the entire database from a cold backup.

  • Recover the entire database from hot or cold backups and apply as many archive files as you have available.

  • Recover the entire database from exports using full, cumulative, and incremental exports.

4.3.1.2. Disk failure

A disk failure is the most common formof database failure. With the cost of RAID solutions (includingmirroring and parity solutions such as RAID-1 and RAID-5) comingdown, most sites have moved to a hardware solution to prevent asingle disk failure from impacting the database. If your site doesnot use these solutions, then at some point in your career you willhave to perform a recovery from a disk failure.

We recommend multiple control files, separate disks for archivefiles, and mirroring redo logs either with redo log groups oroperating system mirroring. With mirrored redo logs and multiplecontrol files on separate disks, no single disk failure will cause aloss of the database. If you have only one control file or only oneredo member per group, then losing the disk containing the controlfile or the active redo log would be catastrophic to the database.Placing archive files on a separate disk from the redo logs (ifmirroring is not used) at least ensures that you can recover thedatabase up to the point of the last archive file.

In the case of a disk failure, you have the following options:

  • Restore the datafile to a new disk, rename it using the ALTER DATABASE RENAME DATAFILE command, and recover the file using archive files and online redo logs.

  • If you are not running in archivelog mode, you can still use the tablespace point-in-time recovery procedure from a cold backup.

  • Recover the entire database using a cold backup.

  • Place the tablespace containing the missing datafiles offline using the ALTER TABLESPACE OFFLINE TEMPORARY command; then drop the tablespace. Recreate the tablespace and restore the contents from previous exports.

  • Recover the entire database from exports using full, cumulative, and incremental exports.

4.3.1.3. Database corruption

With datacorruption, the internal structure of the database is inconsistent.Data corruption is usually caused by a hardware failure or an anomalyin the Oracle software. This will manifest itself in any number ofOracle error messages. Most likely you will be able to identify theactual database block that is corrupt. Your options for recoverydepend on the kind of information stored in that location:


Table data

You should be able to salvage rows fromblocks that are not corrupt by copying them over to another table andthen dropping the table. It may be necessary to exclude rows usingunique keys or ROWIDs. Alternately, you may have to perform datafileor database recovery.


Index

Youcan drop and recreate the index.


Data dictionary

You will have to either recoverthe SYSTEM tablespace using media recovery or recreate the databaseand recover using full, cumulative, and incremental exports.


Rollback segments

If there are uncommittedtransactions, you will have to perform datafile or tablespacerecovery.

4.3.1.4. Data corruption

Data corruption occurs when the structure of the database is intactbut the data is not. This situation is caused by incorrect oraccidental SQL statements being executed and committed. In this case,you have the following options:

  • Restore the incorrect table or tables from the most recent export. Take care to ensure that referential integrity is maintained.

  • Restore the tablespace (in Oracle8), using the tablespace point-in-time recovery process, to just prior to the data corruption. Of course, changes to any other tables in that tablespace made after the recovery point will be lost.

  • Recover the entire database to a time prior to the data corruption, using either hot or cold backups.

4.3.2. Tablespace Point-in-Time Recovery

Tablespace point-in-time recovery isa new feature implemented with Oracle8. With tablespace point-in-timerecovery, you are able to recover one or more tablespaces to a pointin the past, independent of the other tablespaces. The tablespaces tobe restored are referred to as the recoveryset.However, note that the SYSTEM tablespace cannot be recovered usingtablespace point-in-time recovery.

4.3.2.1. Overview of the process

To perform tablespace point-in-time recovery, follow these steps.Please refer to the Oracle8 Backup and RecoveryGuide for a more detailed set of directions.

  1. Identify any objects in the original database that may be impacted by the tablespace point-in-time recovery. This will include any dependent objects, tables with referential integrity, and indexes and objects created after the point-in-time recovery time. The various constraints will have to be removed prior to tablespace point-in-time recovery.

  2. Create a second, or clone, database. Using hot or cold backups, restore the datafiles to the clone database. Normally, you will only need the datafiles corresponding to the SYSTEM tablespace, the rollback segments, any temporary tablespaces, and the tablespace containing the tables to be recovered. If necessary, use archive files to roll forward the tablespaces to the desired point.

  3. Mount the clone database using the ALTER DATABASE MOUNT CLONE DATABASE command.

  4. Use the Export utility to export metadata about the objects in the tablespaces to be recovered.

  5. Alter the original database to rename the datafiles to the recovered tablespace datafiles.

  6. Input this special export. All objects in the tablespaces are effectively dropped and recreated.

  7. Delete the remaining datafiles in the clone database.

4.3.2.2. Benefits

With tablespace point-in-time recovery, you have the ability torecover specific tables to a previous point without having to rollback the entire database. This form of recovery is likely to takeless time than recovering the entire database to the specific pointor recovering a large table from exports.

4.3.2.3. Limitations

As implied by the name tablespace point-in-time recovery, all tablesin the tablespace will be recovered—you cannot recover just onetable. Therefore, you have to have sufficient disk space and memoryto run the original and clone databases. Any objects in the recoveredtablespaces created after the point-in-time recovery time will bedropped.

4.3.2.4. Data dictionary views

The following data dictionary views are used by the tablespacepoint-in-time recovery facility:


TS_PITR_CHECK

Identifies objects that will be impacted by the tablespacepoint-in-time recovery. As long as any items are included in thisview, tablespace point-in-time recovery will fail. To query the view,use the following:

SELECT * FROM SYS.TS_PITR_CHECK 
WHERE (ts1_name INrecovery_set ANDts2_name NOT INrecovery_set) OR
(ts1_name NOT INrecovery_set ANDts2_name INrecovery_set);


TS_PITR_OBJECTS_TO_BE_DROPPED

Lists objects created after the tablespace point-in-time recoverytime. These objects will be dropped as part of the recovery process.You must make a copy of these objects prior to completing tablespacepoint-in-time recovery. If you don't, the information in themwill be lost.

  • Create Bookmark (Key: b)Create Bookmark
  • Create Note or Tag (Key: t)Create Note or Tag
  • Download (Key: d)Download
  • Email This Page (Key: e)Email This Page
  • PrintPrint
  • Html View (Key: h)Html View
  • Zoom Out (Key: -)Zoom Out
  • Zoom In (Key: +)Zoom In
  • Toggle to Full Screen (Key: f)
  • Previous (Key: p)Previous
  • Next (Key: n)Next

Related Content

What Are the Recovery Options?
From: Oracle Security

What Are the Backup Options?
From: Oracle Security

Bigfile Tablespaces
From: Oracle Database 10g Performance Tuning: Tips & Techniques

Redefining Tablespace Containers During Restore
From: DB2® for Solaris™: The Official Guide

Recovery History File (RHF)
From: DB2® for Solaris™: The Official Guide

Dropping Tablespaces
From: Oracle 9i Fundamentals I Exam Cram™ 2 (Exam 1Z0-031)

DBA Backup and Recovery Methods
From: Oracle Database Foundations

Logical Structure of the Database
From: Oracle 9i Fundamentals I Exam Cram™ 2 (Exam 1Z0-031)

Tablespaces and the Structure of the Database
From: Oracle Database 10g: The Complete Reference

Managing Tablespaces and Data Files
From: Oracle 9i Fundamentals I Exam Cram™ 2 (Exam 1Z0-031)