Date post: | 13-Dec-2014 |
Category: |
Technology |
Upload: | syed-asrarali |
View: | 441 times |
Download: | 1 times |
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