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

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

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

Demo 1 Nesting Transactions

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

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

Demo 2 Repeatable Read Isolation

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

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

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

Demo 3 Multi granular locking

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

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

Demo 4 Lock Escalation

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

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

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.

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