Module 3

Transaction Management and Concurrency

Jinesh Melvin Y I
Topics to be covered
Transaction Concepts
A collection of several operations on the database appears to be a single
logical unit from the point of view of the database user.

The transaction consists of all operations executed between the begin

transaction and end transaction.

This collection of steps must appear to the user as a single, indivisible unit.
Since a transaction is indivisible, it either executes in its entirety or not at all.

If a transaction begins to execute but fails for whatever reason, any

changes to the database that the transaction may have made must be undone.
Transaction Model
Transaction concept using a simple bank application consisting of several accounts
and a set of transactions that access and update those accounts.

Transactions access data using two operations:

• read(X), which transfers the data item X from the database to a variable, also
called X, in a buffer in main memory belonging to the transaction that executed the
read operation.

• write(X), which transfers the value in the variable X in the main-memory buffer of
the transaction that executed the write to the data item X in the database.
Transaction Model Cont...
Let Ti be a transaction that transfers $50 from account A to account B. This
transaction can be defined as:

Ti : read(A);

A := A − 50;

write(A);

read(B);

B := B + 50;

write(B).
Properties of the Transactions.
ACID

A -> Atomicity

C -> Consistency

I -> Isolation

D -> Durability
Properties of the Transactions Cont...
Atomicity:

Either all Operations of the transaction are reflected properly in the database or
none.

Consistency:

Execution of a transaction in isolation, ie with no other transaction executing

concurrently preserves the consistency of the database.

Isolation:

Even though multiple transactions may execute concurrently, the system

guarantees that, for every pair of transaction Ti and Tj, it appears to Ti that either Tj
finished execution before Ti started or Tj start execution after Ti finished.
Properties of the Transactions Cont...
Durability:

After a transaction completes successfully, the changes it has made to the

database persist, even if there are system failures.

Simple Transaction Model:

This concepts is using Bank Application.

read(x) -> x is the dataitem, buffer in main memory, used to read the previous
balance/data.

write(x) -> update the data to the database.

Simple Transactions Model
Ti : read(A);

A := A − 50;

write(A);

read(B);

B := B + 50;

write(B).

Atomicity:

Suppose Ti transaction with two accounts A and B, which has $1000 and $2000
respectively.
Simple Transactions Model Cont...
Account A wants to transfer $50 to account B, due to some failure A’s account
get debited but B’s is not get credited ie $950 in A’s account and $2000 is in B’s
account. This state is called inconsistent state.

To make it consistent the transaction will happen successfully, which means A’s
account debit $50 and B’s account get credit $50, so balance amount is $950 and
$2050.

If the system failures in any operation, then it restore the old value from log.
Simple Transactions Model Cont...
Consistency:

The Consistency requirement here is that the sum of A and B be unchanged by

the execution of the transaction.

Without the consistency requirement, money could be created or destroyed by the

transaction. It can be verified easily that, if the database consistent before an execution
of the transaction the database remains consistent after the execution of the
transaction.

Ensuring consistency for an individual transaction is the responsibility of the

application programmer who codes the transaction. This task may be facilitated by
automatic testing of integrity constraints.
Simple Transactions Model Cont...
Isolation:

Isolation allows multiple transactions to occur at the sametime without impacting

the execution of each.

Example.

A and B transaction should operate on the database in an isolated manner.

The database should either perform A entire transaction before executing B or

vice-versa.

The isolation property does not ensure that a specific transaction will execute
first, only that they will not interfere with each other.
Simple Transactions Model Cont...
Isolation:

There are four levels of isolation

1. Serializable
2. Repeatable
3. Read Committed
4. Read Uncommitted.

1. Serializable.

The transaction will be completed before another transaction is able to start.

2. Repeatable.

Read allows transactions to be accessed once that transaction has started, even
Simple Transactions Model Cont...
Isolation:

though it hasn’t been finished.

3. Read Committed.

