基于表空时间点的恢复和不完全恢复…

文档地址：http://docs.oracle.com/cd/B19306_01/server.102/b14220/backrec.htm#sthref2355

Incomplete Recovery

Incomplete recovery, or point-in-time recovery, uses a backup to produce a noncurrent version of the database.---

这两者的备份是两个不同备份。

 In other words, you do not apply all of the redo records generated after the most recent backup. You usually perform incomplete recovery of the whole database in the following situations:

• Media failure destroys some or all of the online redo logs.

• A user error causes data loss, for example, a user inadvertently drops a table.

• You cannot perform complete recovery because an archived redo log is missing.

• You lose your current control file and must use a backup control file to open the database.

To perform incomplete media recovery, you must restore all datafiles from backups created prior to the time to which you want to recover and then open the database with the RESETLOGS option when recovery completes. The RESETLOGS operation creates a new incarnation of the database—in other words, a database with a new stream of log sequence numbers starting with log sequence 1.

Before using the OPEN RESETLOGS command to open the database in read/write mode after an incomplete recovery, it is a good idea to first open the database in read-only mode, and inspect the data to make sure that the database was recovered to the correct point. If the recovery was done to the wrong point, then it is easier to re-run the recovery if no OPEN RESETLOGS has been done. If you open the database read-only and discover that not enough recovery was done, then just run the recovery again to the desired time. If you discover that too much recovery was done, then you must restore the database again and re-run the recovery.

Tablespace Point-in-Time Recovery--基于表空间时间点的恢复

The tablespace point-in-time recovery (TSPITR) feature lets you recover one or more tablespaces to a point in time that is different from the rest of the database.

TSPITR is most useful when you want to:

• Recover from an erroneous drop or truncate table operation

• Recover a table that has become logically corrupted

• Recover from an incorrect batch job or other DML statement that has affected only a subset of the database

• Recover one independent schema to a point different from the rest of a physical database (in cases where there are multiple independent schemas in separate tablespaces of one physical database)

• Recover a tablespace on a very large database (VLDB) rather than restore the whole database from a backup and perform a complete database roll-forward

TSPITR has the following limitations:

• You cannot use it on the SYSTEM tablespace, an UNDO tablespace, or any tablespace that contains rollback segments.

• Tablespaces that contain interdependent data must be recovered together. For example, if two tables are in separate tablespaces and have a foreign key relationship, then both tablespaces must be recovered at the same time; you cannot recover just one of them. Oracle can enforce this limitation when it detects data relationships that have been explicitly declared with database constraints. There could be other data relationships that are not declared with database constraints. Oracle cannot detect these, and the DBA must be careful to always restore a consistent set of tablespaces.

文档地址：http://docs.oracle.com/cd/B19306_01/backup.102/b14192/flashptr001.htm#sthref596

7.1.1 About Database Point-in-Time Recovery

Database point-in-time recovery (DBPITR) is a process that works at the physical level to return the datafiles to their state at a desired target time in the past. In an RMAN DBPITR operation, you specify a target point in time, and RMAN restores the database from backups prior to that time, and then applies incremental backups and performs media recovery to recreate all changes between the time of the datafile backups and the target time. If your backup strategy is properly designed and your database is running in ARCHIVELOG mode then DBPITR is an option in nearly all circumstances.

---从官方文档的描述来看，这个数据库基于时间点的恢复就是一个不完全恢复，一个类似:

Recover database until time ''; 基于时间点的不完全恢复。

（Point-in-Time:时间点）

RMAN simplifies DBPITR greatly compared to user-managed DBPITR. Given a target SCN, datafiles are restored from backup and recovered efficiently using incremental backups and archived logs available on disk or tape, with no intervention from the user. However, there are some disadvantages to point-in-time recovery:

• You cannot return only selected objects to their earlier state, only the entire database.

• Your entire database is unavailable during the database point-in-time recovery process.

• Point-in-time recovery can be time-consuming, because all datafiles must be restored, and redo logs and incremental backups must be restored from backup and used to recover the datafiles. If needed backups are on tape, this process can take even longer.