SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes

The ACID Properties

Transactions are defined by the ACID properties.
ACID is an acronym for four interdependent properties:
atomicity,
consistency,
isolation, and
durability.

Atomicity
A transaction must be atomic, meaning all or nothing. At the end of the transaction, either all of the
transaction is successful, or all of the transaction fails. If a partial transaction is written to disk, the
atomic property is violated. The ability to commit or roll back transactions is required for atomicity.

Consistency
A transaction must preserve database consistency, which means that the database must begin the transaction
in a state of consistency and return to a state of consistency once the transaction is complete.
Every row and value must agree with the reality being modeling, and every constraint must be enforced.
Pgina 1 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
For example, if the order rows were written to disk but the order detail rows are not written, the consistency between the Order and OrderDetail tables, or more specifically,
the OrderDetail tables OrderID foreign key constraint, would have been violated, and the database would be in an inconsistent state. This is not allowed.
Consistency allows the database to be in an inconsistent state during the transaction. The key is that the
database is consistent at the completion of the transaction.

Isolation
Each transaction must be isolated, or separated, from the effects of other transactions.
Regardless of what any other transaction is doing, a transaction must be able to continue with the exact same data sets it
started with. Isolation is the fence between two transactions.
A proof of isolation is the ability to replay a serialized set of transactions on the original set of data and always receive the same result.
For example, assume Joe is updating 100 rows. While Joes transaction is under way, Sue tries to read one of the rows Joe is working on. If Sues read takes place, then
Joes transaction is affecting Sues transaction, and their two transactions are not fully isolated from each another. This property is less critical in a read-only database or a
database with only a few users.
SQL Server enforces isolation with locks and row versioning.

Durability
The durability of a transaction refers to its permanence regardless of system failure.
Once a transaction is committed, it stays committed in the state it was committed.
In addition, the Database Engine must be designed so that even if the data drive fails, the database can be restored up
to the last transaction that was committed before the hard drive failure.
SQL Server ensures durability with the write-ahead transaction log.

Transaction Log
Every transaction is recorded in a transaction log to maintain database consistency and to aid in transaction recovery. When changes are made to data in SQL Server, the
database pages that have been modified are written to the transaction log on the disk first and later written to the database.
If any part of the transaction fails, all of the changes made so far are rolled back to leave the database in its original state. This system ensures that updates are complete
and recoverable.
Transactions use locking to prevent other users from changing or reading data in a transaction that has not completed. Locking is required in online transaction processing
(OLTP) for multi-user systems

Pgina 2 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Concurrency Concepts

Pgina 3 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Auto Commit Transactions

Pgina 4 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Explicit Transactions

Pgina 5 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Implicit Transactions

Pgina 6 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Transaction Recovery

Pgina 7 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Considerations for using Transactions

Pgina 8 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Methods of Concurrency Control

Pgina 9 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
What are Locks?

Pgina 10 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Blocking vs. Locking

Pgina 11 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
What Concurrency Problems are Prevented by Locking?

Pgina 12 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Lockable Resources

Pgina 13 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Types of Locks

Pgina 14 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Lock Compatibility

Pgina 15 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Locking Timeout

Pgina 16 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Lock Escalation

Pgina 17 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
What are Deadlocks?

Pgina 18 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Locking-related Table Hints

Pgina 19 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Methods to View Locking Information

Looking at transaction duration with the sys.dm_tran_active_transactions DMV for the blocking
session can help determine whether the problem is related to long-running user transactions.
In addition, enable the Blocked Process Report with sp_configure and then collect it using SQL
Trace to capture detailed information about blocking.

sp_configure 'blocked process threshold',5

Profiler: Events Selection Events Errors and Warnings Blocked Process Report

sys.dm_tran_locks
sys.dm_tran_active_transactions
sys.dm_tran_session_transactions
sys.dm_tran_current_transaction
sys.dm_os_waiting_tasks

Pgina 20 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
SQL Server Transaction Isolation Levels

Pgina 21 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Read Committed Snapshot

Read Committed Snapshot is a database option that, when enabled, causes DML statements to start generating row versions, even when no transaction is using snapshot
isolation.
Transactions that specify read committed are automatically altered to use row versioning rather than locking.
All statements see a snapshot of data as it existed at the start of the statement.

Pgina 22 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
Isolation-related Table Hints

Pgina 23 de 24
SQL Server Tuning and Optimizing Queries Module 06 Managing Concurrency - Notes
TempDB Performance Considerations

The Version Store

Many features in SQL Server 2008 require multiple versions of rows to be maintained, and the version store is used to store these different versions of index and data rows.
The following features make use of the version store:
Triggers: These have used row versions since SQL Server 2005, rather than scan the transaction log as they did in SQL Server 2000.
Snapshot Isolation and Read-Committed Snapshot Isolation: isolation levels based on versioning of rows, rather than locking.
Online Index Operations: Row versioning to support index updates during an index rebuild.
MARS (Multiple Active Result Sets): Row versioning to support interleaving multiple batch requests across a single connection.

Pgina 24 de 24