Database Reference
In-Depth Information
Assume that T is possibly one of the transactions in progress. So the log records
for T will be on the log file in the interval from the most recent checkpoint to the
end of the file. The log records for T will be among the records the recovery system
will examine for recovery. It will take action based on the log records for T using
the logic indicated below:
CASE 1:
Both (T,BEGIN) and (T,COMMIT) are present on the log
Failure occurred after all log records were written.
Cannot be sure whether all database updates were completed.
However, the log file contains all records for T.
So the log records for T can be used to update the database.
USE LOG RECORDS TO UPDATE DATABASE WITH AFTER
IMAGE VALUES. DATABASE BROUGHT TO NEW CONSIS
TENT STATE.
CASE 2:
(T,BEGIN) is present but (T,COMMIT) is not present on the log.
Cannot be sure exactly when failure occurred.
Failure could have occurred before updating B or both B and A.
Cannot be sure whether all log records are written.
However, available log records may be used to undo any database
updates.
USE AVAILABLE LOG RECORDS TO UNDO DATABASE
UPDATES WITH BEFORE-IMAGE VALUES.
DATABASE STAYS IN PRIOR CONSISTENT STATE.
Shadow Paging
The log-based recovery techniques, however effective, come with some substantial
overhead. The DBMS must maintain log files. Depending on the circumstances of
the failure, the recovery process can be long and difficult. Shadow paging is an alter-
native technique for database recovery. This technique does not require log files,
nor is this recovery process as long and difficult as that of log-based techniques.
However, it is not easy to extend shadow paging to an environment with concur-
rent transaction processing. Still, shadow paging has its use under proper circum-
stances. We will quickly review the concepts of shadow paging. A detailed discussion
is not within our scope here.
The underlying principle in shadow paging is the consideration of the database
as a set of fixed-size disk pages or blocks. A directory or page table is created to
point to database pages. If the database has n pages, the directory has n entries.
Directory entry number 1 points to the first database page, entry number 30 points
to the 30th database page, entry number 75 points to the 75th database page, and
so on. Unless the directory is too large, the directory is kept in main memory during
transaction processing. All database reads and writes pass through the directory.
During the life of a transaction, two directories are maintained, the current page
table or current directory and the shadow page table or shadow directory. The
current directory points to the current set of database pages.
Search WWH ::




Custom Search