0% found this document useful (0 votes)
7 views

Unit -4 - part 2

Uploaded by

admin pro
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

Unit -4 - part 2

Uploaded by

admin pro
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 50

Course Code: CS302

Database Management Systems

UNIT – IV

Transactions and Query Processing: Transaction Management - ACID properties,


Concurrency control – Schedules - Serializability, Locking Protocols,
Recoverability, Query Processing and optimization, Database Recovery methods.

Slide 1- 1
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
Schedule

 A schedule is a list of transactions.


 Or
 A series of operation from one transaction to another transaction is known as
schedule.
 It is used to preserve the order of the operation in each of the individual
transaction.
 Or
 A Schedule is a process creating a single group of the multiple parallel
transactions and executing them one by one.
 Or
 When there are multiple transactions that are running in a concurrent manner
and the order of operation is needed to be set so that the operations do not
overlap each other, Scheduling is brought into play and the transactions are
timed accordingly.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 2
Schedule

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 3


1. Serial Schedule
 The serial schedule is a type of schedule where one transaction is executed
completely before starting another transaction.
 In the serial schedule, when the first transaction completes its cycle, then the
next transaction is executed.
 For example: Suppose there are two transactions T1 and T2 which have some
operations. If it has no interleaving of operations, then there are the following
two possible outcomes:
1. Execute all the operations of T1 which was followed by all the operations
of T2.
2. Execute all the operations of T2 which was followed by all the operations
of T1.
 In the given (b) figure, Schedule B shows the serial schedule where T2
followed by T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 4


1. Serial Schedule
In the given (a) figure, Schedule A shows the serial schedule where T1 followed by
T2.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 5


1. Serial Schedule
In the given (b) figure, Schedule B shows the serial schedule where T2 followed
by T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 6


2. Non-serial Schedule
 If interleaving of operations is allowed, then there will be non-serial schedule.
 It contains many possible orders in which the system can execute the individual
operations of the transactions.
 In the given figure (c) and (d), Schedule C and Schedule D are the non-serial
schedules. It has interleaving of operations.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 7


2. Non-serial Schedule

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 8


2. Non-serial Schedule

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 9


2. Non-serial Schedule
 In non-serial schedule - If the schedule is not proper - Then the problems can
arise like
 Multiple update

 Uncommitted dependency

 Incorrect analysis.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 10


3. Serializable schedule
 The serializability of schedules is used to find non-serial schedules that allow
the transaction to execute concurrently without interfering with one another.
 It identifies which schedules are correct when executions of the transaction
have interleaving of their operations.
 A non-serial schedule will be serializable if its result is equal to the result of its
transactions executed serially.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 11


3. Serializable schedule
 The main objective of serializability
 Is to find non-serial schedules

 that allow transactions to execute concurrently without interference and

 produce a database state

 that could be produced by a serial execution.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 12


Schedule Example

Consider the following two transactions for a bank:


 The first is meant to deduct $100 from an account
 The second adds 0.5% interest to every account in the bank.

 The transactions are:


Transaction 1
UPDATE accounts SET balance = balance – 100 WHERE acct_id = 3456;

Transaction 2
UPDATE accounts SET balance = balance+( balance * 0.005);

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 13


Schedule Example

 We'll summarize their interactions with the DBMS in the following form:

Transaction 1: r1(A), w1(A)


Transaction 2: r2(A), w2(A), r2(B), w2(B)

 One Possible Schedule - (Non – serial)


 A schedule is some interleaving of the operations from the two transactions
(without violating the order of operations within any individual transaction).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 14


Schedule Example

Schedule S:
r1(A), r2(A), w1(A), w2(A), r2(B), w2(B)
 If account A starts with $200
 If account B starts with $100
 We can trace what would happen with Schedule S.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 15


Schedule Example

 Schedule S is very bad! (At least, it's bad if you're the bank!)
 We withdrew $100 from account A,
 But somehow the database has recorded that our account now holds $201.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 16


Schedule Example

Serial schedule
 Our idea is a serial schedule, in which all operations by a transaction are
grouped together.

 For our two transactions, • There are only two ways to arrange their operations
to get a serial schedule:

 Serial schedule 1: r1(A), w1(A), r2(A), w2(A), r2(B), w2(B)


 Serial schedule 2: r2(A), w2(A), r2(B), w2(B), r1(A), w1(A)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 17


Schedule Example

Serial schedule
 Problem :
 In practice, a serial schedule isn't realistic, because it means we must wait for
one transaction to complete before starting another.

 Solution:
 We would really prefer to interleave them — but we need to interleave the
transactions so that they work the same as some serial schedule.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 18


Schedule Example

Serializable schedule
 As an example, consider Schedule T, which has swapped the third and