Allow the data to be accessed after the data has been committed to the database,
but not before then.

4. Read Uncommitted.

Allows data to be accessed before the changes have been made.

Simple Transactions Model Cont...
Durability:

It must be the case that no system failure can result in a loss of data
corresponding to this transfer of funds.

The durability property guarantees that once a transaction completes successfully

all updates that it carried out on the database even if there is a system failure after the
transaction completes execution.

We assume for now that a failure of the computer system may result in loss of
data in main memory, but data written to disk are never lost.

We can guarantee durability by ensuring that either.

Simple Transactions Model Cont...
Durability:

1. The updates carried out by the transaction have been written to disk before
transaction completes.
2. Information about the updates carried out by the transaction and written to
disk is sufficient to enable the database to reconstruct the updates when the
database system is restart after failure.
Transactions Process.
Transactions States.

During its execution a transaction must be in any one of the following state.

Five different states are: Active State, Partially Committed state, Failed State,
Committed state and Terminated.
Transactions States Cont....
Active State:

The transaction starts executing from the first instruction begin_transaction, the
transaction will be consider in active state. During this state it performs
operations READ and WRITE on some data item.

Partially Committed state:

A transaction goes into the partially committed state after the end of a
transaction.

Committed State:

When the transaction is committed to state, it has already completed its execution
successfully. Moreover, all of its changes are recorded to the database
permanently.
Transactions States Cont....
Failed State:

A transaction considers failed when any one of the checks fails or if the
transaction is aborted while it is in the active state.

Aborted State:

After the failed state, all the changes mades by the transaction has to rolled back
and the database has to be restored to its state prior to the start of the
transaction.

If these actions are completed by the DBMS then the transaction consider to be in
aborted state.
Transactions States Cont....
Example:

Let us assume a transaction T1 that transfer money from account A to account B.

Before transaction let A = 1000 and B = 1000. The transaction can be represented
as follows.

Transaction T1: BEGIN TRANSACTION

READ(A);

A:=A-500;

WRITE(A);
Transactions States Cont....
READ(B);

B:=B+500;

WRITE(B);

COMMIT;

END TRANSACTION;

★ Active state:

In ACTIVE STATE, A=1000 and B=1000

Transactions States Cont....
★ Partially Committed:

In PARTIALLY COMMITTED State, A=500 and B=1000.

★ Failed state:

It happens before WRITE(A), then A=1000 and B=1000

It happens after WRITE(A), then A=500 and B=1000

It happens before COMMIT and after WRITE(B), then A=500 and

B=1500.

★ Aborted state:

Undo the changes made so far, the old consistent values of data items A
and B are restored.
Transactions States Cont....

★ Committed:

If it successfully write a new values of A and B into log file or stable storage,
then the transaction is said to be committed state.

In COMMITTED STATE, A=500 and B=1500[New Consistent State]

Serializability.
When multiple transaction are being executed by Operating system in a multiple
program environment, there are possibilities that instructions of one transaction are
interleaved with some other transaction.

➔ Schedule.
➔ Serial Schedule.

Schedule:

A chronological execution sequence of transaction is called a schedule. A schedule

can have many transaction in it, each comprising of a number of instructions/tasks.

Serial Schedule:

It is a schedule in which transactions are aligned in such a way that one

transaction is executed first. When first transaction completes its cycle then the next
transaction will executed.
 Serializability Cont...
Transactions are order one after the other. These type of schedule is called serial
schedule.

Two Transaction T1 and T2

 Serializability Cont...
Serial Schedule:

1. Execute all the operations of transaction in sequence followed by T2.

2. Execute all the operations of transaction in sequence followed by T1.
 Serializability Cont...
a. Serial Schedule A : T1 followed by T2.

b. Serial Schedule B : T2 followed by T1.

 Serializability Cont...
Two non serial schedule C and schedule D with interleaving of operations.

Concepts of Serializability:

Let,

