Rob's SQL Server Blog : 2000

SQL Server Locking

robcarrol — Sun, 18 May 2008 10:30:00 GMT

Locking is a mechanism used by the Microsoft SQL Server Database Engine to synchronize access by multiple users to the same piece of data at the same time.

Before a transaction acquires a dependency on the current state of a piece of data, such as by reading or modifying the data, it must protect itself from the effects of another transaction modifying the same data. The transaction does this by requesting a lock on the piece of data. Locks have different modes, such as shared or exclusive. The lock mode defines the level of dependency the transaction has on the data. No transaction can be granted a lock that would conflict with the mode of a lock already granted on that data to another transaction. If a transaction requests a lock mode that conflicts with a lock that has already been granted on the same data, the instance of the Database Engine will pause the requesting transaction until the first lock is released.

When a transaction modifies a piece of data, it holds the lock protecting the modification until the end of the transaction. How long a transaction holds the locks acquired to protect read operations depends on the transaction isolation level setting. All locks held by a transaction are released when the transaction completes (either commits or rolls back).

Applications do not typically request locks directly. Locks are managed internally by a part of the Database Engine called the lock manager. When an instance of the Database Engine processes a Transact-SQL statement, the Database Engine query processor determines which resources are to be accessed. The query processor determines what types of locks are required to protect each resource based on the type of access and the transaction isolation level setting. The query processor then requests the appropriate locks from the lock manager. The lock manager grants the locks if there are no conflicting locks held by other transactions.

TRANSACTION ISOLATION LEVEL

Controls the locking and row versioning behavior of Transact-SQL statements issued by a connection to SQL Server. There are 5 levels:

READ UNCOMMITTED:

Statements can read rows that have been modified by other transactions but not yet committed.

READ COMMITTED:

Specifies that statements cannot read data that has been modified but not committed by other transactions. This prevents dirty reads. Data can be changed by other transactions between individual statements within the current transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.

REPEATABLE READ:

Specifies that statements cannot read data that has been modified but not yet committed by other transactions and that no other transactions can modify data that has been read by the current transaction until the current transaction completes.

SNAPSHOT:

Specifies that data read by any statement in a transaction will be the transactionally consistent version of the data that existed at the start of the transaction.

SERIALIZABLE:

Statements cannot read data that has been modified but not yet committed by other transactions. No other transactions can modify data that has been read by the current transaction until the current transaction completes. Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.

More details on all the transaction isolation modes can be found here in Books Online

Lock Granularity and Hierarchies

Locking at a smaller granularity, such as rows, increases concurrency but has a higher overhead because more locks must be held if many rows are locked. Locking at a larger granularity, such as tables, are expensive in terms of concurrency because locking an entire table restricts access to any part of the table by other transactions. However, it has a lower overhead because fewer locks are being maintained.

The following table shows the resources that the Database Engine can lock.

Resource	Description
RID	A row identifier used to lock a single row within a heap.
KEY	A row lock within an index used to protect key ranges in serializable transactions.
PAGE	An 8-kilobyte (KB) page in a database, such as data or index pages.
EXTENT	A contiguous group of eight pages, such as data or index pages.
HOBT	A heap or B-tree. A lock protecting an index or the heap of data pages in a table that does not have a clustered index.
TABLE	The entire table, including all data and indexes.
FILE	A database file.
APPLICATION	An application-specified resource.
METADATA	Metadata locks.
ALLOCATION_UNIT	An allocation unit.
DATABASE	The entire database.

Lock Modes

The Microsoft SQL Server Database Engine locks resources using different lock modes that determine how the resources can be accessed by concurrent transactions.

The following table shows the resource lock modes that the Database Engine uses.

Lock mode	Description
Shared (S)	Used for read operations that do not change or update data, such as a SELECT statement.
Update (U)	Used on resources that can be updated. Prevents a common form of deadlock that occurs when multiple sessions are reading, locking, and potentially updating resources later.
Exclusive (X)	Used for data-modification operations, such as INSERT, UPDATE, or DELETE. Ensures that multiple updates cannot be made to the same resource at the same time.
Intent	Used to establish a lock hierarchy. The types of intent locks are: intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX).
Schema	Used when an operation dependent on the schema of a table is executing. The types of schema locks are: schema modification (Sch-M) and schema stability (Sch-S).
Bulk Update (BU)	Used when bulk copying data into a table and the TABLOCK hint is specified.
Key-range	Protects the range of rows read by a query when using the serializable transaction isolation level. Ensures that other transactions cannot insert rows that would qualify for the queries of the serializable transaction if the queries were run again.

Full details of SQL Server's lock modes can be found in this article.

Lock Compatibility (Database Engine)

Multiple transactions can acquire concurrent locks on the same resource if their lock modes are compatible. If a transaction requests a lock mode that conflicts with an existing lock, the transaction is paused until the first lock is freed. For a full list of lock mode compatibilty see this article

Key-Range Locking

Key-range locks protect a range of rows implicitly included in a record set being read by a Transact-SQL statement while using the serializable transaction isolation level. The serializable isolation level requires that any query executed during a transaction must obtain the same set of rows every time it is executed during the transaction. A key range lock protects this requirement by preventing other transactions from inserting new rows whose keys would fall in the range of keys read by the serializable transaction.

Key-range locking prevents phantom reads. By protecting the ranges of keys between rows, it also prevents phantom insertions into a set of records accessed by a transaction.

A key-range lock is placed on an index, specifying a beginning and ending key value. This lock blocks any attempt to insert, update, or delete any row with a key value that falls in the range because those operations would first have to acquire a lock on the index. For example, a serializable transaction could issue a SELECT statement that reads all rows whose key values are between 'AAA' and 'CZZ'. A key-range lock on the key values in the range from 'AAA' to 'CZZ' prevents other transactions from inserting rows with key values anywhere in that range, such as 'ADG', 'BBD', or 'CAL'.

More details can be found in Books Online here

Lock Escalation

Lock escalation is the process of converting many fine-grain locks into fewer coarse-grain locks, reducing system overhead while increasing the probability of concurrency contention. See the Lock Escalation (Database Engine) chapter on BOL for full details

Dynamic Locking

The Microsoft SQL Server Database Engine uses a dynamic locking strategy to determine the most cost-effective locks. The Database Engine automatically determines what locks are most appropriate when the query is executed, based on the characteristics of the schema and query. For example, to reduce the overhead of locking, the optimizer may choose page-level locks in an index when performing an index scan.

Dynamic locking has the following advantages:

Simplified database administration. Database administrators do not have to adjust lock escalation thresholds
Increased performance. The Database Engine minimizes system overhead by using locks appropriate to the task
Application developers can concentrate on development. The Database Engine adjusts locking automatically

Displaying Locking Information (Database Engine)

Microsoft SQL Server 2005 provides several ways to get information about the current locking activity in an instance of the Database Engine.

Deadlocking

A deadlock occurs when two or more tasks permanently block each other by each task having a lock on a resource which the other tasks are trying to lock. Both transactions in a deadlock will wait forever unless the deadlock is broken by an external process. More information on deadlocks and techniques to avoid them can be found in BOL.

SQL Server and Windows Memory

robcarrol — Thu, 15 May 2008 17:02:00 GMT

SQL Server 2000 Enterprise Edition introduced support for the use of Windows 2000 Address Windowing Extensions (AWE) to address 8GB of memory on Windows 2000 Advanced Server and 32GB of memory on Windows 2000 Datacentre. With AWE, SQL Server can reserve memory not in use by other applications and the OS. Each instance must statically allocate the memory it needs. AWE memory can only be used for the data cache and not for executables, drivers, DLL's, etc.

SQL Server 2000 on Windows 2003/Windows 2000 Advanced Server/Windows 2000 Datacentre:

The use of /PAE and AWE allows SQL Server 2000 to use more than 4GB of RAM. Without /PAE, SQL can only use up to 3GB (with /3GB switch enabled in boot.ini). To allow AWE to use the the memory range above 16GB on Windows 2000 Datacentre, the /3GB switch must not be enabled in the server's boot.ini file. When you allocate SQL Server AWE memory on a 32GB system, Windows 2000 may require at least 1GB memory to manage AWE.

SQL Server 2000 Enterprise and Developer Editions are the only editions that can use AWE.

USING AWE MEMORY (SQL Server 2000)

Run the database engine under a Windows account with the "lock data pages in memory" option enabled. SQL Server setup will automatically grant this permission. If you start an instance from the command prompt (sqlservr.exe), you must manually assign this permission using gpedit.msc. Set the sp_configure option AWE ENABLED and restart SQL Server.

Instances of SQL Server 2000 do not dynamically manage the size of the address space when you enable AWE memory. When you enable AWE and start an instance of SQL 2000, one of the following occurs:

If sp_configure max server memory has been set and there are at least 3GB RAM free on the computer, the instance acquires the amount of memory specified in max server memory
If the amount of memory available is less than max server memory (but more than 3GB), then the instance acquires almost all of the available memory and may leave only up to 128MB of memory free
If max server memory has not been set and there is at least 3GB of free memory available, then the instance acquires almost all of the available memory and may leave only up to 128MB of memory free
If there is less than 3GB of free memory available, memory is dynamically allocated and, regardless of the parameter setting for AWE ENABLED, SQL Server will run in non-AWE mode

Evaluating Memory Usage

Use System Monitor to obtain the correct amount of SQL Server memory usage:

Total Server Memory (KB)
Select memory usage from sysperfinfo

Running Multiple instances with AWE on SQL Server 2000

Each instance must have a max server memory setting.

Sum of max server memory values for all instances should be less than the amount of physical memory on the server. If the sum greater, some of the instances will either not start or will have less memory than is specified in max server memory.

Windows 2000 Usage Considerations:

Before configuring Windows 2000 for AWE memory:

Add the /PAE switch to boot.ini
Add the /3GB switch to enable Windows 2000 Advanced Server and Windows 2000 Datacentre to support a 3GB virtual address space. This allows user applications to address 3 GB of virtual memory and reserves 1 GB of virtual memory for the operating system. However, if there is more than 16 GB of physical memory available on a computer, Windows 2000 needs 2 GB of virtual memory address space for system purposes and therefore can support only a 2-GB virtual address space.
In order to allow AWE to use the memory range above 16 GB, be sure the /3gb parameter is not in the boot.ini file. If it is, Windows 2000 will be unable to address any memory above 16 GB. When allocating SQL Server AWE memory on a 32-GB system, Windows 2000 may require at least 1 GB of available memory to manage AWE. Therefore, when starting an instance of SQL Server with AWE enabled, it is recommend you do not use the default max server memory setting, but instead limit it to 31 GB or less

Using Failover Clustering:

If you are using SQL Server 2000 failover clustering and AWE memory, you must ensure that the summed value of the max server memory settings for all the instances is less than the lowest amount of physical RAM available on any of the servers in the failover cluster. If the failover node has less physical memory than the original node, the instances of SQL Server 2000 may fail to start or may start with less memory than they had on the original node.

SQL SERVER 2005

To enable AWE for SQL Server 2005:

Run the SQL Server account under a Windows account with "Lock Pages in Memory" permissions assigned.
Use sp_configure to set "awe enabled" option to 1
The "Maximize Data Throughput for Network Application" in Control Panel must be selected.

Support for AWE is available only in the SQL Server 2005 Enterprise, Standard and developer editions and only applies to 32-bit OS's. SQL Server 2005 Analysis Services (SSAS) cannot take advantage of AWE mapped memory. If available physical memory is less than the user mode VAS, AWE cannot be used.

Lock pages in memory: Prevents paging the data to virtual memory or disk. Set to OFF by default in SQL Server 2005.

SQL Server 2005 Enterprise Edition can access up to 64GB of memory on Windows 2000 and Windows Server 2003.

Instances of SQL Server 2005 running on Windows 2000 use static AWE memory allocation, instances running on Windows Server 2003 use dynamic AWE memory allocation.

To support over 4GB of physical memory, the /PAE switch must be added to boot.ini file. If more than 16GB of physical memory, the OS needs 2GB of virtual address space for system purposes and can therefore support only a 2GB user mode virtual address space. Remove /3GB from boot.ini file in order to use this memory above 16GB.

The SQL Server buffer pool can fully utilise AWE mapped memory, however only database pages can be dynamically mapped to and unmapped from SQL Server's virtual address space and take full advantage of memory allocated through AWE.

AWE does not directly help supporting additional users, threads, databases, queries and other objects that permanently reside in the virtual address space.

SQL Server 2005 Features Comparison