Database Reference
In-Depth Information
Performing User-Based
Incomplete Recoveries
Incomplete recovery (also called point-in-time recovery ) is the process of recovering the
database to a different point in time than the most current point in time. Why would one
do such a thing, you ask? There may be a number of reasons:
Loss of one of the online redo log groups, making full recovery impossible
User error requiring a recovery of the database to a different point in time
Creation of a duplicate database to a point in time other than that of the source database
In the following sections, we will cover the basics of incomplete recovery. First, we will
discuss the requirements for and mechanics of incomplete recovery, and then we will cover
preparation for incomplete recovery. Finally, we will walk through the process of an actual
incomplete recovery.
Requirements for and Mechanics of an
Incomplete Recovery
The requirements for incomplete recovery are much like those of a complete recovery from
an online backup. First, the database must be in ARCHIVELOG mode. Second, you have to
have a backup of the database (online or offline) and all of the archived redo logs required
to get your database to the point in time that you are interested in.
Preparing for an Incomplete Recovery
The first step in performing an incomplete recovery is to restore the database from a
backup that was taken before the point in time to which you want to restore the database.
Notice that you have to restore the entire database. This can sometimes confuse less-
experienced DBAs. With incomplete recovery, you must restore the entire database, and it
must be restored to a point in time before the point in time that you wish to recover to.
For example, suppose it's 2:00 p.m. and you wish to recover just the USERS tablespace
objects to 1:00 p.m. because someone messed something up. To do so, it's not just as simple
as restoring the USERS tablespace data files to 1:00 p.m. You have to restore the entire data-
base to 1:00 p.m.
Oracle is persnickety about data file consistency. Recall the concept of the SCN, which is
Oracle's internal counter for all operations. When you do an insert, it is assigned an SCN.
When you then commit that insert, it is assigned a different, higher SCN. This way, Oracle
knows the insert came first and the commit came second.
When you start the Oracle Database, it's a demanding bit of software. It requires that the
SCN in each data file be the same before it will open the database (there is an exception to this
Search WWH ::




Custom Search