Consider a Schedule S in which there are two consecutive instructions, I and

J of transaction Ti and Tj respectively(i!=j)

If I and J refer to different data items, then we can swap I and J without
affecting the results and instruction in the schedule.

However if I and J refer to the same data item Q, then the order of the two
steps may matter.

We are dealing with only read and write instructions, there fair case that
need to consider
 Serializability Cont...
1. I = read(Q), J = read(Q). The order I and J does not matter,since the same
value of Q is read by Ti and Tj.

2. I = read(Q), J = write(Q). If I comes before J, then Ti does not read the value of
Q that it written by Tj in instruction J.

If J comes before I, then Ti read the value of Q that it written by Tj in instruction

J.

Showing only Read and Write instruction

 Serializability Cont...
After Swapping of a pair of instructions
 Serializability Cont...
2. I = read(Q), J = write(Q).
 Serializability Cont...
3. I = write(Q), J = read(Q), The order of I and J matters for reasons similar to
those of the previous case.

4. I = write(Q), J = write(Q), Both instructions are write operations, the order of

these instructions does not affect either Ti or Tj
 Serializability Cont...
3. I = write(Q), J = read(Q), The order of I and J matters for reasons similar to
those of the previous case.
 Serializability Cont...
4. I = write(Q), J = write(Q), Both instructions are write operations, the order of
these instructions does not affect either Ti or Tj
Examples:
Read - Write Conflict:

Suppose A and B want to book the flight for their vacation. A open airlines
website to check the availability and cost of the ticket. There is only one ticket is
available. A finds it expensive and looks for other airlines fares if she gets any
offers.

Meanwhile, B logins to the same airline portal and book the ticket. Now, there is
no more flight ticket available.

A does not find any good offer on other airlines portal, she comes back to the
previous airline portal. And tried to book a flight ticket even it is not available.
This conflict is called (RW) Conflict
Examples:
Write - Write Conflict:

A and B share common Google-sheet online. Both read the file. A updates the
document and forgets to save the file. On another end, B updates the Google sheet
and save the file.

The content updated by A is overwritten by B. The data updated by A is lost. It is

called as Write-Write (WW) conflict.
Concurrency Control.
What is Concurrency Control?

Concurrency control is the procedure in DBMS for managing simultaneous

operations without conflicting with each other. Concurrent access is quite easy if
all users are just reading data. There is no way they can interfere with one
another. Though for any practical database, would have a mix of READING and
WRITE operations and hence the concurrency is a challenge.

Concurrency control is used to address such conflicts which mostly occur with a
multi-user system. It helps you to make sure that database transactions are
performed concurrently without violating the data integrity of respective
databases.
Concurrency Control Cont...

Potential problems of Concurrency

★ Lost Updates

★ dirty read

★ Non-Repeatable Read

★ Incorrect Summary issue

Concurrency Control Cont...
Why use Concurrency method?

Reasons for using Concurrency control method is:

● To apply Isolation through mutual exclusion between conflicting transactions

● To resolve read-write and write-write conflict issues
● To preserve database consistency through constantly preserving execution
obstructions
● The system needs to control the interaction among the concurrent
transactions. This control is achieved using concurrent-control schemes.
● Concurrency control helps to ensure serializability
Concurrency Control Techniques.
1. Lock Based Protocol:

A lock guarantees exclusive of a data item to a current transaction.

To Access Data item the lock will acquire

After completion of transaction, it release lock.

All dataitem mut be accessed in a mutually exclusive manner.

Types of Locks:

1. Shared Lock(S): Read dataitem values.

2. Exclusive Locks(X): Both read and write /update values.

Concurrency Control Techniques Cont...
Compatibility between lock mode:

Example of Lock protocols:

Concurrency Control Techniques Cont...
Any number of transaction can hold shared lock on an item but Exclusive lock can
be hold only by one transaction at a time.

Versions of Locks:

