Introduction To SQLUnit 12

Modern Business Technology

Introduction To TSQLUnit 12

Developed by

Michael Hotek

Transaction Management

• Most of the following discussion of transaction management is specific to Sybase SQL Server and MS SQL Server

• But, the principles can be applied to virtually any DBMS

Transactions

• Transactions by definition are a logical unit of work

• A logical unit of work is a SQL operation or a set of SQL statements executed against a database– Usually include at least one DML

statement– Changes the database from one

consistent state to another

• A transaction can have two outcomes– When it completes successfully, it is

"committed" or "saved"– When a transaction fails, it is "rolled

back" or "undone"

• Another definition is a single recoverable unit of work that executes either:– Completely– Not at all

• A transaction can be anything from a single DML command to a series of commands (multiple inserts or deletes)

Transactions

Outcomes

• After a transaction is committed, it can not be undone

• When a transaction is rolled back, all modifications of the transaction are undone

• Partial execution of a transaction is not allowed

• delete authors can only have two possible outcomes:– All rows are deleted (committed) or– None of the rows are deleted (rolled

back)

Need for Transactions

• Transactions are the result of business rules being applied to the database world

• These rules state that an operation either completes successfully or none of the operations can be applied

• In the following scenario, we will consider a bank teller machine

Need for Transactions

• The business function we are trying to apply is the transfer of funds from a savings to a checking account

• The amount debited from the savings account must be added to the checking account

• Both the debit and the credit must occur or neither must occur

Need for Transactions

• Here are the possible problems in transferring $1000– Partial transfer

• Money is debited, but not credited

– Another operation against your account could conflict with the transfer

– Another operation could see invalid data• The debit does not work, but the money is

credited. A check for an amount greater than should be in the checking account is processed and approved

– Another operation could see data at the wrong time

• Transaction management is implemented to cover the following issues:– Protect data from software, hardware, or

power failure– Provide access to multiple user– Prevent simultaneous read and write of

the same data by multiple users

• Transaction control is implemented via three methods– Locking– Transaction control statements– Error management

Implementing

Data Storage

• How data is physically stored by SQL Server is beyond the scope of this class

• However, there is one principle that must be understood in order to continue with the next topic

• A table's data is stored in a series of pages called data pages

• SQL Server handles this page allocation internally and also "knows" where to find the particular data via a set of internal structures

Locking

• Locking is automagically handled by SQL Server via a process called the Lock Manager

• As reads or writes are performed on a data page, the lock manager places a lock on that page

• This ensures that simultaneous transactions do not interfere with each other

• Without this locking, you may get data inconsistency in a multi-user environment

• The locking mechanism also reduces availability of data

Locking

• All locking decisions are handled by SQL Server

• There are two levels of locking– page and table

• Page locks are less restrictive than table locks, because the lock is placed only on a single page and therefore on a small subset of data

• Page locks are used whenever possible

Table Locks

• A table lock is the most restrictive lock

• As it's name implies, it is a lock that covers the entire table

• A table lock is implemented via a means called escalation

• If a user is going to access an entire table:– an update with no where clause

• SQL Server will escalate the page lock to a table lock

• Once a SQL statement accumulates 200 page locks, it is escalated to a table lock

Locking

• Obviously there can only be one table lock

• So, it would seem that you want to avoid this if at all possible

• The type of lock acquired is generally not a concern as SQL Server tries to maintain the most appropriate lock for the least duration of time

Granularity

• The granularity of a lock refers to the amount of data that can be locked at one time. This can range from a single page to an entire database

• By increasing the lock granularity, the processing required to obtain a lock decreases. But this also degrades performance

• As lock granularity decreases, the amount of processing required to maintain and coordinate the locks increases

Types of Page Locks

• There are three types of locks– Shared

• Multiple transactions can lock a shared page

• No transactions can change the page

• Usually released as soon as the page is read

– Exclusive• Only one transaction can lock a page

• Other transactions must wait until the lock is released

• Exists for the duration of the transaction

– Update• Allows reads, but will not allow shared or

exclusive locks

• Becomes an exclusive lock when the page is ready to be modified

• Is an internal lock to help avoid deadlocks

• Exists for the duration of the transaction

Lock Interactions

