Chapter One

Transaction: A transaction is a set of logically related operations performed by a single user

to access the contents of a database. It consists of a group of tasks that are performed together.
Cont…
 For example, let's consider a transaction where an employee of a bank transfers Rs 800
from X's account to Y's account. This transaction involves multiple tasks for each account:
 X's Account:
1. Open_Account(X)
2. Retrieve the old balance value: Old_Balance = X.balance
3. Calculate the new balance after deduction: New_Balance = Old_Balance - 800
4. Update X's balance with the new value: X.balance = New_Balance
5. Close_Account(X)
 Y's Account:
1. Open_Account(Y)
2. Retrieve the old balance value: Old_Balance = Y.balance
3. Calculate the new balance after addition: New_Balance = Old_Balance + 800
4. Update Y's balance with the new value: Y.balance = New_Balance
5. Close_Account(Y)
Cont…
 The main operations of a transaction include Read(X) and Write(X):
 Read(X): It retrieves the value of X from the database and stores it in a buffer in the main memory.
 Write(X): It writes the value from the buffer back to the database.
 In the example of a debit transaction, the operations involved are:
 Read(X): Retrieve the value of X from the database and store it in a buffer.
 X = X - 500: Decrease the value of X by 500 in the buffer.
 Write(X): Write the updated value from the buffer back to the database.
 If a transaction fails due to hardware, software, or power failures before completing all the
operations, it can lead to inconsistencies in the database. To address this issue, two important
operations are used:
 Commit: This operation saves the work done by a transaction permanently, making the changes
visible to other users.
 Rollback: This operation undoes the work done by a transaction, reverting the changes made.
 These operations play a crucial role in ensuring data integrity and maintaining the consistency of
the database.
Operations of Transaction
 Following are the main operations of transaction:
 Read(X): Read operation is used to read the value of X from the database and stores it in a
buffer in main memory.
 Write(X): Write operation is used to write the value back to the database from the buffer. Let's
take an example to debit transaction from an account which consists of following operations:
 In the given example transaction, the following operations are performed on X with an initial
value of 4000:
 1. Read(X): Retrieves the value of X from the database and stores it in a buffer.
 2. X = X - 500: Decreases the value of X by 500, resulting in a buffer value of 3500.
 3. Write(X): Writes the value from the buffer (3500) back to the database, making X's final
value 3500.
 However, there is a possibility of transaction failure due to hardware, software, power issues,
etc., before completing all the operations. In such cases, the transaction may not be able to make
the necessary changes to the database.
Cont…
 To address this problem, two important operations are used:
 1. Commit: This operation saves the work done by a transaction permanently. It ensures that the
changes made by the transaction are applied to the database.
 2. Rollback: This operation undoes the work done by a transaction. It reverts the changes made by the
transaction, bringing the database back to its previous state.
 Additionally, transactions have four properties that help maintain consistency in a database:
 1. Atomicity: Ensures that a transaction is treated as a single unit, where either all its operations are
fully completed or none are applied at all.
 2. Consistency: Ensures that a transaction brings the database from one consistent state to another,
adhering to integrity constraints and rules defined on the database.
 3. Isolation: Ensures that concurrent transactions do not interfere with each other, providing the
illusion of executing transactions in isolation.
 4. Durability: Guarantees that once a transaction is committed, its changes are permanent and will
survive subsequent failures, ensuring data persistence.
 These transaction properties work together to maintain the reliability, integrity, and consistency of the
database, even in the presence of failures or concurrent access.
Cont…
 Atomicity: Atomicity states that a transaction must be treated as a single, indivisible unit of work. All operations
within the transaction must either be executed completely or not executed at all. There are two outcomes: abort, where
no changes made within the transaction are visible, and commit, where all changes made within the transaction are
visible.
T1 T2

Read(A) Read(B)
A:= A-100 Y:= Y+100
Write(A) Write(B)

Example: Let's assume that following transaction T consisting of T1 and T2. A consists of Rs 600 and B
consists of Rs 300. Transfer Rs 100 from account A to account B.
After completion of the transaction, A consists of Rs 500 and B consists of Rs 400.
If the transaction T fails after the completion of transaction T1 but before completion of transaction T2,
then the amount will be deducted from A but not added to B. This shows the inconsistent database state.
In order to ensure correctness of database state, the transaction must be executed in entirety.

 Consistency: Consistency ensures that the integrity constraints of the database are maintained before and after the
transaction. The execution of a transaction should leave the database in a stable state, either the previous stable state or
a new stable state. Transactions should operate on a consistent database instance and transform it from one consistent
state to another.
Cont…
 For example: The total amount must be maintained before or after the transaction.
 Total before T occurs = 600+300=900
 Total after T occurs= 500+400=900
 Therefore, the database is consistent. In the case when T1 is completed but T2 fails, then
inconsistency will occur.
 Isolation: Isolation ensures that the data accessed by one transaction cannot be accessed
by another transaction until the first transaction is completed. Transactions must be
executed in isolation to prevent interference or conflicts with other transactions. The
concurrency control subsystem enforces the isolation property.
 Durability: Durability guarantees that once a transaction is completed and the database
