Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

The only cure for this is setting your transaction isolation level to SERIALIZABLE, in which case any
updates to the table must not fall within your WHERE clause or they will be locked out.
Lost Updates
Lost updates happen when one update is successfully written to the database, but is accidentally overwritten
by another transaction. I can just hear you right about now, “Yikes! How could that happen?”
Lost updates can happen when two transactions read an entire record, then one writes updated information
back to the record and the other writes updated information back to the record. Let’s look at an example.
Let’s say that you are a credit analyst for your company. You get a call that customer X has reached their
credit limit and would like an extension, so you pull up their customer information to take a look. You
see that they have a credit limit of $5,000 and that they appear to always pay on time.
While you’re looking, Sally, another person in your credit department, pulls up customer X’s record to
enter a change in the address. The record she pulls up also shows the credit limit of $5,000.
At this point, you decide to go ahead and raise customer X’s credit limit to $7,500, and press Enter. The
database now shows $7,500 as the credit limit for customer X.
Sally now completes her update to the address, but she’s using the same edit screen that you are — that
is, she updates the entire record. Remember what her screen showed as the credit limit? $5,000. Oops,
the database now shows customer X with a credit limit of $5,000 again. Your update has been lost!
The solution to this depends on your code somehow recognizing that another connection has updated
your record between when you read the data and when you went to update it. How this recognition
happens varies depending on what access method you’re using.
Lockable Resources
There are six lockable resources for SQL Server, and they form a hierarchy. The higher level the lock, the
less granularity it has (that is, you’re choosing a higher and higher number of objects to be locked a cascading
type of action just because the object that contains them has been locked). These include, in
ascending order of granularity:
❑ Database: The entire database is locked. This happens usually during database schema changes.
❑ Table: The entire table is locked. This includes all the data-related objects associated with that
table, including the actual data rows (every one of them) and all the keys in all the indexes associated
with the table in question.
❑ Extent: The entire extent is locked. Remember than an extent is made up of eight pages, so an
extent lock means that the lock has control of the extent, the eight data or index pages in that
extent, and all the rows of data in those eight pages.
❑ Page: All the data or index keys on that page are locked.
Chapter 14: Transactions and Locks
❑ Key: There is a lock on a particular key or series of keys in an index. Other keys in the same
index page may be unaffected.
❑ Row or Row Identifier (RID): Although the lock is technically placed on the row identifier (an
internal SQL Server construct), it essentially locks the entire row.
437