Transcript No Slide Title

Chapter 16
How to manage
transactions and locking
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 1
Objectives
Applied
 Given a set of statements to be combined into a transaction, insert
the Transact-SQL statements to explicitly begin, commit, and roll
back the transaction.
Knowledge
 Describe the use of implicit transactions.
 Describe the use of explicit transactions.
 Describe the use of the COMMIT TRAN statement and the
@@TRANCOUNT function within nested transactions.
 Describe the use of save points.
 Define these types of concurrency problems: lost updates, dirty
reads, nonrepeatable reads, and phantom reads.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 2
Objectives (continued)
 Describe the way locking and the transaction isolation level help
to prevent concurrency problems.
 Describe the way SQL Server manages locking in terms of
granularity, lock escalation, shared locks, exclusive locks, and
lock promotion.
 Describe deadlocks and the way SQL Server handles them.
 Describe four coding techniques that can reduce deadlocks.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 3
How transactions maintain data integrity
 A transaction is a group of database operations that are combined
into a logical unit.
 By default, each SQL statement is treated as a separate
transaction. However, you can combine any number of SQL
statements into a single transaction.
 When you commit a transaction, the operations performed by the
SQL statements become a permanent part of the database.
 Until it’s committed, you can undo all of the changes made to the
database since the beginning of the transaction by rolling back the
transaction.
 A transaction is either committed or rolled back in its entirety.
Once you commit a transaction, it can’t be rolled back.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 4
Three INSERT statements that work with related
data
DECLARE @InvoiceID int
INSERT Invoices
VALUES (34,'ZXA-080','2008-08-30',14092.59,0,0,3,
'2008-09-30',NULL)
SET @InvoiceID = @@IDENTITY
INSERT InvoiceLineItems
VALUES (@InvoiceID,1,160,4447.23,'HW upgrade')
INSERT InvoiceLineItems
VALUES (@InvoiceID,2,167,9645.36,'OS upgrade')
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 5
The same statements coded as a transaction
DECLARE @InvoiceID int
BEGIN TRY
BEGIN TRAN
INSERT Invoices
VALUES (34,'ZXA-080','2008-08-30',14092.59,
0,0,3,'2008-09-30',NULL)
SET @InvoiceID = @@IDENTITY
INSERT InvoiceLineItems
VALUES (@InvoiceID,1,160,4447.23,'HW upgrade')
INSERT InvoiceLineItems
VALUES (@InvoiceID,2,167,9645.36,'OS upgrade')
COMMIT TRAN
END TRY
BEGIN CATCH
ROLLBACK TRAN
END CATCH
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 6
When to use explicit transactions
 When you code two or more action queries that affect related data
 When you update foreign key references
 When you move rows from one table to another table
 When you code a SELECT query followed by an action query and
the values inserted in the action query are based on the results of
the SELECT query
 When a failure of any set of SQL statements would violate data
integrity
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 7
Summary of the SQL statements for processing
transactions
Statement
Description
BEGIN {TRAN|TRANSACTION}
Marks the starting point of a
transaction.
SAVE {TRAN|TRANSACTION}
Sets a new save point within a
save_point
transaction.
COMMIT [TRAN|TRANSACTION]
Marks the end of a transaction
and makes the changes within
the transaction a permanent part
of the database.
ROLLBACK [[TRAN|TRANSACTION] Rolls back a transaction to the
[save_point]]
starting point or to the specified
save point.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 8
How to use the SQL statements for processing
transactions
 Although you can omit the TRAN keyword from the COMMIT
and ROLLBACK statements, it’s generally included for
readability.
 By default, SQL Server is in autocommit mode. Then, unless you
explicitly start a transaction using the BEGIN TRAN statement,
each statement is automatically treated as a separate transaction.
 In autocommit mode, if the statement causes an error, it’s
automatically rolled back. Otherwise, it’s automatically
committed.
 Even if you don’t explicitly start a transaction, you can roll it back
using the ROLLBACK TRAN statement. However, you can’t
explicitly commit an implicit transaction.
 When you use save points, you can roll a transaction all the way
