0% found this document useful (0 votes)
26 views46 pages

DBMS-Chapter 12

DBMS
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views46 pages

DBMS-Chapter 12

DBMS
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

 Systems with large databases and hundreds of

concurrent users executing database transactions.


 Example: Airline Reservations, Banking, Stocks etc
 Single-User System:
 At most one user at a time can use the system.
 Multiuser System:
 Many users can access the system concurrently.
 Multiple users can access databases
simultaneously because of the concept of
multiprogramming.
 Concurrency
 Interleaved processing:
 Concurrent execution of processes is
interleaved in a single CPU
 Parallel processing:
 Processes are concurrently executed in
multiple CPUs.
 A transaction is an executing program that forms a
logical unit of database processing.
 A transaction includes one or more database
access operations like insertion, deletion,
modification or retrieval operations.
 The operations that form a transaction can be a
part of any application program or they can be
specified via high level query language such as
SQL.
 Transaction boundary
Transaction boundary is explicitly specified using
begin transaction and end transaction.

Read-Only Transaction
If the database operations in a transaction does not
update the database but only retrieve the data, the
transaction is called a read-only transaction.

Read-write Transaction
Database operations in a transaction that update the
database.
 Database is represented as a collection of named
data items.
 The size of the data item is called its Granularity.
 A data item can be a database record, whole disk
block, or even a single attribute.
 Each data item has a unique name.
 Basic database operations that a transaction can
include:
 read_item(X): Reads a database item named X
into a program variable. To simplify our notation,
we assume that the program variable is also
named X.
 write_item(X): Writes the value of program
variable X into the database item named X.
 read_item(X) command includes the following
steps:
1. Find the address of the disk block that
contains item X.
2. Copy that disk block into a buffer in main
memory (if that disk block is not already in
some main memory buffer).
3. Copy item X from the buffer to the program
variable named X.
 write_item(X) command includes the following
steps:
 Find the address of the disk block that contains
item X.
 Copy that disk block into a buffer in main
memory (if that disk block is not already in some
main memory buffer).
 Copy item X from the program variable named X
into its correct location in the buffer.
 Store the updated block from the buffer back to
disk (either immediately or at some later point in
time).
 Many transactions may execute concurrently,
access and update the same db items.
 Ifuncontrolled, result in some problems (ie,
inconsistent database)
 The Lost Update Problem
This occurs when two transactions that access the
same database items have their operations
interleaved in a way that makes the value of some
database item incorrect.
Example:
 The Temporary Update (or Dirty Read) Problem
This occurs when one transaction updates a
database item and then the transaction fails for some
reason.
Example:
 Incorrect Summary Problem
Consider a situation, where one transaction is
applying the aggregate function on some records
while another transaction is updating these records.
The aggregate function may calculate some values
before the values have been updated and others
after they are updated.
 The Unrepeatable Read Problem:

This problem may occur when a transaction T reads


the same item twice and the item is changed by
another transaction T’ between the two reads.
 When a transaction is submitted to a DBMS, either
all operations in it are completed successfully and
their effect is recorded permenantly in db
(committed) or transaction has no effect in the db
or any other transactions (transaction is aborted).
 What causes a transaction to fail?
1. A computer Failure ( System Crash)
2. A transaction or System error
3. Local Errors or exception conditions detected
by the transaction
4. Concurrency control enforcement
5. Disk Failure
6. Physical problems and catastrophes
 A transaction is a single logical unit of work which
accesses and possibly modifies the contents of a
database. Transactions access data using read and
write operations.
 In order to maintain consistency in a database,
before and after transaction, certain properties are
followed. These are called ACID properties.
It means that either the entire transaction takes place at
once or doesn’t happen at all. There is no midway i.e.
transactions do not occur partially. Each transaction is
considered as one unit and either runs to completion or
is not executed at all. It involves following two
operations.
 Abort: If a transaction aborts, changes made to
database are not visible.
 Commit: If a transaction commits, changes made
are visible.
Atomicity is also known as the ‘All or nothing rule’.
 A transaction should be consistency preserving,
meaning that if it is completely executed from
beginning to end without interference from other
transactions, it should take the database from one
consistent state to another.
 This means that integrity constraints must be
maintained so that the database is consistent
before and after the transaction. It refers to
correctness of a database.
 Example:
 The total amount before and after the transaction
must be maintained.
Total before T occurs = 500 + 200 = 700.
Total after T occurs = 400 + 300 = 700.
Therefore, database is consistent. Inconsistency
occurs in case T1 completes but T2 fails. As a
result T is incomplete.
 A transaction should appear as though it is being
executed in isolation from other transactions, even
though many transactions are executing
concurrently.
 The changes applied to the database by a
committed transaction must persist in the database.
These changes must not be lost due to any failures.
 Types of schedules that are always considered to
be correct when concurrent transactions are
executing are called as serializable schedules.
 Suppose that two users, for example, two airline