1. Upgrading -> Read locks -> Write lock

2. Downgrading -> Write lock -> Read lock

Two phase locking (2PL)

1. Phase 1: Growing (Locking) phase.

T obtain locks

T may not release locks

Concurrency Control Techniques Cont...
2. Phase 2: Shrinking (unlocking) phase:

T release locks

T may not obtain locks.

Example:
Concurrency Control Techniques Cont...
Concurrency Control Techniques Cont...
Schedule 1:
Concurrency Control Techniques Cont...
Deadlock.
In a multi-process system, deadlock is an unwanted situation that arises in a shared
resource environment, where a process indefinitely waits for a resource that is held by
another process.

For example, assume a set of transactions {T0, T1, T2, ...,Tn}. T0 needs a resource X
to complete its task. Resource X is held by T1, and T1 is waiting for a resource Y,
which is held by T2. T2 is waiting for resource Z, which is held by T0. Thus, all the
processes wait for each other to release resources. In this situation, none of the
processes can finish their task. This situation is known as a deadlock.

Deadlocks are not healthy for a system. In case a system is stuck in a deadlock, the
transactions involved in the deadlock are either rolled back or restarted.
Deadlock Cont...
Deadlock Cont...
Necessary Condition:

★ Hold & wait

★ Mutual Exclusion
★ No Preemption
★ Circular wait

How 2 Phase locking protocol get reduced Concurrency?

2 PL protocol enforces serializability but may reduce concurrency due to the

following reasons.

1. Holding lock unnecessary

2. Locking too early
3. Penalty to other transaction.
Deadlock Cont...
Deadlock Handling:

There are two principal methods for dealing with the deadlock problems.

1. Deadlock Prevention
2. Deadlock Detection and Recovery

1. Deadlock Prevention:

If it finds that a deadlock situation might occur, then that transaction is never
allowed to be executed.

Two approaches to deadlock prevention

i) Ensure that no cyclic waits can occur by ordering the requests for lock.

ii) It closer to deadlock recovery and performs transaction rollback instead of

waiting for a lock, whenever the wait could potentially result in a deadlock
Deadlock Cont...

Two points of Deadlock Prevention

1. Advance Locking

Transaction T should lock data before execution. So there is no

deadlock in feature.

2. Ordering dataitem

Lock data item in ascending or descending, previously it would be

in random and the ordering of data item should happen before execution.
 Deadlock Cont...
Time-stamp based:

1. Wait-die:

If a transaction requests to lock a resource (data item), which is already held with
a conflicting lock by another transaction, then one of the two possibilities may occur −

● If TS(Ti) < TS(Tj) − that is Ti, which is requesting a conflicting lock, is older than T j −
then Ti is allowed to wait until the data-item is available.
● If TS(Ti) > TS(tj) − that is Ti is younger than Tj − then Ti dies. Ti is restarted later with a
random delay but with the same timestamp.

This scheme allows the older transaction to wait but kills the younger one.
 Deadlock Cont...
2. Wound-Wait Scheme

If a transaction requests to lock a resource (data item), which is already held with
conflicting lock by some another transaction, one of the two possibilities may occur −
● If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back − that is Tiwounds Tj. Tj is
restarted later with a random delay but with the same timestamp.
● If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource is available.

This scheme, allows the younger transaction to wait; but when an older transaction
requests an item held by a younger one, the older transaction forces the younger one to
abort and release the item.
In both the cases, the transaction that enters the system at a later stage is aborted.
 Deadlock Cont...
TimeOut Based:
Transaction is wait for fix time for any dataitem (resource), if transaction is fails to
get the results in a given time, then transaction is rolled back and it restart after
sometime.
Deadlock Detection:
The way to detect the deadlock is wait for graph. G=(V, E)
G -> Graph, V -> Vertices representation the ‘T’ E -> Set of Edges

