Schedule in DBMS

• A schedule is defined as an execution sequence of

transactions.
• A schedule maintains the order of the operation in each
individual transaction.
• A schedule is the arrangement of transaction
operations. A schedule may contain a set of
transactions.
• We already know that a transaction is a set of
operations. To run transactions concurrently, we
arrange or schedule their operations in an interleaved
fashion.
• In DBMS, schedules may be classified as-
Serial Schedules-

In serial schedules,
• All the transactions execute serially one after the
other.
• When one transaction executes, no other
transaction is allowed to execute.

• Characteristics-
Serial schedules are always-
• Consistent
• Recoverable
• Cascadeless
• Strict
 In this schedule,
• There are two transactions T1 and T2 executing serially In this schedule,
one after the other. • There are two transactions T1 and T2 executing serially
• Transaction T1 executes first. one after the other.
• • Transaction T2 executes first.
After T1 completes its execution, transaction T2 executes.
• So, this schedule is an example of a Serial Schedule. • After T2 completes its execution, transaction T1 executes.
• So, this schedule is an example of a Serial Schedule.
• Non-Serial Schedules-

• In non-serial schedules,
• Multiple transactions execute concurrently.
• Operations of all the transactions are inter leaved or mixed with each
other.
•
• Characteristics-

• Non-serial schedules are NOT always-

• Consistent
• Recoverable
• Cascadeless
• Strict
 In this schedule, In this schedule,
• There are two transactions T1 and T2 executing • There are two transactions T1 and T2 executing
concurrently. concurrently.
• The operations of T1 and T2 are interleaved. • The operations of T1 and T2 are interleaved.
• So, this schedule is an example of a Non-Serial • So, this schedule is an example of a Non-Serial
Schedule. Schedule.
• Serializability in DBMS-
• Some non-serial schedules may lead to inconsistency of the
database.
• Serializability is a concept that helps to identify which non-
serial schedules are correct and will maintain the consistency
of the database.
• 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.
• Serializable Schedules-
• If a given non-serial schedule of ‘n’ transactions is equivalent to
some serial schedule of ‘n’ transactions, then it is called as
a serializable schedule.
• Characteristics-
• Serializable schedules behave exactly same as serial
schedules.
• Thus, serializable schedules are always-
• Consistent
• Recoverable
• Casacadeless
• Strict
Serial Schedules Vs Serializable Schedules-

Serial Schedules Serializable Schedules

No concurrency is allowed.
Thus, all the Concurrency is allowed.
transactions necessarily Thus, multiple transactions
execute serially one after the can execute concurrently.
other.
Serializable
Serial schedules lead to less
schedules improve both
resource utilization and CPU
resource utilization and CPU
throughput.
throughput.
Serial Schedules are less Serializable Schedules are
efficient as compared to always better than serial
serializable schedules. schedules.
(due to above reason) (due to above reason)
 Types of Non serial schedules
Non serial schedules are divided into serializability and the Non serial schedules. Let us first
discuss serializability.
There are two types of serializability which are as follows −

1. Conflict Serializable:
A schedule is called conflict serializable if it can be transformed into a serial schedule by swapping non-
conflicting operations. Two operations are said to be conflicting if all conditions satisfy:
1. They belong to different transactions
2. They operate on the same data item
3. At Least one of them is a write operation

Example:
Swapping is possible only if S1 and S2 are logically equal.
Example:
Swapping is possible only if S1 and S2 are logically equal.

Here, S1 = S2. That means it is non-conflict. Here, S1 ≠ S2. That means it is conflict.
 • Conflict Equivalent
• In the conflict equivalent, one can be transformed to
another by swapping non-conflicting operations. In the
given example, S2 is conflict equivalent to S1 S1 can be
converted to S2 by swapping non-conflicting operations).
• Two schedules are said to be conflict equivalent if and only
if:
1. They contain the same set of the transaction.
2. If each pair of conflict operations are ordered in the same
way.
 • Conflict Equivalent After swapping of non-conflict operations, the
schedule S1 becomes:
• Example:
T1 T2

Read(A)
Write(A)
Read(B)
Write(B)
Read(A)
Write(A)
Read(B)
Write(B)

Schedule S2 is a serial schedule because, in this, all Since, S1 is conflict serializable.

operations of T1 are performed before starting any
operation of T2. Schedule S1 can be transformed into
a serial schedule by swapping non-conflicting
operations of S1.
 View serializability
A schedule is view-serializability if it is
view equivalent to a serial schedule.
View Equivalent Schedules-
• If a schedule is conflict serializable, then it
will be view serializable.
 View Equivalent
Two schedules S1 and S2 are said to be view
equivalent if they satisfy the following conditions:
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 not view equal

because, in S1, T3 is reading A updated by T2
and in S2, T3 is reading A updated by T1.

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.
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.
 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.
 1. = 3! 6
Example: 2. S1 T1 T2 T3
3. S2 T1 T3 T2
4. S3 T2 T3 T1
5. S4 T2 T1 T3
6. S5 T3 T1 T2
7. S6 T3 T2 T1
Taking first schedule S1

Schedule S
With 3 transactions, the total number of
possible schedule

Total number of serial schedules

= Number of different ways of arranging n
transactions
= n!
 Example:
Schedule S1
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.
1. S1 T1 T2 T3 The first schedule S1 satisfies all three conditions, so
Taking first schedule S1 we don't need to check another schedule.
Hence, view equivalent serial schedule is:
T1 → T2 → T3