back to the beginning or to a particular save point.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 9
A script that performs a test before committing
the transaction
BEGIN TRAN
DELETE Invoices
WHERE VendorID = 34
IF @@ROWCOUNT > 1
BEGIN
ROLLBACK TRAN
PRINT 'Deletions rolled back.'
END
ELSE
BEGIN
COMMIT TRAN
PRINT 'Deletions committed to the database.'
END
The response from the system
(3 row(s) affected)
Deletions rolled back.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 10
How to work with nested transactions
 You can nest transactions by coding nested BEGIN TRAN
statements. Each time this statement is executed, it increments the
@@TRANCOUNT system function by 1.
 You can query the @@TRANCOUNT function to determine how
many levels deep the transactions are nested.
 If @@TRANCOUNT is equal to 1 when you execute a COMMIT
TRAN statement, all of the changes made to the database during
the transaction are committed and @@TRANCOUNT is set to
zero.
 If @@TRANCOUNT is greater than 1, the changes aren’t
committed. Instead, @@TRANCOUNT is decremented by 1.
 The ROLLBACK TRAN statement rolls back all active
transactions regardless of the nesting level where it’s coded. It also
sets the value of @@TRANCOUNT back to 0.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 11
A script with nested transactions
BEGIN TRAN
PRINT 'First Tran @@TRANCOUNT: ' +
CONVERT(varchar,@@TRANCOUNT)
DELETE Invoices
BEGIN TRAN
PRINT 'Second Tran @@TRANCOUNT: ' +
CONVERT(varchar,@@TRANCOUNT)
DELETE Vendors
COMMIT TRAN
-- This COMMIT decrements @@TRANCOUNT.
-- It doesn't commit 'DELETE Vendors'.
PRINT 'COMMIT
@@TRANCOUNT: ' +
CONVERT(varchar,@@TRANCOUNT)
ROLLBACK TRAN
PRINT 'ROLLBACK
@@TRANCOUNT: ' +
CONVERT(varchar,@@TRANCOUNT)
PRINT ' '
DECLARE @VendorsCount int, @InvoicesCount int
SELECT @VendorsCount = COUNT (*) FROM Vendors
SELECT @InvoicesCount = COUNT (*) FROM Invoices
PRINT 'Vendors Count: ' + CONVERT (varchar , @VendorsCount)
PRINT 'Invoices Count: ' + CONVERT (varchar , @InvoicesCount)
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 12
The response from the system
First Tran
@@TRANCOUNT: 1
(114 row(s) affected)
Second Tran @@TRANCOUNT: 2
(122 row(s) affected)
COMMIT
@@TRANCOUNT: 1
ROLLBACK
@@TRANCOUNT: 0
Vendors count: 122
Invoices count: 114
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 13
How to work with save points
 You can partially roll back a transaction if you use save points.
 If you code a save point name in the ROLLBACK TRAN
statement, the system rolls back all of the statements to that save
point.
 If you don’t code a save point name, the ROLLBACK TRAN
statement rolls back the entire transaction.
 Since you can’t code a save point name in a COMMIT TRAN
statement, the system always commits the entire transaction.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 14
A transaction with two save points
IF OBJECT_ID ( 'tempdb..#VendorCopy' ) IS NOT NULL
DROP TABLE tempdb.. #VendorCopy
SELECT VendorID, VendorName
INTO #VendorCopy
FROM Vendors
WHERE VendorID < 5
BEGIN TRAN
DELETE #VendorCopy WHERE VendorID = 1
SAVE TRAN Vendor1
DELETE #VendorCopy WHERE VendorID = 2
SAVE TRAN Vendor2
DELETE #VendorCopy WHERE VendorID = 3
SELECT * FROM #VendorCopy
ROLLBACK TRAN Vendor2
SELECT * FROM #VendorCopy
ROLLBACK TRAN Vendor1
SELECT * FROM #VendorCopy
COMMIT TRAN
SELECT * FROM #VendorCopy
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 15
The response from the system
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 16
An introduction to concurrency and locking
 Concurrency is the ability of a system to support two or more
transactions working with the same data at the same time.
 Because small systems have few users, concurrency isn’t
generally a problem on these systems.
 On large systems with many users and many transactions, you
may need to account for concurrency in your SQL code.
 Concurrency is a problem only when the data is being modified.
When two or more transactions simply read the same data, the
transactions don’t affect each other.
 When you use locks, the execution of a transaction is delayed if it
