Database Reference
In-Depth Information
Complete versus incomplete recovery
The scope of the recovery can either be full or partial. The latter is also known as incomplete recovery, or point in time
recovery. A full recovery, as the name suggests, is applied when media failure has rendered a mount point unusable.
The reasons for this are manifold, failure of a SAN switch or logical corruption on the file system level can cause a
file system to be downgraded to “read-only” mode at best, or automatically dismounted at worst. In any case, the
database will not be able to write to its files, causing it to crash.
If all information required for a full recovery is available you can restore the files on the lost mountpoint to
another file system with sufficient free space and fully recover the database. A full recovery ends with the command to
open the database, not specifying the resetlogs clause.
An incomplete recovery on the other hand is required in situations where for example a software release has
gone badly wrong and the Flashback Database feature has not been enabled, rendering the feature unavailable.
Another situation requiring a full recovery is the user error or a bug in the application using the database to store and
retrieve data. In some circumstances it is impossible to create a fix for the logical corruption, and the database must
be restored to a point in time prior to the failure.
The database incarnation
Whenever you open the database with the resetlogs option it creates a new incarnation. An incarnation as per
the Oracle documentation is a separate version of the database. The original incarnation of each new database
is incarnation 1, and others are added as and when needed. Using Recovery Manager it is possible to list the
incarnations of a database:
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 CDB2 573673282 PARENT 1720082 20.09.2013 09:39
2 2 CDB2 573673282 CURRENT 1764438 20.09.2013 10:24
The resetlogs system change number is tracked with every incarnation, as is the date. It is important to understand
that the counter for the sequence numbers in Oracle online log files is reset with each incarnation. This posed a
serious problem up to Oracle 10g when the new archived redo logs could potentially overwrite archivelogs with the
same sequence number but from an earlier incarnation. Unless you decide otherwise Oracle will now include the
resetlogs change number in the format for the archived redo logs, avoiding the problem. Also beginning with Oracle
10 it became possible to recover across the resetlogs statements, a feature which relied on the inclusion of the
resetlogs change number in the archived log file name.
The Fast Recovery Area
The Fast Recovery Area or FRA is one of the greatest additions to the Oracle database over the last years. Although it
started its existence as Flash Recovery Area Oracle renamed it in 11g to avoid further confusion with other technology
using “flash” in its name. The recovery area is a central location for many backup related files, such as:
•
Archived redo logs
•
Backup piece
•
Image copy
•
Flashback log
Search WWH ::
Custom Search