Serial and Non‑Serial Schedule

In a DBMS, when multiple transactions run at the same time, the order in which their operations are executed is called a schedule. Depending on how these operations are arranged, schedules are classified mainly into serial and non-serial types.

Understanding serial and non-serial schedules is the first step toward grasping concurrency control and serializability, which ensure that concurrent transactions behave correctly.

What Is a Serial Schedule?

A serial schedule is a schedule in which one transaction executes completely before the next transaction starts.

In other words:

• All operations of transaction T1 are executed first, then

• All operations of transaction T2 are executed after T1 finishes, or vice versa.

There is no interleaving of operations between transactions.

Example of a Serial Schedule

Suppose we have two transactions:

• T1: read(A), write(A)

• T2: read(B), write(B)

A serial schedule of T1 followed by T2:

T1.read(A)
T1.write(A)
T2.read(B)
T2.write(B)

Here, all of T1 completes before any of T2 starts. This is a serial schedule.

Properties of Serial Schedules

• Safe and correct:
  Since transactions do not interfere with each other, serial schedules always preserve consistency.

• No concurrency:
  Only one transaction is “active” at a time, so performance is usually lower.

• Conceptual baseline:
  In concurrency control, other schedules are compared to serial schedules to check if they are “equivalent” in effect.

For beginners, a serial schedule is like a single-file line of transactions: each one finishes its job completely before the next one starts.

What Is a Non-Serial Schedule?

A non-serial schedule is a schedule in which operations of different transactions are interleaved (mixed together).

In real-world database systems, transactions are usually executed concurrently, so the DBMS interleaves their operations to improve performance and resource utilization.

Example of a Non-Serial Schedule

Using the same transactions:

• T1: read(A), write(A)

• T2: read(B), write(B)

A non-serial schedule could be:

T1.read(A)
T2.read(B)
T1.write(A)
T2.write(B)

Here, operations of T1 and T2 are mixed, not grouped together. This is a non-serial schedule.

Properties of Non-Serial Schedules

• Efficient:
  They allow concurrency, so the system feels faster and can handle more transactions at once.

• Not always safe:
  Some non-serial schedules can cause inconsistencies (like lost updates, dirty reads, etc.) if not controlled properly.

• May be serializable:
  Many non-serial schedules are serializable, meaning their effect is the same as some serial schedule, so they are correct even though operations are interleaved.

For beginners, a non-serial schedule is like multiple queues working at once, but the DBMS must ensure that the final result is still logically correct.

Serial vs Non-Serial Schedules

Why the Distinction Matters

• Serial schedules are the simplest, safest form but not practical for performance.

• Non-serial schedules are necessary for concurrency, but only serializable ones should be allowed.

• DBMS uses concurrency control protocols (locking, timestamping, etc.) to allow only non-serial schedules that are serializable, so the system is both efficient and correct.

Summary

In DBMS, serial schedules run transactions one after another with no interleaving, while non-serial schedules mix operations from different transactions. Serial schedules are safe but slow; non-serial schedules are fast but must be serializable to avoid inconsistencies. Concurrency control is the mechanism that lets DBMS allow non-serial but serializable schedules, giving the best balance of performance and correctness.