In this method a graph is drawn based on the transaction and their lock on the resource. If the graph created has a
closed loop, then there is a deadlock. In DBMS maintains this graph for all the transactions waiting for the resources
and checks if there is a loop.

Suppose T1 and T2 are two transactions. Suppose T1 is requesting for a resource R which is held by T2. In this
case, wait for graph draws an arrow from T1 to T2. If T2 releases the resource R, then this arrow is deleted.
Deadlock Cont...
Deadlock Recovery:

1. Select the victim.

Suppose T1 is the victim, then we have to kill that, then T2 will successfully get
execute. This means we can recover from the deadlock.

How we can identify the victim?

We have four point to select victim,

★ Cost of ‘T’
★ How many more ‘T’ would be affected and its rollback.
★ How many data items has locked
★ How much time it need to complete.
Deadlock Cont...
Deadlock Recovery:

2. Roll back:

Total Rollback: Victim is selected and after that it is terminated completely.

Partial Rollback: It says we have selected the victim but we have rollback upto
the certain point, so that it can break the deadlock.

Partial rollback is the effective way to break the deadlock.

3. Starvation: Same transaction has not rollback again and again.

Recovery System
Failure Classification

Transaction failure: A transaction has to abort when it fails to execute or when it

reaches a point from where it can’t go any further. This is called transaction failure where
only a few transaction or process are hurt.

Reasons for a transaction failure could be:

1. Logical error.

2. System error.
Recovery System Cont...
System Crash:

Power supply, Hardware or Software, Operating System, Memory and so on..

Disk Failure:

Hard disk drive, Permanent storage, Temporary storage and any other disk
failure.

Storage Structure:

1. Volatile storage: Main memory and cache memory

2. Non-Volatile storage: Hard disk, magnetic taps, flash memory, battery backups.
Recovery System Cont...
Log based Recovery:

A log is the most widely used recording database modification technique. The log is a
structure used for recording database modification. It is a sequence of log record
recording all the update activities in the database. We can use this log to recover from
failure and to bring back the database to the consistent state. An update log record
contains various fields:

● Transaction identifier: It is the identifier which uniquely identifies the

transaction.
● Data item identifier: It is the identifier which uniquely identifies the data to be
used.
● Old value: It is the value of the data item before the write operation.
● New value: It is the value of the data item after performing the write operation.
 Recovery System Cont...
There are many types of log record we denote the various types of log records:

1. <Ti start> transaction Ti has started.

2. <Ti, Xi, V1, V2> transaction Ti has performed a write on data item Xi, Xj has
value v1 before the write and will have value V2 after the write operation.
3. <Ti commit> transaction Ti has committed.
4. <Ti abort> transaction Ti has aborted.

In the recovery method, we use two operations:

1. Undo(Ti): Restores the values of all data item updated by transaction Ti to the old
values.
2. Redo(Ti): Sets the value of all data item updated by transaction Ti to the new values.
We need to undo a transaction T only when log contains the record <T start> only
when log contains the record <start> and <T commit> both.
 Recovery System Cont...
Transaction modification technique
There are mainly two techniques to ensure the transaction atomicity despite failure are as
follow:

1) Immediate database modification

2) Deferred modification technique

1) Immediate database modification

We consider an example of banking system taken earlier for transaction To and T1
such that To is followed by T1. If the system crash occurs just after the log record and
during recovery we do redo (To) and undo (T1) as we have both < To start > and
<To commit> in the log record. But we do not have <T1 commit> with <T1
start> in log record. Undo(T1) should be done first then redo (To) should be done.
Recovery System Cont...
Example

<To start>

<To A, 1000, 950>

<To B, 2000, 2050>

<To commit>

<T1 start>

<T1 C, 700, 600>

<Ti commit>
 Recovery System Cont...
2) Deferred modification technique
Example

(A) (B)

<To start> <To start>

<To A, 950> <To A , 950>

<To B, 2050> <To B, 2050>

<To commit>

<T1 start>

<T1 C, 600>

If a system fails just after the log record for the step write(B) of transaction To. The during recovery no redo
operation will be done as we have only <To start> in log record but not <To commit>.
 Recovery System Cont...
If a system crash occurs just after the log record write C. the during recovery only redo (To) is done as we have only
<To start> and <To commit> in log disk. At the same time we have <T1 start> in log disk but not <T1
commit> so redo (T1) will not be done.

(C)

<To start>

<To A , 950>

<To B, 2050>

<To commit>

<T1 start>

<T1 C, 600>

<T1 commit>

If a system crash occurs just after the log record <T1 commit> the during the recovery we will perform both redo (T0) and
redo (TI) as we have both <To start> <To commit> and <T1 start>, <T1 commit> in log disk.
Recovery System Cont...
Check points:
When a system crash occurs, we must consult the log to determine those transactions
that need to be redone and those that need to be undone. In principle, we need to
search the entire log to determine this information. There are two major difficulties
with this approach:
1. The search process is time-consuming.
2. Most of the transactions that, according to our algorithm, need to be redone
have already written their updates into the database. Although redoing them will
cause no harm, it will nevertheless cause recovery to take longer.
To reduce these types of overhead, we introduce checkpoints.
Note:
A. Does not permit any updates to be performed while the checkpoint operation is in
progress.
B. Outputs all modified buffer blocks to disk when the checkpoint is performed.
Recovery System Cont...
A checkpoint is performed as follows:

1. Output onto stable storage all log records currently residing in main memory.
2. Output to the disk all modified buffer blocks.
3. Output onto stable storage a log record of the form <checkpoint L>, where
L is a list of transactions active at the time of the checkpoint.

Transactions are not allowed to perform any update actions, such as writing to a
buffer block or writing a log record, while a checkpoint is in progress.
The presence of a <checkpoint L> record in the log allows the system to
streamline its recovery procedure. Consider a transaction Ti that completed prior
to the checkpoint. For such a transaction, the <Ti commit> record (or < Ti abort>
record) appears in the log before the <checkpoint> record. Any database
modifications made by Ti must have been written to the database either prior to the
Recovery System Cont...
checkpoint or as part of the checkpoint itself. Thus, at recovery time, there is no
need to perform a redo operation on Ti .

After a system crash has occurred, the system examines the log to find the last
<checkpoint L> record (this can be done by searching the log backward, from
the end of the log, until the first <checkpoint L> record is found).

The redo or undo operations need to be applied only to transactions in L, and

to all transactions that started execution after the <checkpoint L> record was
written to the log. Let us denote this set of transactions as T.
● For all transactions Tk in T that have no <Tk commit> record or <Tk abort>
record in the log, execute undo(Tk ).
● For all transactions Tk in T such that either the record <Tk commit> or the
record <Tk abort> appears in the log, execute redo(Tk ).
 Recovery System Cont...