conflicts with a transaction that’s already running. The second
transaction can’t use the data until the first one releases the lock.
 SQL Server automatically enforces locking, but you can write
more efficient code by customizing locking in your programs.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 17
Two transactions that retrieve and then modify the
data in the same row
Transaction A
BEGIN TRAN
DECLARE @InvoiceTotal money, @PaymentTotal money,
@CreditTotal money
SELECT @InvoiceTotal = InvoiceTotal,
@CreditTotal = CreditTotal,
@PaymentTotal = PaymentTotal
FROM Invoices WHERE InvoiceID = 112
UPDATE Invoices
SET InvoiceTotal = @InvoiceTotal,
CreditTotal = @CreditTotal + 317.40,
PaymentTotal = @PaymentTotal WHERE InvoiceID = 112
COMMIT TRAN
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 18
Two transactions that retrieve and then modify the
data in the same row (cont.)
Transaction B
BEGIN TRAN
DECLARE @InvoiceTotal money, @PaymentTotal money,
@CreditTotal money
SELECT @InvoiceTotal = InvoiceTotal,
@CreditTotal = CreditTotal,
@PaymentTotal = PaymentTotal
FROM Invoices WHERE InvoiceID = 112
UPDATE Invoices
SET InvoiceTotal = @InvoiceTotal,
CreditTotal = @CreditTotal,
PaymentTotal = @InvoiceTotal - @CreditTotal,
PaymentDate = GetDate() WHERE InvoiceID = 112
COMMIT TRAN
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 19
Two transactions that retrieve and then modify the
data in the same row (cont.)
The initial values for the row
The values after transaction A executes
The values after transaction B executes, losing
transaction A’s updates
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 20
The four types of concurrency problems
Problem
Lost updates
Dirty reads
(uncommitted
dependencies)
Nonrepeatable
reads
(inconsistent
analysis)
Phantom reads
Murach’s SQL Server 2008, C16
Description
Occur when two transactions select the same row
and then update it based on the original values.
The later update overwrites the earlier one.
Occur when a transaction selects data that hasn’t
been committed by another transaction. If a change
is then rolled back, the transaction has selected a
row that doesn’t exist in the database.
Occur when two SELECT statements of the same
data result in different values because another
transaction has updated the data in the time
between the two statements.
Occur when you perform an update or delete on a
set of rows while another transaction is performing
an insert or delete that affects a row within the set.
© 2008, Mike Murach & Associates, Inc.
Slide 21
How to handle concurrency problems
 In a large system with many users, you should expect
concurrency problems to occur.
 In general, you don’t need to take any action except to
anticipate the problem. In many cases, if the query is
resubmitted, the problem goes away.
 On some systems, if two transactions overwrite each other, the
validity of the database is compromised and resubmitting one
of the transactions will not eliminate the problem.
 On such a system, you must anticipate these concurrency
problems and account for them in your code.
 If a potential concurrency problem would affect data integrity,
you can change the default locking behavior by setting the
transaction isolation level.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 22
The syntax of the SET TRANSACTION ISOLATION
LEVEL statement
SET TRANSACTION ISOLATION LEVEL
{READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|
SNAPSHOT|SERIALIZABLE}
The concurrency problems prevented by each level
Dirty
reads
Lost
Nonrepeatable Phantom
updates reads
reads
READ
UNCOMMITTED
Allows
Allows
Allows
Allows
READ
COMMITTED
Prevents
Allows
Allows
Allows
REPEATABLE
READ
Prevents
Prevents
Prevents
Allows
SNAPSHOT
Prevents
Prevents
Prevents
Prevents
SERIALIZABLE
Prevents
Prevents
Prevents
Prevents
Isolation level
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 23
How to set the transaction isolation level
 The transaction isolation level controls the degree to which
transactions are isolated from one another, thereby reducing
concurrency problems.
 The server isolates transactions by using more restrictive locking
behavior.
 The default transaction isolation level is READ COMMITTED.
This is acceptable for most transactions.
 The READ UNCOMMITTED isolation level doesn’t set any locks
and ignores locks that are already held. That results in the highest
possible query performance, but at the risk of every kind of
concurrency problem. So use it only for data that is rarely updated.
 The REPEATABLE READ level places locks on all data that’s