reaches a consistent state, the changes made by the transaction are permanent and will not
be lost even in the event of system failures or faulty transactions. The recovery subsystem
is responsible for maintaining the durability property.
State of Transaction
 In a database, transactions can exist in various states:

 Active state: The initial state of a transaction where it is being executed. Changes made are not yet saved to
the database.

 Partially committed state: The transaction executes its final operation, but the data is still not permanently
saved to the database. For example, in a total mark calculation, the final display of total marks is done in this
state.

 Committed state: A transaction is considered committed if it successfully completes all its operations. In this
state, all effects of the transaction are permanently saved in the database.

 Failed state: If any checks performed by the database recovery system fail, the transaction enters the failed
state. For instance, if a query to fetch marks fails in the total mark calculation example.

 Aborted state: When a transaction fails and enters the failed state, the database recovery system restores the
database to its previous consistent state. If necessary, the executed transactions are rolled back. The recovery
module may choose to restart or kill the transaction after aborting it.
DBMS Schedule

A DBMS schedule refers to a series of operations between transactions that preserves the
order of operations within each transaction. There are different types of schedules:
1. Serial Schedule: In a serial schedule, transactions are executed one after another without
interleaving their operations. The first transaction completes before the next one starts.
Two possible outcomes are executing all operations of T1 followed by T2 or vice versa.
2. Non-serial Schedule: In a non-serial schedule, interleaving of operations is allowed
between transactions. There are multiple possible orders in which operations can be
executed. Schedule C and Schedule D in Figure (c) and (d) show non-serial schedules with
interleaved operations.
3. Serializable Schedule: Serializable schedules are non-serial schedules that allow
concurrent execution of transactions without interference. They determine which schedules
are correct when transaction operations are interleaved. A non-serial schedule is considered
serializable if its result is the same as the result of executing the transactions serially.
Testing of Serializability
 The testing of serializability involves the use of a serialization graph to analyze a schedule.
Here is a summary of the topic:
 To test the serializability of a schedule, a serialization graph is constructed. Given a
schedule S, a precedence graph is created, denoted as G = (V, E). V represents the set of
vertices, which contains all transactions participating in the schedule. E represents the set
of edges, which contains edges Ti -> Tj that satisfy one of three conditions:
 If transaction Ti executes a write (Q) before transaction Tj executes a read (Q), a node Ti -
> Tj is created in the graph.
 If transaction Ti executes a read (Q) before transaction Tj executes a write (Q), a node Ti -
> Tj is created.
 If transaction Ti executes a write (Q) before transaction Tj executes a write (Q), a node Ti -
> Tj is created.
 By examining the serialization graph, the serializability of the schedule can be determined.
Cont…

 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.
 Page 11 up to 21 (note didn’t include).
Failure Classification:

 Failures in a system can be categorized into the following types:

1. Transaction failure:
Occurs when a transaction fails to execute or reaches a point where it cannot proceed further.
Logical errors: Transaction cannot complete due to code errors or internal error conditions.
Syntax error: The DBMS terminates an active transaction, for example, in cases of deadlock or
resource unavailability.
2. System crash:
System failure caused by power failure, hardware or software failures, or operating system errors.
Fail-stop assumption: Non-volatile storage is assumed to remain uncorrupted during a system crash.
3. Disk failure:
 Failures of hard-disk drives or storage drives, often caused by bad sectors, disk head crashes, or
other issues that result in data loss.
Log-Based Recovery

 The log is a sequence of records used for recovery purposes, maintaining a transaction's actions in a stable
storage.
 Operations performed on the database are recorded in the log.
 Logging should occur before the actual transaction is applied to the database.
 Recovery using Log records:
 When a system crash occurs, the log is consulted to determine which transactions need to be undone or redone.
 If the log contains the records <Ti, Start> and <Ti, Commit> or <Ti, Commit>, Transaction Ti needs to be redone.
 If the log contains the record <Ti, Start> but does not contain either <Ti, commit> or <Ti, abort>, Transaction Ti
needs to be undone.
 Database Modification Approaches:
1. Deferred database modification:
 Database modification occurs only after the transaction has committed.
 Logs are created and stored in stable storage, and the database is updated upon transaction commit.
2. Immediate database modification:
 Database modification occurs while the transaction is still active.
 The database is modified immediately after each operation, following the actual database modification approach.
Recovery using Log records:

 During a system crash, the log is utilized to determine which transactions need to be
undone and redone.
1. If the log contains the record <Ti, Start> and <Ti, Commit> or <Ti, Commit>, Transaction
Ti needs to be redone.
2. If the log contains the record <Ti, Start> but does not contain either <Ti, commit> or <Ti,
abort>, Transaction Ti needs to be undone.
DBMS Checkpoint
 Checkpoint is a mechanism in which previous logs are removed from the system and
permanently stored in the storage disk.
 Checkpoints serve as bookmarks during transaction execution. As the transaction
progresses, log files are created based on the transaction steps.
 When reaching a checkpoint, the transaction is updated in the database, and the entire log
file up to that point is removed. The log file is then updated with the new transaction steps
until the next checkpoint, and so on.
 Checkpoints establish a point where the DBMS was in a consistent state and all
transactions were committed.
Recovery using Checkpoint
 In the following manner, a recovery system recovers the database from this failure: