Beginning SQL

Chapter 11
Database
There are perfectly valid reasons for locking the entire database. Perhaps a process requires making
changes to most of the tables in the database, perhaps even the structure of a large number of tables.
Getting locks to each table to be modified, in the correct order, can take a long time. It might make sense
in this instance just to lock the entire database, but of course you should do this as seldom as possible.
Do so at times when you have the fewest users trying to access data, and make your updates as quickly
as possible.
Table
The next level of locking is an entire table. Say a manufacturer wants to update the price on every item
they sell by 5 percent. Rather than locking each record, locking the table that contains the record, running
an UPDATE query on every record in a single SQL statement, and then releasing the lock would be far
faster.
Page
DBMSs tend to work with the physical medium that they are stored on to help them manage the data.
The DBMS may break its table data down into chunks that fit in a sector on the disk. These chunks are
called pages, and of course the page size often corresponds to the sector size of the hard disk. Thus, if the
disk has a sector size of 16K, the DBMS applies locks to an entire page since this maps easily to lock
requests sent to the operating system. For this reason, disks used for storing databases may be most efficient
if formatted with the smallest sector size available (within reason). Obviously, a 2K sector locks
fewer data rows than an 8K or a 32K sector. In the end, a record in a given table usually holds a specific
number of bytes. If a record has five fields that hold 400 bytes, then a 2K sector locks roughly five or six
such records (assuming page locks are used), but an 8K sector locks 20 records, and a 32K sector locks 80
records. As you can see, large sector sizes lock very large chunks of a table even if you need to lock only
a small part of the table.
Row
Many modern databases allow locking to the row, or record, level. This means that other users without
interactions may use adjacent records in the database. Of course, this is good, but remember that each
lock requires manipulation by the DBMS. If 40 percent of all the records in a table need to be updated by
a mass update, and the table contains a million records, it makes much more sense to just lock the table
rather than apply for 400,000 record-level locks. On the other hand, if only 100 of those million records
need updating, asking for 100 record locks minimizes the inconvenience to other users who still need to
use the table.
Column
Although it is theoretically possible to lock data at the column level, few if any DBMSs do so. The overhead
to track the locks at this granularity is simply too high and the benefit too small.
Locking Levels
314
In addition to the granularity or size of the data unit being locked, locks also have a property known as
the level. The level determines how rigidly the lock is applied and whether any other user can use the
data in any manner. The first locking level is the shared lock.