fourth operations from S:

 Schedule T: r1(A), r2(A), w2(A), w1(A), r2(B), w2(B)

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 19


Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 20
Precedence Graph
For
Testing Serializability

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 21


Precedence Graph For Testing Serializability

 Precedence Graph or Serialization Graph is used commonly to test


Serializability of a schedule.

 It is a directed Graph (V, E) consisting of


 a set of nodes V = {T1, T2, T3……….Tn} and

 a set of directed edges E = {e1, e2, e3……em}.

 The graph contains one node for each Transaction Ti.


 An edge ei is of the form Tj –> Tk

 where Tj is the starting node of ei and Tk is the ending node of ei.

 An edge ei is constructed between nodes Tj to Tk


 if one of the operations in Tj appears in the schedule before some operation

in Tk .

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 22


Precedence Graph For Testing Serializability

The set of edges is used to contain all edges Ti ->Tj for which one of the three
conditions holds:
 Create a node Ti → Tj if Ti executes write (Q) before Tj executes read (Q).
 Create a node Ti → Tj if Ti executes read (Q) before Tj executes write (Q).
 Create a node Ti → Tj if Ti executes write (Q) before Tj executes write (Q).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 23


Precedence Graph For Testing Serializability

 If a precedence graph contains a single edge Ti → Tj, then all the instructions
of Ti are executed before the first instruction of Tj is executed.

 If a precedence graph for schedule S contains a cycle,


 then S is non-serializable.

 If the precedence graph has no cycle,


 then S is known as serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 24


Precedence Graph For Testing Serializability

Example: Consider the schedule S :


 S : r1(x) r1(y) w2(x) w1(x) r2(y)

Creating Precedence graph:


 Make two nodes corresponding to Transaction T 1 and T2.

 S : r1(x) r1(y) w2(x) w1(x) r2(y)


 For the pair r1(x) w2(x),
 where r1(x) happens before w2(x),
 draw an edge from T1 to T2

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 25


Precedence Graph For Testing Serializability

 S : r1(x) r1(y) w2(x) w1(x) r2(y)


 For the pair w2(x) w1(x),
 where w2(x) happens before w1(x),
 draw an edge from T2 to T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 26


Precedence Graph For Testing Serializability – Example:

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 27


Precedence Graph For Testing Serializability

Example: Explanation:
Read(A): In T1, no subsequent writes to A, so no new edges
Read(B): In T2, no subsequent writes to B, so no new edges
Read(C): In T3, no subsequent writes to C, so no new edges
Write(B): B is subsequently read by T3, so add edge T2 → T3
Write(C): C is subsequently read by T1, so add edge T3 → T1
Write(A): A is subsequently read by T2, so add edge T1 → T2
Write(A): In T2, no subsequent reads to A, so no new edges
Write(C): In T1, no subsequent reads to C, so no new edges
Write(B): In T3, no subsequent reads to B, so no new edges

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 28


Precedence Graph For Testing Serializability – Example:

Precedence graph for schedule S1:

T1

T2 T3

The precedence graph for schedule S1 contains a cycle that's why Schedule S1
is non-serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 29


Precedence Graph For Testing Serializability – Example:

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 30


Precedence Graph For Testing Serializability

Example: Explanation:
Read(A): In T4,no subsequent writes to A, so no new edges
Read(C): In T4, no subsequent writes to C, so no new edges
Write(A): A is subsequently read by T5, so add edge T4 → T5
Read(B): In T5,no subsequent writes to B, so no new edges
Write(C): C is subsequently read by T6, so add edge T4 → T6
Write(B): A is subsequently read by T6, so add edge T5 → T6
Write(C): In T6, no subsequent reads to C, so no new edges
Write(A): In T5, no subsequent reads to A, so no new edges
Write(B): In T6, no subsequent reads to B, so no new edges

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 31


Precedence Graph For Testing Serializability – Example:

Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no cycle that's why


ScheduleS2 is serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 32


Types of serializability:

 Depending on the type of schedules, there are two types of serializability:


 Conflict Serializable Schedule

 View Serializable Schedule

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 33


Conflict Serializability

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 34


Conflict Serializable Schedule

 A schedule is called conflict serializable


 if it can be transformed into a serial schedule
 by swapping non-conflicting operations.
 or
 The schedule will be a conflict serializable if it is conflict equivalent to a serial
schedule.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 35


Conflict Serializable Schedule

Conflicting operations:
 Two operations are said to be conflicting if all conditions satisfy:
 They belong to different transaction

 They operate on same data item

 At Least one of them is a write operation

Example - Conflicting operations


 Conflicting operations pair (R1(A), W2(A)) because they belong to two
different transactions on same data item A and one of them is write operation.
 Similarly, (W1(A), W2(A)) and (W1(A), R2(A)) pairs are also conflicting.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 36


Conflict Serializable Schedule

Example - Conflicting operations

 Here, S1 ≠ S2. That means it is conflict.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 37