reservations agents submit to the DBMS
transactions T1 and T2 at approximately the same
time.
 If no interleaving of operations is permitted, there
are only two possible outcomes:
 Execute all the operations of transaction T1 (in
sequence) followed by all the operations of
transaction T2 (in sequence).
 Execute all the operations of transaction T2 (in
sequence) followed by all the operations of
transaction T1 (in sequence).
 These two schedules called serial schedules.
 The concept of serializability of schedules is
used to identify which schedules are correct
when transaction executions have interleaving of
their operations in the schedules.
 A schedule S is serial if, for every transaction T
participating in the schedule, all the operations of T
are executed consecutively in the schedule. Else
the schedule is called nonserial.
 In a serial schedule, only one transaction at a time
is active. The commit or abort of the active
transaction initiates the execution of the next
transaction.
 A schedule S of n transactions is serializable if it is
equivalent to some serial schedule of the same n
transactions.
 Two schedules are result equivalent if they produce
the same final database state.
 But it is not true all the time.
 Two schedules are said to be conflict equivalent if
the relative order of any two conflicting operations
is the same in both the schedules.
 Two operations in a schedule are said to conflict if
they belong to different transactions, access the
same database item and either both are write_item
operations or one is write_item and the other one
is read_item.
 If two conflicting operations are applied in different
orders in two schedules, the effect can be different
on the database, and hence they are not conflict
equivalent.
 A schedule S is said to be serializable if it is
equivalent to some serial schedule S’.
 An algorithm can be used to test a schedule for
conflict serializability.
 The algorithm looks only at read_item and
write_item operations in a schedule to construct a
precedence graph which is a directed graph
G=(N,E) that consists of a set of nodes N ={
T1,T2......Tn} and a set of directed edges
E={e1,e2.....em}.
 Each edge ei in the graph id of the form (TjTk),
where Tj is the starting node ei, and Tk is the
ending node of ei.
1. For each transaction Ti participating in schedule S,
create a node labelled Ti in the precedence graph.
2. For each case in S where Tj executes a read_item(X)
after Ti executes a write_item(X), create an edge (Ti
 Tj) in the precedence graph.
3. For each case in S where Tj executes a Write_item(X)
after Ti executes a read_item(X), create an edge (Ti
 Tj) in the precedence graph.
4. For each case in S where Tj executes a write_item(X)
after Ti executes a write_item(X), create an edge (Ti
 Tj) in the precedence graph.
5. The schedule S is serializable if and only if the
precedence graph has no cycles.
T1 T2 T3
R(X)
R(Z)
W(Z)
R(Y)
R(Y)
W(Y)
W(X)
W(Z)
W(X)
T1 T2 T3
R(X)
R(Y)
R(Y)
W(Y)
W(X)
W(X)
R(X)
W(X)
T1 T2 T3
R(Z)
R(Y)
W(Y)
R(Y)
R(Z)
R(X)
W(X)
W(Y)
W(Z)
R(X)
R(Y)
W(Y)
W(X)
T1 T2 T3
R(Y)
R(Z)
R(X)
W(X)
W(Y)
W(Z)
R(Z)
R(Y)
W(Y)
R(Y)
W(Y)
R(X)
W(X)
T1 T2
R(X)
W(X)
R(Y)
W(Y)
R(X)
W(X)
T1 T2
R(X)
W(X)
R(X)
W(X)
R(Y)
W(Y)
T1 T2
R(X)
R(X)
W(X)
R(Y)
W(X)
W(Y)
T1 T2
R(X)
W(X)
R(X)
W(X)
R(Y)
W(Y)
 A serial schedule represents inefficient processing
because no interleaving of operations from
different transactions is permitted. This can lead to
low CPU utilization while a transaction waits for
disk I/O, or for another transaction to terminate,
thus slowing down processing considerably. A
serializable schedule gives the benefits of
concurrent execution without giving up any
correctness.
 In practice, it is quite difficult to test for the
serializability of a schedule. The interleaving of
operations from concurrent transactions which are
usually executed as processes by the operating
system is typically determined by the operating
system scheduler, which allocates resources to all
processes.
 Two schedules are said to be view equivalent if the
order of initial read, final write and update
operations is the same in both the schedules.
 Two schedules S1 and S2 are said to be view-
equivalent if below conditions are satisfied :
 Initial Read: If a transaction T1 reading data item
A from initial database in S1 then in S2 also T1
should read A from initial database.
 Updated Read: If Ti is reading A which is
updated by Tj in S1 then in S2 also Ti should read
A which is updated by Tj.
 Final Write operation: If a transaction T1
updated A at last in S1, then in S2 also T1 should
perform final write operations.
 A schedule S is said to be view serializable if it is
view equivalent to a serial schedule.
 Conflict Serializability and view serializability are
similar if a condition known as Blind Write holds on
all transactions in a schedule.
 Blind Write: It is a write operation in a transaction T
on an item X that is not dependent on the old value
of X, so it is not preceded by a read of X in the
transaction T.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy