trans recovery

7/31/2019 Trans Recovery

1/7

Transaction Recovery

Transaction recovery is required to ensure failure atomicity and

durability in the presence of failure.

Atomicity means all or nothing; it requires that the effects of allcommitted transactions are reflected in the data items and none of the

effects of incomplete or aborted transactions are reflected in the data

items.

Durability and Failure atomicity .

Durability requires that data items are saved in permanent storage and

therefore when a two-phase protocol commits, the changes to the data

item are permanently stored.

Failure atomicity requires that the effects of a transaction are atomic

even when the server fails.

When a server is running its keeps all of its data items in its volatile

memory and records its committed data in a recovery file. Therefore

recovery consists of restoring the server with the latest committed

version of its data items from its permanent storage.

Recovery Manager:-

Recovery is performed by recovery manager which saves the data ofcommitted transactions in permanent storage (recovery file).

Restores the servers data items after a crash.

Reorganize the recovery file to improve performance of recovery.

To reclaim the storage space in the recovery files.

Intention List:-

Each server records an intention list of its currently active transactions.

An intention list of particular transactions contains a list of names and

values of all data items that are altered by the transactions.

When a transaction commits the server uses the transactions list to

identify the data items that it affected.


2/7


3/7

2. Shadow versions

Logging

This is one of the uses of the recovery file (in this instance it is

sometimes called the log),It contains the history of all transactionsperformed by a server.

It is a log of all the values of data items, transaction status entries and

intentions lists of transactions processed by the server.

Normally the recovery manager is called whenever a transaction

prepares to commit, commits or aborts a transaction.

When a server is prepared to commit a transaction, the RM appends all

the data items in its intentions list to the recovery file, followed by the

current transaction status (prepared) together with the its intentions

list.

When the transaction is committed or aborted, the RM appends the

corresponding status of the transaction to the recovery file.

Log For Banking Service:-

10/9/201248

Log for banking service

P0 P1 P2 P3 P4 P5 P6 P7

Object:A Object:B Object:C Object:A Object:B Trans: T Trans: T Object:C Object: BTrans: U

100 200 300 80 220 prepared committed 278 242 prepared

P0 P3 P4

CheckpointEnd

of log


4/7

Here T and U are the two transactions, and A, B and C are the uniqueidentifiers for the objects.

The log was recently reorganized and entries to the left of the double line

represent a snapshot of values before transactions T and U.

We show the situation when a transaction T has committed and transactionU has prepared but not committed.

When a transaction T prepare to commit, the values of objects A and B arewritten at positionP1 and P2 in the log, followed by a prepare status entryfor t with its intention list(,).

When transaction T commits, committed transaction status entry for T isput at position P4.Then the transaction U prepares to commit, the values Cand B are written at the position P5 and P6 in the log, followed by preparedtransaction status entry for U with its intention list().

Each transaction status entry contains a pointer to the position in therecovery file of the previous transaction status entry to enable the recovery

manager to follow the transaction status entries in the reverse orderthrough recovery file.

The last pointer in the sequence of transaction entries points to thecheckpoint.

When a server is replaced after a crash, it first sets default initial values forits objects and then hands over to recovery manager. Recovery managerreads recovery file backward (most recent information is at the end ofthe log). The recovery file has been structured so that there is a backward

pointer from each transaction status entry to the next. If transaction iscommitted, restore committed values until it has restored all of its serversobjects. If not, record status of transaction as aborted.

The advantage of this approach is that each object is restored once only.


5/7

Recovery manager is responsible for reorganizing its recovery file so as tomake the process of recovery faster and to reduce its use of space.(bydiscarding old recovery file.)

The name checkponting is used to refer to the process of writing thecurrent committed values of servers objects to a new recovery file.

Checkpoint is used to refer to the information stored by check pointingprocess.

Shadow Versions

The logging technique records transaction status entries, intention list andobjects all in the same file-the log.

The shadow version technique is an alternative way to organize recoveryfile. It uses map to locate versions of the servers objects in a file calledversion store.

The map associates the identifiers of servers objects with the position oftheir current versions in the version store.

When a transaction commits a new map is made. The switch between thetwo maps must be done atomically.

The version written by each transaction are shadow the previouscommitted versions.

When a transaction is prepared to commit any of the object changed by thetransaction are appended to the version store, leaving the correspondingcommitted versions unchanged.


6/7

There new as yet tentative versions are called shadow versions.

To complete the commit process, the new map replaces the old map.

To restore the objects when a server is replaced after a crash, its recoverymanager reads the map and uses the information in the map to locate theobjects in the version store.

This technique is illustrated with the same example.The first column in thetab le shows the map before transaction T and second column shows the

map after transaction has committed.

10/11/201249

Shadow versions

Shadow versions of Band C

Map at start Map when T commits

A P0

A P1

B P0' B P

2

C P0" C P

0"

P0 P0' P0" P1 P2 P3 P4

Version store 100 200 300 80 220 278 242

Checkpoint

The map must always be written to a well known place, so that it can be

found when the system needs to be recovered.


7/7

The shadow version provides faster recovery than logging because the

positions of the current committed objects are recorded in the map, where

as recovery from log requires searching through out the log for objects.

trans recovery

Documents