Conflict Serializable Schedule

Example – Non Conflicting operations:


 On the other hand, (R1(A), W2(B)) pair is non-conflicting because they
operate on different data item.
 Similarly, ((W1(A), W2(B)) pair is non-conflicting.

 Here, S1 = S2. That means it is non-conflict.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 38


Conflict Serializable Schedule - Example

Example
 Consider the following schedule:
 S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)

 we can get two transactions of schedule S1 as:


 T1: R1(A), W1(A), R1(B), W1(B)
 T2: R2(A), W2(A), R2(B), W2(B)

 Possible Serial Schedules are:


T1->T2 or T2->T1

 Swapping non-conflicting operations


 R2(A) and R1(B) in S1, the schedule becomes,

 S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)

 S11: R1(A), W1(A), R1(B), W2(A), R2(A), W1(B), R2(B), W2(B)


Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 39
Conflict Serializable Schedule - Example

Example
 Similarly, swapping non-conflicting operations W2(A) and W1(B) in S11,
the schedule becomes
 S11: R1(A), W1(A), R1(B), W2(A), R2(A), W1(B), R2(B), W2(B)

 S12: R1(A), W1(A), R1(B), W1(B), R2(A), W2(A), R2(B), W2(B)

 S12 is a serial schedule in which all operations of T1 are performed before


starting any operation of T2.
 Since S1 has been transformed into a serial schedule S12 by swapping non-
conflicting operations of S1
 S1 is conflict serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 40


Conflict Serializable Schedule - Example

Example

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 41


Conflict Serializable Schedule - Example

Example - After swapping of non-conflict operations, the schedule S1 becomes:

T1 T2
Read(A)
Write(A)
Read(B)
Write(B)
Read(A)
Write(A)
Read(B)
Write(B)

Since, S1 is conflict serializable.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 42


View Serializability Schedule

 A schedule will view serializable if it is view equivalent to a serial schedule.


 If a schedule is conflict serializable, then it will be view serializable.
 The view serializable which does not conflict serializable contains blind writes.

View Equivalent
 Two schedules S1 and S2 are said to be view equivalent if they satisfy the
following conditions:
1. Initial Read
2. Updated Read
3. Final Write

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 43


View Serializability Schedule

1. Initial Read
 An initial read of both schedules must be the same.
 Suppose two schedule S1 and S2.
 In schedule S1, if a transaction T1 is reading the data item A, then in S2,
transaction T1 should also read A.

 Above two schedules are view equivalent because Initial read operation in S1 is
done by T1 and in S2 it is also done by T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 44


View Serializability Schedule

2. Updated Read
 In schedule S1, if Ti is reading A which is updated by Tj then in S2 also, Ti
should read A which is updated by Tj.

 Above two schedules are not view equal because, in S1, T3 is reading A
updated by T2 and in S2, T3 is reading A updated by T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 45


View Serializability Schedule

3. Final Write
 A final write must be the same between both the schedules.
 In schedule S1, if a transaction T1 updates A at last then in S2, final writes
operations should also be done by T1.

 Above two schedules is view equal because Final write operation in S1 is done
by T3 and in S2, the final write operation is also done by T3.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 46


View Serializability Schedule - Example

Example : Consider the following schedule S

 With 3 transactions, the total number of possible schedule


 = 3! = 6
 S1 = <T1 T2 T3>
 S2 = <T1 T3 T2>
 S3 = <T2 T3 T1>
 S4 = <T2 T1 T3>
 S5 = <T3 T1 T2>
 S6 = <T3 T2 T1>

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 47


View Serializability Schedule - Example

 Example : Taking first schedule S1 and Compare with schedule S


 schedule S

 schedule S1

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 48


View Serializability Schedule - Example

 Example : Taking first schedule S1 and Compare with schedule S


Step 1: final updation on data items
 In both schedules S and S1, there is no read except the initial read that's why we
don't need to check that condition.
Step 2: Initial Read
 The initial read operation in S is done by T1 and in S1, it is also done by T1.
Step 3: Final Write
 The final write operation in S is done by T3 and in S1, it is also done by T3. So,
S and S1 are view Equivalent.

The first schedule S1 satisfies all three conditions, so we don't need to check
another schedule.
 Hence, view equivalent serial schedule is:
T1 → T2 → T3
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 49
Difference between Serial Schedule and Serializable Schedule

Serializable
Serial Schedule
Schedule

In Serial schedule, transactions will be In Serializable schedule transaction are


executed one after other. executed concurrently.

Serial schedule are less efficient. Serializable schedule are more efficient.

In serial schedule only one transaction In Serializable schedule multiple


executed at a time. transactions can be executed at a time.

Serial schedule takes more time for


In Serializable schedule execution is fast.
execution.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 1- 50

You might also like