Can another process:

Command Lock Select Modify

select title_id from titles shared yes no

delete titles exclusive no no

where price > 25

insert into titles values (…) exclusive no no

update titles set type= update, yes no

'general' where type = then exclusive no

'business'

• Locking is affected by:– Indexes

– Transactions

– Isolation Levels

– Table and page level locking

Isolation Levels

• The ANSI standard defines four level of isolation for transactions– Level 0 allows dirty reads (You can see

data that has been changed, but not necessarily committed, by another user

– Level 1 prevents dirty reads– Level 2 prevents non-repeatable reads– Level 3 prevents phantom reads

• The higher the isolation level, the higher the consistency

• The higher the isolation level, the lower the concurrency

Isolation Levels

• All higher levels include all of the restrictions of the lower levels

• Level 0– No shared locks for reads or exclusive

locks on pages or tables being changed. An update still acquires a shared lock for its read

• Level 1– Exclusive lock on objects being changed.

Hold lock until end of transaction– Shared locks on pages being searched.

Release locks after object is processed.

Isolation Levels

• Level 2– Exclusive lock on pages being changed.

Hold lock until end of transaction– Shared lock on pages being searched.

Remove lock after processing object

• Level 3– Exclusive lock on pages being changed– Shared lock on pages/tables being

searched– Hold all locks until end of transaction

(accumulate locks)

• The default isolation level for SQL Server is 1

• The default isolation level for the ANSI-92 standard is 3

• The current isolation level can be gotten from @@isolation

Holdlock

• noldlock/noholdlock is an option for a select statement that overrides the isolation level set for the duration of the select statement

• Holdlock– Enforces isolation level 3– Makes a shared lock more restrictive, by

causing the server to hold all shared locks until the transaction is complete

– Applies a shared pages lock if the search argument references indexed columns, otherwise it applies a table lock

– Use only if strictly necessary

Noholdlock

• Use the noholdlock option only if you want SQL Server to release any shared locks regardless of isolation level

Holdlock

begin trandeclare @avg_adv money

select @avg_adv = avg(advance) from titles holdlock where type = 'business'

if @avg_adv > 5000

select title from titles where type = 'business' and advance > @avg>adv

commit tran

Since the average must remain constant for the duration of the transaction, holdlock will prevent anyone from writing to the titles table until the transaction is complete

Deadlock

• A deadlock can occur when two processes hold locks on a page on which the other process holds a conflicting lock

• SQL Server detects this and aborts one of the transactions

Deadlock

• SQL Server will detect a deadlock and chooses the user with the least amount of CPU time as the "victim"

• Even the "winner" will see a significant decrease in performance

Deadlock

• Application need to program for the possibility of a deadlock (error 1205 in Sybase SQL Server)

• If a deadlock occurs, the application should resubmit the transaction

Avoiding Deadlocks

• To minimize the possibility of a deadlock– Have all transaction access the tables in

the same order– Use holdlock only when repeatable

reads are necessary– Avoid long running transactions; make

transactions small and commit as soon as possible

– Avoid user input while you have a holdlock on a table

– Avoid numerous simultaneous executions of DML commands like insert, update, delete

Avoiding Deadlocks

• The best way to avoid deadlocks is to write transaction in the same order. Avoid the following:begin tran begin tran

update table A update table B

update table B update table A

commit tran commit tran

• Wherever possible try to use stored procedures to perform transactions to ensure consistent access order to tables

Transaction Control

• Provides the control required for managing transaction

• Enables the grouping of SQL commands in a transaction that meet business requirements

• Enables a programmer to influence SQL Server's locking strategy

• Creates predictable effects when committing or rolling back transactions

• begin transaction and commit transaction mark the beginning and end of a transaction

Transaction Control

• There are three transaction control statements– begin tran

• Alerts SQL Server that a transaction is beginning. You can optionally name a transaction.

– rollback tran• Undoes the changes either to the named

savepoint or the beginning of the transaction. Execution continues with the next statement

– commit tran• End the transaction and saves changes to

the database

Rollback

• Before a commit is issued, a transaction can be either partially rolled back to a savepoint or completely rolled back

• After a commit is issued, a transaction can not be rolled back

Savepoints

• In unchained mode, you can set up savepoints in a transaction

• These serve as an intermediate point in a transaction

• There could be cases where you want to only rollback a portion of the work you have done.

• save {transaction | tran } savepoint_name

Savepoints

• To undo all statements or procedures between a savepoint and the rollback use:

• rollback {transaction | tran | work} savepoint_name

• Always name savepoints

• After a rollback, execution continues with the statement immediately following the rollback

Savepoint Example

A bank can charge a fee for every use of an ATM. The specific transaction might fail, but the charge still needs to be applied

begin tran

update service_charge set service_charge = service_charge + .50 where account_num = '99999'

save tran service_charge

update savings set balance = balance - 500 where account_num = '99999'

if @@transtate = 2

begin

select @@error

rollback tran service_charge

return

end

...

Error Processing

• You can monitor a transaction through two global variables:– @@error detects errors during/after

statements execute– @@transtate monitors the current state

of the transaction

Value Meaning

0 transaction in progress

1 transaction committed

2 previous statement aborted and transaction still in progress

3 transaction aborted/statement rolled back

• @@transtate is reset after insert, update, delete

Error Handling

• Failure with a rollback (@@transtate = 3)– Errors of severity level 19 or higher are fatal

and will immediately abort the transaction and roll back all statements to the beginning of the transaction

• Failure with continue (@@transtate = 2)– Errors from a failed statement cause the

statement to fail, but other statements are committed

• No error, completed (@@transtate = 1)– Transaction finished and saved all its changes

• No error, in progress (@@transtate = 0)

Error Handling

• @@transtate is not always set to 2 or 3 when a statement fails

• Insert into a null into a column that does not allow nulls– An error is reported for each attempt– All rows that contain valid data will be

inserted– The error is found in @@error– There is no indication in @@transtate

• @@error should be used exclusively to:– Maintain atomicity of transactions

• If any commands fail, undo all changes

• Abort the transaction using a return

• Ensure each batch contains only one transaction so you can predict what is rolled back on an abort

Error Handling

• If you are using insert statements in a transaction, you should always check @@error

begin tran

insert …if @@error != 0

begin

rollback tran

return

end

…

commit tran

@@rowcount

• @@rowcount will tell you how many rows were affected by a statement– An insert, update, or delete may affect

more than one row– A select into a variable may not return

any rows which could cause invalid results later in the transaction

• If you expect rows and @@rowcount = 0– Issue a rollback tran– Issue a return to abort the transaction

Reporting Errors

• If an error occurs, we want to return a user friendly message of what happened.

• This is accomplished by using raiserror

• Develop a numbering system for error messages– 20001 - 21000 = update errors– 21001 - 22000 = insert errors...

• Standardize you error output

• Add a new error message with sp_addmessage

Report Errors Example

exec sp_addmessage 40000, "An error occurred while updating '%1!' table with a publisher ID of '%2!'."

declare @error int,

@rows int

begin tran

update publishers set pub_id = 'a' where pub_id = '0736'

select @error = @@error, @rows = @@rowcount

if @error != 0

begin

rollback tran

raiserror 40000,'publishers','0736'

return

end...

commit tran

Results

Msg 40000, Level 16, State 1:

Line11

An error occurred while updating publishers table with publisher ID of 0736.

Unit 12 Review

• A transaction is a logical unit of work

• Transactions can be committed or rolled back

• Once a transaction is committed it can not be rolled back

• Pages are locked as they are accessed. A large number of page locks will escalate into a table lock

• There are four isolation levels which can be used to control the locking in the database

• Use the holdlock/noholdlock to override an isolation level setting

• Deadlocks occur when two transaction are trying to obtain a lock on a page where the other has a conflicting lock

• Deadlocks need to be avoided at all costs

• There are three transaction control statements: begin tran, commit tran, rollback tran

• There are two transaction modes: chained and unchained

• Savepoints can be implemented to preserve some of the work done in the event of an error

• @@error detects errors during or after statement execution

Unit 12 Review

• @@transtate is used to check the state of a transaction - It has four values

• @@rowcount stores the number of rows affected by a given statement

• Raiserror is used to return an error message back to an application

Unit 12 Exercises

• Time allotted for exercises is 1/2 hour