SQL Server

Database Recovery Methods Part 8

Database Recovery Methods Part – 8

Shadow Paging

This recovery system does not need the use of a log in a single user setting. In a multi user setting, a log may be desired for the concurrency control technique. Shadow paging considers the database to be made up of a number of static size disk pages (or disk blocks) like, N (many) for recovery purposes. A directory with N (many) entries is created, where the ith entry points to the ith database page on disk. The directory is saved in main memory when it is not too big, as well as all the references reads or writes to database pages on disk go through it.

At the time when a transaction initiates implementing, the existing directory whose entries point to the most current or update database pages on disk is copied into a shadow directory. The shadow directory is then kept on disk while on other hand the existing directory is castoff by means of the transaction.

At the time when the transaction is implemented, the shadow directory is never altered. As soon as a Write_Item operation is done, a fresh copy of the altered database page is generated, however the old copy of that particular page is not updated. As an alternative, the new page is written somewhere else on some earlier unused disk block. The present directory entry is altered to the point to the new disk block, on other hand the shadow directory is not altered as well as continues to point to the old unchanged disk block. Figure 1.5 exemplifies the perceptions of shadow as well as existing directories. For the page update by means of the transaction, two (2) versions are kept. The old version is referenced by means of the shadow directory, as well as the fresh version by means of the current directory. To make progress from a failure at the time of transaction execution, it is enough to free the altered database pages plus to remove the current directory. The phase of the database before transaction implementation is obtainable with the help of the shadow directory, as well as that state is improved through reinstating the shadow directory. The database hence is resumed to its state previous to the transactions which was executed at the time when the crash happened, in addition to any altered pages is rejected. Committing a transaction agrees to removal the preceding shadow directory. As recovery contains neither undoing nor recreating information items, this method can be considered as a NO – UNDO or NO – REDO method for recovery. In a multi user setting with concurrent transactions, logs as well as checkpoints should be combined into the shadow paging method. One (1) drawback of shadow paging is that the modified database pages alter the location on disk. This creates a difficulty to keep associated database pages close together on disk without composite storing management strategies. In addition, when the directory is big, the difficulty of writing shadow directories to disk as transactions commit is important. An additional difficulty is by what means to manage the garbage gathering at the time of transaction commitments. The old pages referenced by means of the shadow directory which have been updated should be free as well as introduced to a list of free pages for future usage. These pages are no longer needed after the transaction commits. Another issue is that the operation to migrate between current and shadow directories must be implemented as an atomic operation.

Current Directory

(after Updating Pages 3, 4)

1

·

2

·

3

·

4

·

5

·

6

·

DATABASE DISK BLOCK

PAGE 4 (OLD)

PAGE 1

PAGE 5

PAGE 3 (Old)

PAGE 2

PAGE 6

PAGE 3 (NEW)

PAGE 4 (NEW)


Shadow Directory

(Not Updated)

·

1

·

2

·

3

·

4

·

5

·

6

Figure 1.5 An Instance of Shadow Paging.

Database Backup And Recovery From Catastrophic Failures

Up to now, every method that has been discussed still now applies to non – catastrophic failures. A key hypothesis has been that the system log is preserved on the disk as well as is not lost as an outcome of the failure. Likewise, the shadow directory should be kept on disk to permit recovery at the time when shadow paging is used. The recovery methods that have been discussed make usage of the entries in the system log otherwise the shadow directory to recover from failure by means of bringing the database back to a reliable phase.

The recovery manager of a Database Management System (DMBS) should also be prepared to manage maximum number of disastrous failures for an instance disk crashes. The key method castoff to manage these type of crashes is that of database backup. The complete databases as well as the log are from time to time copied onto a low – cost storage medium like magnetic tapes. In the circumstance where this type of disastrous system failure occurs, the up-to-date backup copy can be recovered from the tape to the disk, plus the system can be restarted. To dodge losing all the special effects of transactions which have been implemented as the last backup, it is usual to back up the system log at more repeated intervals than full database backup from time to time copying it to magnetic tape. The system log is typically significantly smaller than the database itself as well as therefore can be backed up more often. As a consequence end users do not lose any transactions they have implemented as the last database backup. Every committed transactions logged in the portion of the system log that has been backed up to tape can have their effect on the database rebuilt. A fresh log is started after every single database backup. Therefore, to recover from disk failure, the database is first reconstructed on disk from its up-to-date backup copy on tape. Next, the effects of every committed transaction whose activities have been logged in the backed – up copies of the system log are recreated.

This will be the last part of the series. Hope readers had found it valuable.

Thanks.

Facebooktwittergoogle_plusredditpinterestlinkedinmail