This document discusses transaction management in relational database management systems. It covers topics such as ACID properties, transaction failures including logical errors and system crashes, recovery with concurrent transactions using redo and undo lists, checkpoints, shadow paging using two page tables, and buffer management involving logging records and database blocks.

1. RELATIONAL DATABASE MANAGEMENT SYSTEM
TRANSACTION MANAGEMENT
By,
S.Subhalakshmi,
M.Sc(cs).
Nadar saraswathi college of arts and science.

2. TRANSACTION MANAGEMENT:
 A Transaction is a very small unit of a program and it
may contain several low level tasks.
 A Transaction in a database system must maintain
Atomicity, Consistency, Isolation, and Durability − commonly
known as ACID properties.
 In order to ensure accuracy, completeness, and data
integrity.

3. FAILURE CLASSIFICATION:
 The simplest type of failure is one that does not result
in the loss of information in the system.
 There are various types of failure that may occur in a
system.
 The failures that are more difficult to deal with are
those that result in loss of information.
 The following types of failures are:

4. TRANSACTION FAILURE:
 There are two types of errors that may cause a transaction to
fail:
 LOGICAL ERROR :transaction cannot complete due to
some internal error condition.
 SYSTEM ERROR: the database system must terminate an
active transaction due to an error condition (e.g., deadlock).

5.  SYSTEM CRASH: a power failure or other hardware or
software failure causes the system to crash.
 FAIL-STOPASSUMPTION: non-volatile storage contents
are assumed to not be corrupted by system crash.
 DISK FAILURE: a head crash or similar disk failure destroys
all or part of disk storage.
 DESTRUCTION IS ASSUMED TO BE
DETECTABLE: disk drives use checksums to detect failures.

6. RECOVERY WITH CONCURRENT
TRANSACTIONS :
 We modify the log-based recovery schemes to allow
multiple transactions to execute concurrently.
 All transactions share a single disk buffer and a single
log.
 A buffer block can have data items updated by one or
more transactions.

7. CHECKPOINTS:
 We modify the log-based recovery schemes to allow multiple
transactions to execute concurrently.
 All transactions share a single disk buffer and a single log
 A buffer block can have data items updated by one or more
transactions.
 Streamline recovery procedure by periodically performing
check pointing.

8. RESTART RECOVERY:
 When the system recovers from a crash, it constructs two list:
 The undo-list consists of transaction to be done.
 The system constructs the two lists as follows:
 Initially, they are both empty.
 The system scans the log backward, examining each record, until
it finds the first <checkpoint> record:

9.  For each record found of the form<Ti commit>,it adds Ti to redo-
list.
 For each record found of the form<Ti start>,if Ti is not in redo-
list, then it adds Ti to undo-list.
 When the system has examined all the appropriate log records, it
checks the list L in the checkpoint record.
 For each transaction Ti in L, if Ti is not in redo-list, then it adds
Ti to undo-list.

10. SHADOW PAGING:
 Shadow paging is an alternative to log-based recovery.
 IDEA: maintain two page tables during the lifetime of a
transaction .
 Store the shadow page table in nonvolatile storage, such that state
of the database prior to transaction execution may be recovered.
 Only current page table is used for data item accesses during
execution of the transaction.

12.  TO COMMIT A TRANSACTION :
1. Flush all modified pages in main memory to disk
2. Output current page table to disk
3. Make the current page table the new shadow page table, as
follows:
 keep a pointer to the shadow page table at a fixed (known)
location on disk.
 to make the current page table the new shadow page table,
simply update the pointer to point to current page table on disk.

13.  BUFFER MANAGEMENT:
 LOG RECORD BUFFERING: log records are buffered in
main memory, instead of being output directly to stable storage.
 Log force is performed to commit a transaction by forcing all its
log records (including the commit record) to stable storage.
 Several log records can thus be output using a single output
operation, reducing the I/O cost.

14.  DATABASE BUFFERING :
 Database maintains an in-memory buffer of data blocks.
 When a new block is needed, if buffer is full an existing block
needs to be removed from buffer.
 If the block chosen for removal has been updated, it must be
output to disk.
 If a block with uncommitted updates is output to disk, log
records with undo information for the updates are output to the
log on stable storage first.

15.  OPERATING SYSTEM ROLE IN BUFFER
MANAGEMENT:
 We can manage the database buffer by using one of this
approaches:
 The database system reserves part of main memory to serve as a
buffer that it, rather than the operating system, manages.
 The database system implements its buffer within the virtual
memory provided by the operating system.
 The database system in turn force-output the buffer blocks to the
database, after writing relevant log records to stable storage.

16.  Unfortunately, almost all current-generation operating systems
retain complete control of virtual memory.
 The operating system reserves space on disk for storing virtual-
memory pages that are not currently in main memory ; this space
is called swap space.
 Although both approaches suffer from some drawbacks, one or
the other must be chosen unless the operating system is designed
to support the requirements of database logging.