1. Transactions, Locking and Query Optimisation
Training – 26th July 2010
Zed-Axis Technologies

2. Transaction Basics
provide you with the capability of performing a series of commands in an "all or nothing" fashion
Exhibit Four Properties (ACID):
Atomicity – either all or none
Consistency – leave data in consistent state
Isolation – independent of all other transactions
Durability – data is in persistent state
Autocommit or Explicit

3. Nesting Transactions
Nesting is only possible with Explicit Transactions
Successive BEGIN TRAN Statements Increment
Each COMMIT TRAN Decrements
When reaches 0, COMMIT occurs
ROLLBACK Sets to 0

4. Demo 1
Nesting Transactions

5. Transaction Isolation Level
defines the degree to which one transaction must be isolated from resource or data modifications made by other transactions
a transaction isolation level does not affect the locks acquired to protect data modifications.
It affects the level of protection for read operations
True Isolation is expensive
Trade off between correctness and concurrency

6. Isolation Levels and Operation Allowed
Dirty read
Nonrepeatable read
Phantom
Read uncommitted
Yes
Read committed No
Repeatable read
Serializable

7. Demo 2
Repeatable Read Isolation

8. Aspects of Locking Type of Lock Duration of Lock Granularity Shared
Exclusive
Update
Duration of Lock
Shared locks held until done reading
Exclusive locks held until end of transaction
Granularity

9. Granularity of Locks: Resources
Row/Key
Page
Table
Extent
Database

10. Multi Granular Locking
To lock a fine level, SQL Server places Intent Locks at higher levels.

11. Demo 3
Multi granular locking

12. Locking Granularity Default is row or key lock
After optimization, SQL Server may decide to lock pages or the whole table
If too much memory is used for locks
If optimizer has decided to do a scan
Row/key and page locks can be escalated during execution
Escalation is always to a table – based on total locks
SQL Trace lets you monitor escalations
Tradeoff is resources used vs. concurrency

13. Dynamic Locking Row Locking Is Not Always Best
Sometimes Page or Table Locking Is the Optimal Way to Scan
SQL Server’s Strategy is Dynamic
SQL Server chooses the lowest cost locking strategy (Row, Page, or Table) at run time based upon input from the query optimizer
Multiple Row or Page Locks Can Escalate to TABLE lock

14. Demo 4
Lock Escalation

15. Lock Compatibility Requested mode Existing granted mode IS S U IX SIXIS S U IX
SIX X
Intent shared (IS)
Yes No
Shared (S)
Update (U)
Intent exclusive (IX)
Shared with intent exclusive (SIX)
Exclusive (X)

16. Avoiding Blocking Keep transactions as short as possible
Isolate and Tune Long Running Queries
No user interaction during transactions
Transactions should not be started until all preliminary data analysis has been done.
Rollback when canceling, or on any error or timeout
Acess least amount of data possible in transaction
Stress test at maximum projected user load
Acess heavily used data at the end of transaction

17. Understanding Query Plan
Table scans—Table scans are the slowest way for SQL Server to look up data.
Index seek—This type of operation uses a non-clustered index to look up table results.
Table Lookup - index’s pointer to find the actual row of data within the table.
Clustered index Scan – Similar to table scan, and generally indicate a performance problem in a large table.
Clustered Index Seek - Similar to an index seek, this operation runs through a table’s clustered index to locate query results.
Joins—SQL Server will include one or more join operations in a query plan when necessary.

18. Increase Query Performance
Use NOCOUNT in SP
Reduce network overhead
Return only those values which are required
Do not use DISTINCT keyword unless required
Define all Primary and Foreign Key Relationships
Define all unique and check constraints
Avoid Like operation with wildcard on both sides ‘%a%’
Use FQDN Objects
Do not use sp_ prefix for customer stored procedures
Use Union ALL instead of Union wherever possible.
Use functions carefully in where clause