used in a transaction, preventing other users from updating that
data. However, it still allows inserts, so phantom reads can occur.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 24
How to set the transaction isolation level (cont.)
 The SNAPSHOT level was introduced with SQL Server 2005. It
uses row versioning rather than locks to provide read consistency.
You can also use row versioning with READ COMMITTED.
 With row versioning, each time a row is modified, SQL Server
stores an image of the row as it existed before the change. Read
operations then retrieve the row as it existed at the start of the
transaction (SNAPSHOT) or statement (READ COMMITTED).
 The SERIALIZABLE level places a lock on all data that’s used in
a transaction. Since each transaction must wait for the previous
transaction to commit, the transactions are handled in sequence.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 25
The ten levels of lockable resources
Granularity
Coarse
Resource
Database
Description
Locks an entire database.
Allocation unit Locks a collection of pages that contains
a particular type of data.
Fine
Murach’s SQL Server 2008, C16
Metadata
Locks the data in the system catalog.
File
Locks an entire database file.
Table
Locks an entire table.
Heap or
B-tree
Locks the index pages (B-tree) for a
table with a clustered index or the data
pages (heap) for a table without one.
Extent
Locks a contiguous group of eight pages.
Page
Locks one page (8 KB) of data.
Key
Locks a key or range of keys in an index.
Row
Locks a single row within a table.
© 2008, Mike Murach & Associates, Inc.
Slide 26
Lockable resources and lock escalation
 SQL Server can lock data at various levels, known as lockable
resources. The ten levels form a hierarchy based on granularity,
which refers to the amount of data the resource encompasses.
 A resource that encompasses more data than another resource is
less granular, or coarser, than the other resource. So a coarsegrain lock affects more data than a fine-grain lock.
 More transactions are locked out when the lock is less granular.
Since this slows database performance, the server assigns locks of
the finest possible granularity.
 Locking is automatically enabled and controlled by a SQL Server
application called the lock manager.
 Maintaining several fine-grain locks requires greater server
resources than maintaining one coarse-grain lock. So the lock
manager converts multiple fine-grain locks on the same resource
into a single coarse-grain lock. This is known as lock escalation.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 27
Common SQL Server lock modes
Category
Lock mode
What the lock owner can do
Shared
Schema Stability
(Sch-S)
Intent Shared (IS)
Shared (S)
Update (U)
Compile a query
Exclusive
Shared with Intent
Exclusive (SIX)
Intent Exclusive (IX)
Exclusive (X)
Bulk Update (BU)
Schema Modification
(Sch-M)
Murach’s SQL Server 2008, C16
Read but not change data
Read but not change data
Read but not change data until
promoted to an Exclusive (X) lock
Read and change data
Read and change data
Read and change data
Bulk-copy data into a table
Modify the database schema
© 2008, Mike Murach & Associates, Inc.
Slide 28
Lock modes and lock promotion
 SQL Server automatically determines the appropriate lock mode
for your transaction.
 In general, retrieval operations acquire shared locks, and update
operations acquire exclusive locks.
 As a single transaction is being processed, its lock may have to be
converted, or promoted, from one lock mode to a more exclusive
lock mode.
 An Update (U) lock is acquired during the first part of an update,
when the data is being read.
 If the data is changed, the Update lock is promoted to an
Exclusive (X) lock. This can prevent a common locking problem
called a deadlock.
 An intent lock indicates that SQL Server intends to acquire a
shared lock or an exclusive lock on a finer-grain resource.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 29
Lock modes and lock promotion (cont.)
 Example: An Intent Shared (IS) lock acquired at the table level
means that the transaction intends to acquire shared locks on
pages or rows within that table. This prevents another transaction
from acquiring an exclusive lock on the table.
 Schema locks are placed on a table’s design.
 Schema Modification (Sch-M) locks are acquired when the design
is being changed with a DDL statement.
 Schema Stability (Sch-S) locks are acquired when compiling a
query to prevent a schema change while the query is compiling.
 The Bulk Update (BU) lock mode is acquired for the BULK
INSERT statement and by the bulk copy program (bcp). These
operations are typically done by DBAs.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 30
Compatibility between lock modes
Sch-S
IS
Requested lock mode
S
U SIX IX
X






Intent Shared IS






Shared
S




Update
U



Shared
w/Intent
Exclusive
SIX


Intent
Exclusive
IX


