SQL Server Storage Engine : Concurrency

Overhead of Row Versioning

Sunil Agarwal — Sun, 30 Mar 2008 02:41:00 GMT

Last week I was teaching a class on snapshot isolation and we discussed the overheads of snapshot isolation. There are three main overheads that you need to be aware of when you enable snapshot isolation read-committed-snapshot on a database. First, each UPDATE/DELETE operation generates a row version. Note, that the row version is not generated when you INSERT a new row but a 14 byte overhead (described below) is added to the inserted row . There is an exceptions to this, but I will skip that discussion here. Second, row versions are created and kept in tempdb that leads to increase space usage and IOs there. Third, the queries run under snapshot isolation or read-committed-snapshot need to traverse the row version chain which may lead to as many logical IOs and potentially as many 'random' physical IOs because row versions for a given row are not necessarily on the same or even contiguous physical page(s). It is interesting to note that if we did not traverse the row versions, the query would have blocked otherwise. So basically, at some expense of IO/CPU, the SQL Server can return the transactional consistent results without incurring blocking. We recommend enabling row versioning based isolation levels only when your application is incurring reader/writer blocking.

One question that came up was on the overhead of row versioning on the data or index row. When you enable snapshot isolation or read-committed-snapshot option on the database, the SQL Server starts adding a 14 byte overhead to each row to keep the following information:

XTS (transaction sequence number). It takes 6 bytes. This is used for marking the XSN that did the DML operation on the row
RID (row identifier) that points to the versioned row. It takes 8 bytes.

But this overhead is only added when an existing row is actually modified or if the database was already enabled for either of these options. Let me give a very simple example.

create table foo..t2_snapshot (c1 int)

insert into foo..t2_snapshot values (1)

-- show the max rowsize in bytes

select max_record_size_in_bytes

from sys.dm_db_index_physical_stats (db_id('foo'),

object_id('foo.t2_snapshot'),

null, null, 'DETAILED')

This will show a max row size of 11 bytes (note, the 7 bytes are the metadata overhead within the row and other 4 bytes store the integer value). Now, let me enable snapshot isolation on the database foo. Note, this is a metadata operation and it will NOT change the existing rows in the tables to add extra 14 bytes.

alter database foo set allow_snapshot_isolation ON

-- you can verify the datbaase state using the following

select is_read_committed_snapshot_on, snapshot_isolation_state_desc,

snapshot_isolation_state from sys.databases where name='foo'

Now I run the query

select max_record_size_in_bytes

from sys.dm_db_index_physical_stats (db_id('foo'),

object_id('foo.t2_snapshot'),

null, null, 'DETAILED')

You will notice that the row length still remains 11 bytes. No extra 14 bytes overhead even though the database foo has been enabled for snapshot isolation. Let us now update the data row as follows

update foo..t2_snapshot set c1 = 2

After the update, you will notice the length of the row has become 25 bytes. In other words, there is a 14 byte overhead. Also, the new rows that you insert will have a length of 25 bytes (including row versioning overhead of 14 bytes).There are two interesting observations to be made. First, an update of a fixed length column may lead to page splits because the length of the row has increased. This only happens the first time the row is updated. Second, the increased row length will cause the table size to grow. A typical row size in production is around 300 bytes. So this means that snapshot isolation or read-committed-snapshot will cause 5% growth in the size of the table (in the worst case when all the rows were updated). One point to keep in mind is that new rows inserted after SI/RCSI, will have this 14 byte overhead even though there is no row version to point to.,

Now, if I disable the snapshot isolation and update the same row again, the extra 14 bytes will go away. This is because row versioning has been disabled. I can do the same by rebuilding the index

Thanks

Sunil

Read-Only filegroups and Locking

Sunil Agarwal — Mon, 08 Jan 2007 08:28:00 GMT

I recently saw a newsgroup post that sort of implied that accessing data residing on read-only filegroups can save you on locking. Well, it could, but it does not. If you really want to save on locks, the whole database needs to be set to read-only.

Back to read-only filegroups. They provide you the following three benefits:

Can be compressed (using NTFS compression)
During recovery you don’t need to apply logs to recover a read-only file group
Protection of data from accidental modifications

But as far as locking is concerned, SQL Server still gets the locks when you access data from read-only filegroup. Here is one simple example:

use general

alter database general add filegroup foo

alter database general add file (

name = file1,

filename = 'c:\temp\file1')

to filegroup foo

-- create a table and associate it to a filegroup

create table t_fg (c1 int, c2 int) on foo

insert into t_fg values (1,1)

-- mark the filegroup read-only

alter database general modify filegroup foo read_only

-- run a transaction with repeatable read isolation

set transaction isolation level repeatable read

begin tran

select * from t_fg where c1 = 1

-- no check the locks

sp_lock @@spid

-- here is the output

spid dbid ObjId IndId Type Resource Mode Status

------ ------ ----------- ------ ---- -------------------------------- -------- ------

53 10 1381579960 0 RID 3:8:0 S GRANT

53 10 0 0 DB S GRANT

53 10 1381579960 0 PAG 3:8 IS GRANT

53 10 1381579960 0 TAB IS GRANT

53 1 1115151018 0 TAB IS GRANT

Troubleshooting deadlocks in SQL2005

Sunil Agarwal — Mon, 05 Jun 2006 18:18:00 GMT

Deadlock in the context of SQL Server means two or more transactions or tasks are waiting on each other to acquire the resources needed to complete. A resource can be a logical lock or can be memory grant or can be a worker thread and so on.

Normally, when a transaction T1 requests a lock to access a resource, it may get blocked because some other transaction T2 may have already locked the resource in a conflicting mode. In that case, T1 waits for the lock to be released before proceeding. Under normal operations, one T2 releases the lock; it is then acquired by T1. Two blocking scenarios are of interest here. First, what if T2 never releases the lock? In this case, unless a lock time out is specified, T1 will wait indefinitely. SQL Server has no way of knowing that it is indeed the case and it does not do anything. An external intervention is required to break it, typically by killing the first transaction. Second, what if T2 requests a lock on another resource that is already locked by T1 in conflicting mode? Since T1 is waiting for T2, and now T2 is waiting for T1, it results in a deadlock and in this case no amount of waiting will help. SQL Server has implemented the logic to detect such cycles in resource acquisition since the very beginning. A background task, called the deadlock monitor, checks for cycles periodically, typically every 5 seconds but it can vary depending how often the deadlock is detected. When a deadlock is discovered, it breaks the deadlock by choosing a victim that has consumed to the lowest resources so far. The victim’s session will get 1205 error and the transaction will be aborted. SQL Server provides you some control, by means of deadlock priority, which task will be chosen as deadlock victim.

When a session gets 1205 error, it does not provide any information on why the deadlock happened, what sessions and resources were involved in the deadlock cycle. Without this information, it is difficult to understand the causes of deadlock and to prevent or minimize it in the future. To get the detailed diagnostic information on the deadlock, it is recommended that you run SQL Server with TF-1222 (new in SQL2005) and provides you more detailed information than the related TF-1204 which also can be used for the similar purpose. Note there is no performance overhead of running SQL Server with these traces flags enabled as these trace flags don’t control deadlock monitor task. However, if your SQL Server encounters deadlocks frequently, you may see some impact as the detailed diagnostic information needs to be generated for every deadlock.

Let us consider an example of a simple deadlock between two transactions as shown in the table below. You will notice that T1 holds X lock on all rows with c1=5 on table t_lock1 while T2 holds X lock on all rows with C1=1 on table t_lock2. Now each of these transactions wants to update the rows previously locked by the other. This results in a deadlock.

Transaction T1	Transaction T2
begin tran update t_lock1 set c2 = 10 where c1 = 5	begin tran update t_lock2 set c2 = 10 where c1 = 1
update t_lock2 set c2 = 10 where c1 = 1	update t_lock1 set c2 = 11 where c1 = 5
commit	commit

Here is the output of TF-1222 (with prefix information removed for clarity) that is generated for this deadlock event. This provides lots of useful details (hi-lighted) like the sessions involved in the deadlock, the locks currently held, locks they are blocked on, and the currently executing statements. It shows that there are two sessions (listed under <process-list>) that are blocked on each other and there two resources (listed under <resource-list>) indicating lock owners and waiters. Note, there is no detail when and where the lock was acquired. For that you will need to analyze all the statements in each of the tasks. With this information, you may be able to identify the cause of the deadlock and then make appropriate changes in the application to reduce its occurrence. For the deadlock in the example here, you can possibly eliminate this deadlock in two ways. First, you can execute each statement in its own transaction (i.e. by keeping the transaction short). Second, you can change the order of update statements in one of the transaction such that they access the tables in the same order (i.e. access objects in the same order). However, this may not always be possible for a given application logic. For more details please refer to product documentation.

<deadlock-list>

<process-list>

<process id="process698d48" taskpriority="0" logused="216" waitresource="RID: 6:1:143:4" waittime="5027" ownerId="4031" transactionname="user_transaction" lasttranstarted="2005-12-28T17:44:51.830" XDES="0x3dcba00" lockMode="U" schedulerid="1" kpid="892" status="suspended" spid="53" sbid="0" ecid="0" priority="0" transcount="2" lastbatchstarted="2005-12-28T17:44:56.147" lastbatchcompleted="2005-12-28T17:44:51.830" clientapp="Microsoft SQL Server Management Studio - Query" hostname="SUNILA2" hostpid="904" loginname="REDMOND\sunila" isolationlevel="read committed (2)" xactid="4031" currentdb="6" lockTimeout="4294967295" clientoption1="671090784" clientoption2="390200">

UPDATE [t_lock1] set [c2] = @1 WHERE [c1]=@2 </frame>

update t_lock1 set c2 = 11 where c1 = 5 </frame>

</executionStack>

update t_lock1 set c2 = 11 where c1 = 5 </inputbuf>

</process>

<process id="process699978" taskpriority="0" logused="216" waitresource="RID: 6:1:181:0" waittime="90" ownerId="4021" transactionname="user_transaction" lasttranstarted="2005-12-28T17:44:45.720" XDES="0x3dcade0" lockMode="U" schedulerid="1" kpid="3748" status="suspended" spid="52" sbid="0" ecid="0" priority="0" transcount="2" lastbatchstarted="2005-12-28T17:45:01.080" lastbatchcompleted="2005-12-28T17:44:45.720" clientapp="Microsoft SQL Server Management Studio - Query" hostname="SUNILA2" hostpid="3796" loginname="REDMOND\sunila" isolationlevel="read committed (2)" xactid="4021" currentdb="6" lockTimeout="4294967295" clientoption1="671090784" clientoption2="390200">

UPDATE [t_lock2] set [c2] = @1 WHERE [c1]=@2 </frame>

update t_lock2 set c2 = 10 where c1 = 1 </frame>

</executionStack>

update t_lock2 set c2 = 10 where c1 = 1 </inputbuf>

</process>

</process-list>

<resource-list>

<ridlock fileid="1" pageid="143" dbid="6" objectname="general.dbo.t_lock1" id="lock35c6e40" mode="X" associatedObjectId="72057594041139200">

<owner-list>

</owner-list>

<waiter-list>

<waiter id="process698d48" mode="U" requestType="wait"/>

</waiter-list>

</ridlock>

<ridlock fileid="1" pageid="181" dbid="6" objectname="general.dbo.t_lock2" id="lock35c7040" mode="X" associatedObjectId="72057594041270272">

<owner-list>

</owner-list>

<waiter-list>

<waiter id="process699978" mode="U" requestType="wait"/>

</waiter-list>

</ridlock>

</resource-list>

</deadlock>

</deadlock-list>

You can also get a graphical representation of this deadlock by enabling deadlock_graph event. The best way to troubleshoot deadlocks is to avoid one by designing your application appropriately. We touched upon couple of those in the previous example. Here are some general guidelines:

· Use short transactions where possible. Longer running transaction that the locks are held longer thereby increasing the likelihood of deadlock.

· Avoid user interactions within a transaction. User interactions can potentially take a long unbounded amount of time. This can hold up the crucial resources in your application and deny other transactions from proceeding.

· Try at access resources in the same order. Like we described in the example above, if all transactions access resources in the same order, you will minimize deadlocks.

· Run your transactions at lower level of isolation, if possible. This minimizes the duration of the locks held. Note, this is only applicable to SH locks only.

Use row versioning based isolation levels (e.g. SI and RCSI), where possible. Queries executing under these isolation levels don’t acquire any locks on the data. Note, queries will still acquire schema stability lock under these isolation levels, just like it is done for queries running under read-uncommitted isolation level and can get blocked if there is a concurrent DDL operation on the objects referenced in the query

Range locks

Sunil Agarwal — Fri, 26 May 2006 15:44:00 GMT

Lately I have seen some quesitons on range locks. Why certain keys are locked? How is this behavior different for unique vs. non-unique indexes? So I played around with range locks and here are my findings so far. Range locks are obtained on index keys to prevent phantoms when you execute transactions under serializable isolation. SQL Server implements this by taking range locks. There are two cases of interest

Equality Predicate
- If the key value exists, then the range lock is only taken if the index is non-unique. In the non-unique index case, the ‘range’ lock is taken on the requested key and on the ‘next’ key. If the ‘next’ key does not exist, then a range lock is taken on the ‘infinity’ value. If the index is unique then a regular S lock on the key.
- If the key does not exist, then the ‘range’ lock is taken on the ‘next’ key both for unique and non-unique index. If the ‘next’ key does not exist, then a range lock is taken on the ‘infinity’ value.

Range Predicate (key between the two values)
- ‘range lock on all the key values in the range when using ‘between’
- ‘range’ lock on the ‘next’ key that is outside the range. This is true both for unique and non-unique indexes. This is to ensure that no row can be inserted between the requested key and the one after that. If the ‘next’ key does not exist, then a range lock is taken on the ‘infinity’ value.

Let us consider two examples:

Example-1:

create table foo (c1 int)

insert into foo values (1)

insert into foo values (2)

insert into foo values (3)

insert into foo values (4)

insert into foo values (5)

create unique clustered index foo_ci on foo(c1)

set tran isolation level serializable

begin tran

select * from foo where c1 between 2 and 4

Once this query is executed, your locks will look as follows (I used sys.dm_tran_locks DMV available in SQL2005)

resourcetype resourcedesc request_mode

------------ -------------------- ------------------------------------------------------------

1:8546 1:8546 IS

(020068e8b (020068e8b274) RangeS-S (this is a range lock on value 2)

(0400b4b7d (0400b4b7d951) RangeS-S (this is a range lock on value 4)

(03000d8f0 (03000d8f0ecc) RangeS-S (this is a range lock on value 3)

(0500d1d06 (0500d1d065e9) RangeS-S (this is a range lock on value 5)

(10 row(s) affected)

Since it is a unique index, we don’t really have to get a range lock on 5 but SQL Server takes it anyway. However for non-unique index, SQL Server needs to lock the key 5 for reasons described earlier.

Exanple-2:

If you issue the following query

begin tran

select * from foo where c1 = 4

In this case there will be no range lock taken as the index is unique. However, if the index is not unique then SQL Server will acquire range lock on key value 4 and 5 as follows

resourcetype resourcedesc request_mode

------------ -------------------- ------------------------------------------------------------

1:8546 1:8546 IS

(060004b73 (060004b73a86) RangeS-S (this is a range lock on value 4)

(0500b49e5 (0500b49e5abb) RangeS-S (this is a range lock on value 5)

In the above example, if I use the following query

begin tran

select * from foo where c1 = 0

A range lock will be taken on key value 1 both for unique and non-unique index.Thsi is because the key value '0' does not exist.

Sunil

Lock Escalation in SQL2005

Sunil Agarwal — Wed, 17 May 2006 21:06:00 GMT

Lock Escalation:

If you consider the hierarchy of the objects in a SQL Server instance, at the top level you have the database, followed by schema, tables, table partitions, pages and then finally the individual rows. If you acquire a lock at higher level, it can cover more resources there by you consume fewer lock resources (each lock structure takes approximately 100 bytes) and the locking overhead but this comes at a price of lower concurrency. So for example, if you want to select all the rows of a table, if you acquire a lock a table level, you will not need to lock individual rows or pages but then it will block any concurrent update transaction. Similarly, if you lock individual rows, you will get higher concurrency but then you will incur the overhead of acquiring/releasing locks on each row and lot more locking resources depending upon the isolation level of your transaction, as you may need to hold the locks on all the rows till the end of transaction. Fortunately, for most users don’t need not concern themselves with nuances of locking strategy as deployed by SQL Server. Depending upon the estimates during query compilation, the SQL Server recommends the locking granularity (i.e. row, page or table) appropriately and during query execution, depending on the concurrent work load, the appropriate locking granularity is applied. User can override the locking granularity option explicitly by providing locking hints and/or by executing sp_indexoption stored procedure. While locking granularity is chosen at the start of query execution but during the execution, the SQL Server may choose to escalate the lock to coarser level of granularity depending on the number of locks acquired and the availability of memory at run time. Currently, SQL Server only supports escalating the locks to the table level. The locks can only be escalated from rows to the table or pages to the table level. Locks are never escalated from rows to the parent page or from pages to the owning partition.

Triggering Lock Escalation:

A lock escalation is triggered when any of the following conditions is true

· The number of locks held (different from acquired) by a statement on an index or a heap within a statement exceeds the threshold (currently set to 5000 (approx)). These locks include the intent locks as well. Note the lock escalation will not trigger if

o The transaction acquires 2,500 locks each on two index/heap(s) in a single statement.

o The transaction acquires 2,500 locks on the non-clustered index and 2,500 locks on the corresponding base table in a single statement.

o The same heap/index is referenced more than one time in a statement; the locks on each instance of those are counted separately. So for example, in the case of a self-join on a table t1, if each instance has 3000 locks within the statement, it will not trigger lock escalation

· The memory taken by lock resources > 40% of the non-AWE (32-bit) or regular (64-bit) enabled memory when the locks configuration option is set to 0, the default value. In this case, the lock memory is allocated dynamically as needed.

· The memory taken by lock resources is > 40% of the configured memory of locks (i.e. when a non-zero value for the locks configuration option). When locks configuration option is used, the locks memory is statically allocated when SQL Server starts.

When the lock escalation is triggered, the SQL Server attempts to escalate the lock to table level but the attempt may fail if there are conflicting locks. So for example, if the SH locks need to be escalated to the table level and there are concurrent X locks on one or more rows/pages of the target table, the lock escalation attempt will fail. However, SQL Server periodically, for every 1250 (approx) new locks acquired by the lock owner (e.g. transaction), attempts to escalate the lock. If the lock escalation succeeds, the SQL Server releases the lower granularity locks, and the associated lock memory, on the index or the heap. A successful lock escalation can potentially lead to blocking (because at the time of lock escalation, there cannot be any conflicting access) of future concurrent access to the index or the heap by transactions in conflicting lock mode. So the lock escalation is not always a good idea for all applications.

Disabling Lock Escalation:

SQL2005 provides supports disabling lock escalation using two trace flags as follows:

· TraceFlag-1211: It disables lock escalation at the current threshold (5000) on a per index/heap per statement basis. When this trace flag is in effect, the locks are never escalated. It also instructs SQL Sever to ignore the memory acquired by the lock manager up to a maximum statically allocated lock memory or 60% of non-AWE(32-bit)/regular(64-bit) of the dynamically allocated memory. At this time an out of lock memory error is generated. This can potentially be damaging as a misbehaving application can exhaust SQL Server memory by acquiring large number of locks. This, in the worst case, can stall the Server or degrade its performance to an unacceptable level. For these reasons, a caution must be exercised when using this trace flag

· TraceFlag-1224: This trace flag is similar to trace flag 1211 with one key difference. It enables lock escalation when lock manager acquires 40% of the statically allocated memory or (40%) non-AWE(32-bit)/regular(64-bit) dynamically allocated memory. Additionally, if this memory cannot be allocated due to other components taking up more memory, the lock escalation can be triggered earlier. SQL Server will generate an out of memory error when memory allocated to lock manager exceeds the statically allocated memory or 60% of non-AWE(32-bit)/regular memory for dynamic allocation.

If both trace flags (1211 and 1224) are set at the same time, the trace flag 1211 takes precedence. You can use dbcc tracestatus (-1) command to find the status of all trace flags enabled in SQL Server.

Please also refer to the http://support.microsoft.com/kb/323630/en-us.

Limitations of Lock Escalation:

There are some limitations in the current lock escalation mechanism in SQL Server. We will consider removing one or more of these limitations in future.

· Trace flags can only be used to disable lock escalation at an instance level. More often than not, you want to disable lock escalation at an object level. You can get around this issue by starting a dummy transaction and locking a resource (e.g. a row) to prevent lock escalation.

· The lock escalation triggering is hard coded to approx 5000 locks which may be too many locks for a small table and too few for a large table.

Locks are not escalated to individual table partitions, but to the table instead. So two users accessing distinct partitions of a table in conflicting mode may get blocked immediately after lock escalation.