--%>
Assignment Help - homework help

  Recovery Protocols and Recovery Management

Recovery Protocols:

All participants in a transaction including every component understand and obey the following protocols when operating on recoverable objects:

•    Consistencies lock protocol.
•    The DO-UNDO-REDO paradigm for log records.
•    Write-Ahead-Log protocol (WAL).
•    Two-phase commit protocol.

The consistency lock protocol was examined in the section on lock management. The outstanding protocols are discussed below.

Perhaps the simplest as well as easiest to implement recovery technique is based on the old-master new-master dichotomy common to most batch data processing systems: If the run fails one goes back to the old-master as well as tries again. Miserably this technique doesn’t seem to generalize to concurrent transactions. If numerous transactions concurrently access an object then making a new-master object or returning to the old master may perhaps be inappropriate for the reason that it commits or backs up all updates to the object by all transactions.

It is desirable to be able to commit or else undo updates on a per-transaction basis. Given an action consistent state as well as a collection of in-progress transactions (that is commit not yet executed) one wants to be able to selectively undo a subset of the transactions without affecting the others. Such a facility is called as in-progress transaction backup.

A second shortcoming of versions is that in the event of a media error, one should reconstruct the most recent consistent state. For illustration if a page otherwise collection of pages is lost from non-volatile storage and then they must be reconstructed from some redundant information. Doubly-recording the versions on independent devices are quite costly for large objects. Nevertheless this is the technique used for some small objects such as the warm start file.

Lastly writing a new version of a large database habitually consumes large amounts of storage and bandwidth.

Having abandoned the notion of versions we accept the approach of updating in place as well as of keeping an incremental log of changes to the system state. (Logs are sometimes called audit trails or else journals.)

All action that modifies a recoverable object writes a log record giving the old as well as new value of the updated object. Read operations requirement generate no log records but update operations must record enough information in the log so that given the record at a later time the operation can be completely undone or redone. These records will be aggregated by transaction as well as collected in a common system log that resides in non-volatile storage. The system log is duplexed as well as has independent failure modes.

In what follows we suppose that the log never fails. By duplexing, triplexing, …., one can make this assumption less false.

Every recoverable operation should have:

•    A DO entry that does the action as well as also records a log record sufficient to undo and to redo the operation,
•    An UNDO entry that undo the action given the log record written by the DO action,
•    A REDO entry that redo the action given the log record written by the DO action, and
•    Optionally, a DISPLAY entry that decodes the log into a human-readable format.

To give an illustration of an action and the log record it must write, consider the database record update operator. This action should record in the log the:

1. Record name
2. The old record value (utilized for UNDO)
3. The new record value (utilized for REDO)

A log subsystem augments this with the additional fields:

4. Transaction identifier
5. Action identifier
6. Length of log record
7. Pointer to previous log record of this transaction

DECLARE
1 UPDATE_LOG_RECORD BASED,
2 LENGTH FIXED(16),                 /*length of log record */
2 TYPE FIXED(16),                     /*code assigned to update log recs*/
2 TRANSACTION FIXED(48),             /*name of transaction */
2 PREV_LOG_REC POINTER(31),            /* relative address of prev log */
/*record of this transaction */
2 SET FIXED(32),                     /* name of updated set (table) */
2 RECORD FIXED(32),                 /*name of updated record */
2 NFIELDS FIXED(l6),                 /*number of updated fields */
2 CHANGES (NFIELDS),                 /*for each changed field: */
3 FIELD FIXED(16);                     /* name of field */
3 OLD_VALUE,                     /*old value of field */
4 F_LENGTH FIXED(16),                /*length of old field value */
4 F_ATOM CHAR (F_LENGTH),             /*value in old field */
3 NEW_VALUE LIKE OLD_VALUE,         /*new value of field */
2 LENGTH_AT_END FIXED(16);            /*allows reading log backwards */

The data manager's undo operation restores the record to its previous value appropriately updating indices and sets. The redo operation reinstates the record to its new value. The show operation returns a text string giving a symbolic display of the log record.

The log itself is recorded on a devoted media (disk, tape,...). Formerly a log record is recorded, it cannot be updated. Nevertheless the log component provides a facility to open read cursors on the log that will traverse the system log or else will traverse the log of a particular transaction in either direction.

The UNDO operation should face a rather difficult problem at restart: The undo operation perhaps performed more than once if restart itself is redone several times (that is if the system fails during restart.)

As well one may be called upon to undo operations that were never reflected in non-volatile storage (that is log write occurred but object write did not.)

Alike problems exist for REDO. One may have to REDO an previously done action if the updated object was recorded in non-volatile storage before the crash or if restart is restarted.

The write-ahead-log-protocol as well as high-water-marks solves these problems.

Latest technology based Operating System Online Tutoring Assistance

Tutors, at the www.tutorsglobe.com, take pledge to provide full satisfaction and assurance in Operating System help via online tutoring. Students are getting 100% satisfaction by online tutors across the globe. Here you can get homework help for Operating System, project ideas and tutorials. We provide email based Operating System help. You can join us to ask queries 24x7 with live, experienced and qualified online tutors specialized in Operating System. Through Online Tutoring, you would be able to complete your homework or assignments at your home. Tutors at the TutorsGlobe are committed to provide the best quality online tutoring assistance for Operating System Homework help and assignment help services. They use their experience, as they have solved thousands of the Operating System assignments, which may help you to solve your complex issues of Operating System. TutorsGlobe assure for the best quality compliance to your homework. Compromise with quality is not in our dictionary. If we feel that we are not able to provide the homework help as per the deadline or given instruction by the student, we refund the money of the student without any delay.