Recovery Algorithm:
➔ Transaction Rollback
➔ Recovery After a System Crash
Transaction Rollback:
First consider transaction rollback during normal operation (that is, not during recovery from a
system crash). Rollback of a transaction Ti is performed as follows:
1. The log is scanned backward, and for each log record of Ti of the form <Ti, Xj, V1, V2>
that is found:
a. The value V1 is written to data item Xj , and
b. A special redo-only log record <Ti, Xj, V1> is written to the log, where V1 is the value
being restored to data item Xj during the rollback.
These log records are sometimes called compensation log records. Such records do not need undo
information, since we never need to undo such an undo operation. We shall explain later how
they are used.
2. Once the log record <Ti start> is found the backward scan is stopped, and
a log record <Ti abort> is written to the log.
Recovery System Cont...
Recovery After a System Crash
Recovery actions, when the database system is restarted after a crash, take place
in two phases:
1. In the redo phase, the system replays updates of all transactions by scanning the log forward
from the last checkpoint. The log records that are replayed include log records for transactions
that were rolled back before system crash, and those that had not committed when the system
crash occurred.
This phase also determines all transactions that were incomplete at the time of the crash, and
must therefore be rolled back. Such incomplete transactions would either have been active at the
time of the checkpoint, and thus would appear in the transaction list in the checkpoint record, or
would have started later; further, such incomplete transactions would have neither a <Ti abort>
nor a <Ti commit> record in the log.
The specific steps taken while scanning the log are as follows:
a. The list of transactions to be rolled back, undo-list, is initially set to the list L in the
<checkpoint L> log record.
Recovery System Cont...
Recovery After a System Crash
b. Whenever a normal log record of the form <Ti, Xj, V1, V2>, or a
redo-only log record of the form <Ti, Xj, V2> is encountered, the
operation is redone; that is, the value V2 is written to data item Xj .
c. Whenever a log record of the form <Ti start> is found, Ti is added to
undo-list.
d. Whenever a log record of the form <Ti abort> or <Ti commit> is
found, Ti is removed from undo-list.
At the end of the redo phase, undo-list contains the list of all transactions
that are incomplete, that is, they neither committed nor completed rollback
before the crash.
2. In the undo phase, the system rollback all transactions in the undo-list. It
performs rollback by scanning the log backward from the end.

a. Whenever it finds a log record belonging to a transaction in the undo list, it performs undo
actions just as if the log record had been found
Recovery System Cont...
during the rollback of a failed transaction.
b. When the system finds a <Ti start> log record for a transaction Ti in
undo-list, it writes a <Ti abort> log record to the log, and removes Ti
from undo-list.
c. The undo phase terminates once undo-list becomes empty, that is, the
system has found <Ti start> log records for all transactions that were
initially in undo-list.
After the undo phase of recovery terminates, normal transaction processing
can resume.
Recovery System Cont...
Recovery System Cont...
Recovery System Cont...
Shadow Paging:

1. Needs less no. of disk access than log based method.

2. During the life cycle of the transaction two page table are maintained.
➢ Current Page Table
➢ Shadow Page Table
3. When transaction begin both page tables are identical.
4. Shadow Page Table never changes during transaction active state.
5. Where as Current Page table change during active state of transaction/write
operation.
Recovery System Cont...
8. All input and output operation use Current Page Table to locate in database page
on disk.
9. Shadow Page Table stored in a Non Volatile storage.
Note: On commit of transaction system write current page table to non volatile
storage ie, current page table become shadow page table.
When system performance another operation / new transaction arrives then it copies
shadow page table to main memory.
Advantages:
★ Log record overhead is removed.
★ Faster recovery ie, no UNDO and REDO.
Recovery System Cont...
 Recovery System Cont...
ARIES Algorithm:
1. ARIES stands for “Algorithm for Recovery and Isolation Exploiting Semantics.”
2. No force type of backup approach.
3. Recovery Manager is generally called at time of crash.
3 Steps or phases in ARIES
1. Analysis phase
2. Redo phases
3. Undo phases
1. Analysis phases:
Identify the dirty pages(updated) to the buffer and set of active transaction or time of
failures (p1, p3, p5).
 Recovery System Cont...
When system is restored, analysis is done and it identifies that T1 and T3 are active
hence reverte it.
2. Redo phases:
Aries finds all operations done by DBMS before crash and restore system back to
the same state before crash.
It aborts all actions of transactions those are still in active state at the time of
crash.
The write operations T1 and T3 are applied once again in the same order.
 Recovery System Cont...
3. Undo phases:
Scan the log backwards and write actions of the active transaction in reverse order.
T3 write p3 is undone
T3 write p1 is undone
T1 write p5 is undone.
Advantages:
Simple and Flexible.
Supports concurrency protocols.
Independent recovery of every pages.
Transaction records save points and rollback upto that save point.
Recovery System Cont...
Example:
The End