2. What is a Transaction?What is a Transaction?
īA logical unit of work on a database
âĻ An entire program
âĻ A portion of a program
âĻ A single command
īThe entire series of steps necessary to
accomplish a logical unit of work
īSuccessful transactions change the database
from one CONSISTENT STATE to another
(One where all data integrity constraints are
satisfied)
3. Example of a TransactionExample of a Transaction
īUpdating a Record
âĻ Locate the Record on Disk
âĻ Bring record into Buffer
âĻ Update Data in the Buffer
âĻ Writing Data Back to Disk
4. 4 Properties of a Transaction4 Properties of a Transaction
īAtomic â All or Nothing
All parts of the transaction must be
completed and committed or it must be
aborted and rolled back
īConsistent
Each user is responsible to ensure that
their transaction (if executed by itself)
would leave the database in a consistent
state
5. 4 Properties of a Transaction4 Properties of a Transaction
īIsolation
The final effects of multiple simultaneous
transactions must be the same as if they
were executed one right after the other
īDurability
If a transaction has been committed, the
DBMS must ensure that its effects are
permanently recorded in the database
(even if the system crashes)
6. Transaction Management with SQLTransaction Management with SQL
ī SQL Statements ī Commit / Rollback
ī When a transaction sequence is initiated it
must continue through all succeeding SQL
statements until:
1. A Commit Statement is Reached
2. A Rollback Statement is Reached
3. The End of the Program is Reached (Commit)
4. The Program is Abnormally Terminated
(Rollback)
7. ExampleExample
BEGIN TRAN
DECLARE @ErrorCode INT, @TranSuccessful INT
SET @TranSuccessful = 1
INSERT INTO tblCatalog (CatalogYear)
VALUES('2002')
SET @ErrorCode = @@ERROR; IF (@ErrorCode <> 0) SET @TranSuccessful
= 0 âFalse
INSERT INTO tblCatalog (CatalogYear)
VALUES('2003')
SET @ErrorCode = @@ERROR; IF (@ErrorCode <> 0) SET @TranSuccessful
= 0 âFalse
IF @TranSuccessful = 0
BEGIN
ROLLBACK TRAN
RAISERROR ('Rolledback transaction: Insert Catalog Year.',
16,1)
END
ELSE
BEGIN
COMMIT TRAN
PRINT 'Successfully inserted catalog years...'
END
GO
8. Transaction LogTransaction Log
īKeeps track of all transactions that update the
database
âĻ Record for the beginning of the transaction
âĻ Type of operation (insert / update / delete)
âĻ Names of objects/tables affected by the transaction
âĻ Before and After Values for Updated Fields
âĻ Pointers to Previous and Next Transaction Log
Entries for the same transaction
âĻ The Ending of the Transaction (Commit)
īUsed for recovery in case of a Rollback
9. Concurrency ControlConcurrency Control
īCoordination of simultaneous transaction
execution in a multiprocessing database
system
īEnsure transaction serializability in a
multi-user database
īLack of Concurrency Control can create
data integrity and consistency problems:
âĻ Lost Updates
âĻ Uncommitted Data
âĻ Inconsistent Retrievals
10. Lost UpdatesLost Updates
TimTim
ee
Jackâs TransJackâs Trans Jillâs TransJillâs Trans BalanceBalance
T1T1 BeginBegin
T2T2 Read BalanceRead Balance BeginBegin 10001000
T3T3 Read BalanceRead Balance 10001000
T4T4 Bal = Bal â 50Bal = Bal â 50
(950)(950)
10001000
T5T5 Write Bal (950)Write Bal (950) Bal = Bal + 100Bal = Bal + 100
(1100)(1100)
950950
T6T6 CommitCommit 950950
T7T7 Write Bal (1100)Write Bal (1100) 11001100
T8T8 CommitCommit 11001100
11. Uncommitted DataUncommitted Data
TimeTime DepositDeposit InterestInterest BalBal
T1T1 Begin TransactionBegin Transaction 10001000
T2T2 Read Bal (1000)Read Bal (1000) 10001000
T3T3 Bal = Bal + 1000 (2000)Bal = Bal + 1000 (2000) 10001000
T4T4 Write Bal (2000)Write Bal (2000) Begin TransactionBegin Transaction 20002000
T5T5 Read Bal (2000)Read Bal (2000) 20002000
T6T6 Bal = Bal*1.05 (2100)Bal = Bal*1.05 (2100) 20002000
T7T7 RollbackRollback 10001000
T8T8 Write Bal (2100)Write Bal (2100) 21002100
T9T9 CommitCommit 21002100
12. Inconsistent RetrievalsInconsistent Retrievals
TimeTime SumBalSumBal TransferTransfer Bal ABal A Bal BBal B Bal CBal C SumSum
T1T1 Begin TransBegin Trans 50005000 50005000 50005000
T2T2 Sum = 0Sum = 0 Begin TransBegin Trans 50005000 50005000 50005000
T3T3 Read BalA (5000)Read BalA (5000) 50005000 50005000 50005000
T4T4 Sum = Sum +Sum = Sum +
BalA (5000)BalA (5000)
Read BalA (5000)Read BalA (5000) 50005000 50005000 50005000
T5T5 Read BalB (5000)Read BalB (5000) BalA = BalA -1000 (4000)BalA = BalA -1000 (4000) 50005000 50005000 50005000
T6T6 Sum = Sum+BalBSum = Sum+BalB
(10000)(10000)
Write BalA (4000)Write BalA (4000) 40004000 50005000 50005000
T7T7 Read BalCRead BalC 40004000 50005000 50005000
T8T8 BalC =BalC + 1000 (6000)BalC =BalC + 1000 (6000) 40004000 50005000 50005000
T9T9 Write BalC (6000)Write BalC (6000) 40004000 50005000 60006000
T10T10 Read BalCRead BalC CommitCommit 40004000 50005000 60006000
T11T11 Sum=Sum + BalCSum=Sum + BalC
(16000)(16000)
40004000 50005000 60006000
T12T12 Write Sum (16000)Write Sum (16000) 40004000 50005000 60006000 1600016000
T13T13 CommitCommit 40004000 50005000 60006000 1600016000
13. Serial Execution of TransactionsSerial Execution of Transactions
īSerial Execution of transaction means
that the transactions are performed one
after another.
īNo interaction between transactions -
No Concurrency Control Problems
īSerial Execution will never leave the
database in an inconsistent state ī Every
Serial Execution is considered correct
(Even if a different order would cause
different results)
14. SerializabilitySerializability
īIf 2 Transactions are only reading data items
â They do not conflict ī Order is
unimportant
īIf 2 Transactions operate (Read/Write) on
Separate Data Items
â They do not conflict ī Order is
unimportant
īIf 1 Transaction Writes to a Data Item and
Another Reads or Writes to the Same Data
Item ī The Order of Execution IS
Important
15. The SchedulerThe Scheduler
īSpecial DBMS Program to establish the
order of operations in which concurrent
transactions are executes
īInterleaves the execution of database
operations to ensure:
Serializability
Isolation of Transactions
16. The SchedulerThe Scheduler
īBases its actions on Concurrency
Control Algorithms (Locking / Time
Stamping)
īEnsures the CPU is used efficiently
(Scheduling Methods)
īFacilitates Data Isolation ī Ensure that 2
transactions do not update the same data
at the same time
17. Concurrency Control AlgorithmsConcurrency Control Algorithms
īLocking
A Transaction âlocksâ a database object to
prevent another object from modifying the
object
īTime-Stamping
Assign a global unique time stamp to each
transaction
īOptimistic
Assumption that most database
operations do not conflict
18. LockingLocking
īLock guarantees exclusive use of data
item to current transaction
īPrevents reading Inconsistent Data
īLock Manager is responsible for assigning
and policing the locks used by the
transaction
19. Locking GranularityLocking Granularity
Indicates the level of lock use
īDatabase Level â Entire Database is
Locked
īTable Level â Entire Table is Locked
īPage Level â Locks an Entire Diskpage
(Most Frequently Used)
īRow Level â Locks Single Row of Table
īField Level â Locks a Single Attribute of a
Single Row (Rarely Done)
20. Types of Locks:Types of Locks:
BinaryBinary
īBinary Locks â Lock with 2 States
âĻ Locked â No other transaction can use that object
âĻ Unlocked â Any transaction can lock and use object
All Transactions require a Lock and Unlock Operation
for Each
Object Accessed (Handled by DBMS)
âĻ Eliminates Lost Updates
âĻ Too Restrictive to Yield Optimal Concurrency
Conditions
21. Types of Locks:Types of Locks:
Shared / Exclusive LocksShared / Exclusive Locks
ī Indicates the Nature of the Lock
ī Shared Lock â Concurrent Transactions are granted
READ access on the basis of a common lock
ī Exclusive Lock â Access is reserved for the transaction
that locked the object
ī 3 States: Unlocked, Shared (Read), Exclusive (Write)
ī More Efficient Data Access Solution
ī More Overhead for Lock Manager
âĻ Type of lock needed must be known
âĻ 3 Operations:
ī Read_Lock â Check to see the type of lock
ī Write_Lock â Issue a Lock
ī Unlock â Release a Lock
âĻ Allow Upgrading / Downgrading of Locks
22. Problems with LockingProblems with Locking
īTransaction Schedule May Not be
Serializable
âĻ Can be solved with 2-Phase Locking
īMay Cause Deadlocks
âĻ A deadlock is caused when 2 transactions
wait for each other to unlock data
23. Two Phase LockingTwo Phase Locking
ī Defines how transactions Acquire and
Relinquish Locks
1. Growing Phase â The transaction acquires all
locks (doesnât unlock any data)
2. Shrinking Phase â The transaction releases
locks (doesnât lock any additional data)
ī Transactions acquire all locks it needs until it
reaches locked point
ī When locked, data is modified and locks are
released
24. DeadlocksDeadlocks
īOccur when 2 transactions exist in the
following mode:
T1 = access data item X and Y
T2 = Access data items Y and X
If T1 does not unlock Y, T2 cannot begin
If T2 does not unlock X, T1 cannot continue
T1 & T2 wait indefinitely for each other to unlock
data
īDeadlocks are only possible if a transactions
wants an Exclusive Lock (No Deadlocks on
Shared Locks)
25. Controlling DeadlocksControlling Deadlocks
īPrevention â A transaction requesting a new
lock is aborted if there is the possibility of a
deadlock â Transaction is rolled back, Locks are
released, Transaction is rescheduled
īDetection â Periodically test the database for
deadlocks. If a deadlock is found, abort /
rollback one of the transactions
īAvoidance â Requires a transaction to obtain all
locks needed before it can execute â requires
locks to be obtained in succession
26. Time StampingTime Stamping
ī Creates a specific order in which the transactions are
processed by the DBMS
ī 2 Main Properties
1. Uniqueness â Assumes that no equal time stamp value can
exist (ensures serializability of the transactions)
2. Monotonicity â Ensures that time stamp values always
increases
ī All operations within the same transaction have the
same time stamp
ī If Transactions conflict, one is rolled back and
rescheduled
ī Each value in Database requires 2 Additional Fields:
Last Time Read / Last Time Updated
ī Increases Memory Need and Processing Overhead
27. Time Stamping SchemesTime Stamping Schemes
īWait / Die Scheme
The older transaction will wait
The younger transaction will be rolled back
īWound / Wait Scheme
The older transaction will preempt (wound)
the younger transaction and roll it
back
The younger transaction waits for the older
transaction to release the locks
īWithout time-out values, Deadlocks may be
created
28. Optimistic MethodOptimistic Method
īMost database operations do not conflict
īNo locking or time stamping
īTransactions execute until commit
âĻ Read Phase â Read database, execute computations,
make local updates (temporary update file)
âĻ Validate Phase â Transaction is validated to ensure
changes will not effect integrity of database
ī If Validated ī Go to Write Phase
ī If Not Validated ī Restart Transaction and discard initial
changes
âĻ Write Phase â Commit Changes to database
īGood for Read / Query Databases (Few
Updates)
29. Database RecoveryDatabase Recovery
ī Restore a database from a given state to a previous
consistent state
ī Atomic Transaction Property (All or None)
ī Backup Levels:
âĻ Full Backup
âĻ Differential Backup
âĻ Transaction Log Backup
ī Database / System Failures:
âĻ Software (O.S., DBMS, Application Programs, Viruses)
âĻ Hardware (Memory Chips, Disk Crashes, Bad Sectors)
âĻ Programming Exemption (Application Program rollbacks)
âĻ Transaction (Aborting transactions due to deadlock detection)
âĻ External (Fire, Flood, etc)
30. Transaction RecoveryTransaction Recovery
ī Recover Database by using data in the Transaction Log
ī Write-Ahead-Log â Transaction logs need to be written
before any database data is updated
ī Redundant Transaction Logs â Several copies of log on
different devices
ī Database Buffers â Buffers are used to increase
processing time on updates instead of accessing data on
disk
ī Database Checkpoints â Process of writing all updated
buffers to disk ī While this is taking place, all other
requests are not executes
âĻ Scheduled several times per hour
âĻ Checkpoints are registered in the transaction log
Editor's Notes
A transaction log is a database â therefore it is managed by the DBMS like any other database. It is subject to database dangers like disk crashes. The transaction log contains some of the most critical data in a DBMS â attempts to reduce the risk of system failure should be implemented.
SumBal finds the sum of the balances of all three accounts â it does NOT UPDATE the account, but reads them
Transfer will transfer 1000 from Account A to Account C
Transfer Transaction executes correctly, however, the SumBal adds the same $1000 twice â once in A and Once in C
2 Operations conflict IF ALL of the following are true:
They belong to different transactions
They access the same data item
At least one of them writes the item
Most DBMSâs automatically initiate and enforce locking procedures through the lock manager
Database Level â Good for batch processing, bad for multiuser databases
Table Level â the table is locked, no access to any rows in table with another transaction is using table. Caused problems with many transactions are waiting to access the same table â again not suitable for multi-user databases
Page Level â A diskpage (page) / diskblock is a directly addressable section of a disk. A page has a fixed size (4K, 8K, etc) A table can span several pages, a page can contains several rows from one or more tables.
Row Level â Much less restrictive, allows concurrent transactions to access different rows of same table ī However, HIGH OVERHEAD COST because a lock must exist for every row in every table of the database
Field Level â Allows access to the same row as long as accessing different attributes. MOST flexible, HIGHEST overhead
2 Transactions cannot have conflicting locks
No unlock operation can precede a lock operation in the same transaction
No data is modified until all locks are obtained.
Choice of best method depends on the needs and probability of deadlocks within the database