Home > Articles > Databases > SQL Server

SQL Server Reference Guide

< Back Page 87 of 361 Next >

SQL Server Locks

Last updated Mar 28, 2003.

This is a topic which can really live in almost any area of the SQL Server Guide here at InformIT. The behavior I’ll describe in this tutorial can be caused by design, programs, administration practices and even – nothing at all. The reason is that locks are an inherent part of a Relational Database design. In this overview I’ll explain what locks are and how they happen. In the next few tutorials I’ll explain the tools and processes you can use to locate and deal with them.

Locking, Blocking and Deadlocks

If you’re not familiar with the basics of Relational Databases, check out this link before you read on. If you are familiar with Relational Database Engines, then you recall that tables are normalized into as many discrete entities as possible. The data gets spread out into multiple tables, and then joined back again to make a unit of whatever makeup you need. While this is a good design for speed and flexibility, it has real consequences. Because the data can be read and changed by multiple connections, the system needs a way to maintain integrity. Let’s take a look at a concrete example of how a lock comes about, and then tie that in to the databases we use every day.

Assume that you’re one of the salespeople for a bicycle shop. You, along with other salespeople, meet willing customers at the door. A customer approaches you and says "I’d like to buy a red mountain bike. Do you have any of those?" "I’ll check", you reply, and you open your application to the AdventureWorks database to check the inventory. Sure enough, you see that you have one red mountain bicycle left. You sell it to the customer. Meanwhile, on the other side of the showroom another salesperson is approached by a different customer who also wants a red mountain bike. That salesperson opens the application a split second after you do and checks inventory for a red mountain bike.

The important thing is that both of you shouldn’t sell the same bicycle to two different people. To prevent that, all Relational Database Management Systems (RDBMS) implement locks on the data. While you’re looking at the inventory, the database will lock that data to make sure it doesn’t change. That doesn’t prevent someone else from looking at the data at the same time; it just prevents them from changing it. When you actually put in an order, which changes the inventory, another kind of lock prevents others from even looking at it.

So when you enter the sale, the other salesperson can’t see the amount of red mountain bikes that are in inventory, and they have to tell their customer to wait. The effect of this locking mechanism one the other salesperson is a block, and eventually it gets resolved when the resource the salesperson needs (the inventory numbers) is released by the first party. A moment later they see there aren’t any in stock, and they place an order for a new bike to be built. Everyone goes away happy.

That’s the general overview of how locking works, but before we dive into the details I need to explain one more interesting artifact of locking. When two resources depend on each other, then the system creates a deadlock. Deadlocks happens when one query says "I need the results of thing A to do thing B" and another query says "I need the results of thing B to do thing A". I’ll show you an example of this condition in the next tutorial, but without some way to resolve this condition, it lasts forever, with each query saying "No, YOU go first." SQL Server resolves this condition by picking one of the queries and making it a victim, literally killing what it was doing. Sort of like your dad saying "OK then, NO ONE gets the candy" when you and your brother started an argument in the back of the car.

It isn’t just data access that can cause locks. If you’re running certain kinds of maintenance activities on your system, it will need to take certain kinds of locks on the tables and databases to do its work. Also, if you change a column in a table, the system can’t reliably deliver data to the users, since it isn’t sure what you’re doing with that column, so it takes more locks. In fact, any change to the schema of a database takes a lock. Really anything that might have an impact on the integrity of data will cause a lock.

Microsoft SQL Server automatically handles locks. You don’t have to set aside any processing or memory resources to do that manually. You can affect how locks are handled with several statements dealing with what Microsoft calls "isolation levels" that can indicate to the engine what kind of locks you want, which query should be picked as a victim and so on. I’ll cover those in a bit.

Lock Interactions

Locks interact with various objects on your system. SQL Server has various objects that it can lock. As of this writing they include:

Object that can be locked	What they are
RID	A single row in a table without a clustered index.
KEY	A row lock within an index.
PAGE	An 8k page in a database.
EXTENT	A contiguous group of eight pages (64 K).
HOBT	An index or data pages in a table that does not have a clustered index.
TABLE	A 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.

Books Online of course has the latest information here.

SQL Server will automatically choose a type of lock. What this means is that it might be faster for the system to lock an entire table of data rather than calculate a row or two of data in that table. It can "get in and get out" faster than figuring out which rows to lock.

And some locks "grow" or escalate into larger locks. This means that a particular operation might start out locking a single page (8k) of data on the system, but then move on to locking an entire table, and then the whole database. In the next tutorial I’ll show you how you can see the locks and how they grow while you’re running queries.

Types of Locks

On each of the objects in the previous table, SQL Server can place different types of locks, called lock modes. Recall from our earlier example that while we were just looking at inventory we didn’t prevent another salesperson from looking at the same data. By changing the data, however, we prevented the other salesperson from looking at it. Also, while we were looking at the data we prevented the other salesperson from changing the data.

All of these actions represent different types of locks. There are locks that are placed at a high priority and others (called Intent Locks) that are given lower weight by the system. As of this writing, here are the types of locks (lock modes) SQL Server can take:

Type of lock	What it is used for
Shared (S)	Read operations that do not change data
Update (U)	Preventing many deadlocks.
Exclusive (X)	Data change operations
Schema	Changing the layout of an object.
Bulk Update (BU)	Bulk copying data into a table.
Key-range	Protecting a range of rows read by a query when using the serializable transaction isolation level (more on this later)
Intent shared (IS)	Protecting requested shared locks on some resources.
Intent exclusive (IX)	Protecting exclusive shared locks on some resources.
Shared with intent exclusive (SIX)	Protecting exclusive shared and exclusive locks on some resources.
Intent update (IU)	Protecting update locks on all resources.
Shared intent update (SIU)	A combination of S and IU locks.
Update intent exclusive (UIX)	A combination of U and IX locks.