Exclusive
X

Bulk Update
BU

Current lock mode
Schema
Stability
Sch-S

BU
Sch-M


Schema
Sch-M
Modification
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 31
Compatibility between lock modes (cont.)
 If a resource is already locked by a transaction, a request by
another transaction for a lock on the same resource will be
granted or denied depending on the compatibility of the two lock
modes.
 Example: If a transaction has a Shared (S) lock on a table and
another transaction requests an Exclusive (X) lock, the lock isn’t
granted. The second transaction must wait until the first
transaction releases its lock.
 Intent locks can help improve performance since the server only
needs to examine the high-level locks rather than examining
every low-level lock.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 32
An introduction to deadlocks
 A deadlock occurs when neither of two transactions can be
committed because they each have a lock on a resource needed by
the other.
 SQL Server automatically detects deadlocks and allows one of the
transactions to commit. The other transaction is rolled back and
raises error number 1205.
 The transaction that’s rolled back is known as the deadlock victim.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 33
Two transactions that deadlock
SET TRANSACTION ISOLATION LEVEL
REPEATABLE READ
DECLARE @InvoiceTotal money
SET TRANSACTION ISOLATION LEVEL
REPEATABLE READ
DECLARE @InvoiceTotal money
BEGIN TRAN
SELECT @InvoiceTotal =
SUM(InvoiceLineItemAmount)
FROM InvoiceLineItems
WHERE InvoiceID = 101
BEGIN TRAN
SELECT @InvoiceTotal =
InvoiceTotal
FROM Invoices
WHERE InvoiceID = 101
WAITFOR DELAY '00:00:05'
UPDATE InvoiceLineItems
SET InvoiceLineItemAmount =
@InvoiceTotal
WHERE InvoiceID = 101 AND
InvoiceSequence = 1
COMMIT TRAN
UPDATE Invoices
SET InvoiceTotal =
@InvoiceTotal
WHERE InvoiceID = 101
COMMIT TRAN
The responses from the system
(1 row(s) affected)
Murach’s SQL Server 2008, C16
Msg 1205, Level 13, State 51, Line
10
Transaction (Process ID 53) was
deadlocked on lock resources with
another process and has been chosen
as the deadlock victim. Rerun the
transaction.
© 2008, Mike Murach & Associates, Inc.
Slide 34
How the deadlock occurs
1. Transaction A requests and acquires a shared lock on the
InvoiceLineItems table.
2. Transaction B requests and acquires a shared lock on the
Invoices table.
3. Transaction A tries to acquire an exclusive lock on the Invoices
table to perform the update. Since transaction B already holds a
shared lock on this table, transaction A must wait for the
exclusive lock.
4. Transaction B tries to acquire an exclusive lock on the
InvoiceLineItems table, but must wait because transaction A
holds a shared lock on that table.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 35
Coding techniques that prevent deadlocks
Use the lowest possible transaction isolation level
 The default level of READ COMMITTED is almost always
sufficient.
 Reserve the use of higher levels for short transactions that
make changes to data where integrity is vital.
Don’t allow transactions to remain open for very long
 Keep transactions short.
 Keep SELECT statements outside of the transaction except
when absolutely necessary.
 Never code requests for user input during an open
transaction.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 36
Coding techniques that prevent deadlocks (cont.)
Make large changes when you can be assured of nearly
exclusive access
 If you need to change millions of rows in an active table, don’t
do so during hours of peak usage.
 If possible, give yourself exclusive access to the database
before making large changes.
Consider locking when coding your transactions
 If you need to code two or more transactions that update the
same resources, code the updates in the same order in each
transaction.
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 37
UPDATE statements that transfer money between
two accounts
From savings to checking
UPDATE Savings SET Balance = Balance - @TransferAmt
UPDATE Checking SET Balance = Balance + @TransferAmt
From checking to savings (could cause a deadlock)
UPDATE Checking SET Balance = Balance - @TransferAmt
UPDATE Savings SET Balance = Balance + @TransferAmt
From checking to savings in reverse order to prevent
deadlocks
UPDATE Savings SET Balance = Balance + @TransferAmt
UPDATE Checking SET Balance = Balance - @TransferAmt
Murach’s SQL Server 2008, C16
© 2008, Mike Murach & Associates, Inc.
Slide 38