Managing SQL Server

Transactions and Locks

Transaction and Locking

Architecture

SQL Server uses transactions to process a set of

Transact-SQL statements as a unit.
As a transaction is executed, locks are used to prevent
other users from accessing the data affected by that
transaction.
To support transactional processing, SQL Server
contains a number of architectural components,
including transaction logs, concurrency control,
locks, and support for distributed queries.

Transaction Log Architecture

Every SQL Server database has a transaction log that

records all transactions and the database
modifications made by each transaction.
This record of transactions and their modifications
supports three operations:

Recovery of individual transactions.

Recovery of all incomplete transactions when SQL
Server is started.
Rolling a restored database forward to the point of
failure.

Recovery of individual transactions.

If an application issues a ROLLBACK

statement or if SQL Server detects an error
(such as the loss of communication with a
client), the log records are used to roll back
any modifications made during an incomplete
transaction.

Recovery of all incomplete transactions when

SQL Server is started.

If a server running SQL Server fails, the databases

might be left in a state where some modifications
were never written from the buffer cache to the data
files, and there might be some modifications from
incomplete transactions in the data files.
When a copy of SQL Server is started, it runs a
recovery of each database. Every modification
recorded in the log that was not written to the data
files is rolled forward. Every incomplete transaction
found in the transaction log is then rolled back to
ensure that the integrity of the database is preserved.

Rolling a restored database forward

to the point of failure.

After the loss of a database, as is possible if a

hard drive fails on a server that does not have a
Redundant Array of Independent Disks
(RAID), you can restore the database to the
point of failure.

Write-Ahead Transaction Log

SQL Server 2000, like many relational databases, uses a

write-ahead log.
A write-ahead log ensures that no data modifications are
written to disk before the associated log record.
SQL Server maintains a buffer cache into which it reads
data pages when data must be retrieved.
Data modifications are not made directly to disk but are
instead made to the copy of the page in the buffer cache.
The modification is not written to disk until either the
database is checkpointed or until the modifications are
written to disk so that the buffer can be used to hold a
new page.

Write-ahead Transaction Log

(Cont)

Writing a modified data page from the buffer cache to

disk is called flushing the page.
A page modified in the cache but not yet written to
disk is called a dirty page.
At the time a modification is made to a page in the
buffer, a log record is built into the log cache and
records the modification.
This log record must be written to disk before the
associated dirty page is flushed from the buffer cache
to disk.

Write-ahead Transaction Log

(Cont)

If the dirty page were flushed before the log record, it

would create a modification on disk that could not be
rolled back if the server failed before the log record
was written to disk.
SQL Server has logic that prevents a dirty page from
being flushed before the associated log record.
Because log records are always written ahead of the
associated data pages, the log is called a write-ahead
log.

Transaction Log Logical

Architecture

Log records for data modifications record

either the logical operation performed or
record before-and-after images of the modified
data.
A before image is a copy of the data before the
operation is performed.
An after image is a copy of the data after the
operation has been performed.

Transaction Log Logical

Architecture

Many types of operations are recorded in the

transaction log:

The start and end of each transaction

Every data modification (insert, update, or delete)
Every extent allocation or deallocation
The creation or dropping of a table or index

Checkpoints and the Active Portion

of the Log

Checkpoints minimize the portion of the log that must

be processed during the full recovery of a database.
During a full recovery, you must perform two types
of actions:

The log might contain records of modifications that were

not flushed to disk before the system stopped. These
modifications must be rolled forward.
All of the modifications associated with incomplete
transactions (transactions for which there is no COMMIT
or ROLLBACK log record) must be rolled back.

Checkpoints

Checkpoints occur for the following events:

When a CHECKPOINT statement is executed

When an ALTER DATABASE statement is used to change
a database option
When an instance of SQL Server is stopped by executing a
SHUTDOWN statement or by using the SQL Server
Service Control Manager to stop the service from running
an instance of the database engine
When an instance of SQL Server periodically generates
automatic checkpoints in each database in order to reduce
the amount of time that the instance would take to recover
the database

Truncating the Transaction Log

If log records were never deleted from the transaction

log, the logical log would grow until it filled all of the
available space on the disks that hold the physical log
files.
At some point in time, old log records no longer
necessary for recovering or restoring a database must
be deleted to make way for new log records.
The process of deleting these log records to reduce
the size of the logical log is called truncating the log.

Truncating the Transaction Log

(Cont)

Log truncation occurs at the completion of any

BACKUP LOG statement and occurs every
time a checkpoint is processed, provided the
database is using the simple recovery model.

Transaction Log Physical

Architecture

The transaction log in a database maps over

one or more physical files.
Conceptually, the log file is a serial string of
log records.
Physically, the sequence of log records must
be stored efficiently in the set of physical files
that implement the transaction log.

Shrinking the Transaction Log

The physical size of the log file is reduced

when a DBCC SHRINKDATABASE
statement is executed, when a DBCC
SHRINKFILE statement referencing a log file
is executed, or when an autoshrink operation
occurs.

Concurrency Architecture

When many people attempt to modify data in a

database at the same time, a system of controls must
be implemented so that modifications made by one
person do not adversely affect those of another
person.
This process is referred to as concurrency control.
Two classifications exist for instituting concurrency
control:

Pessimistic concurrency control.

Optimistic concurrency control.

Pessimistic concurrency control.

A system of locks prevents users from modifying data

in a way that affects other users.
After a user performs an action that causes a lock to
be applied, other users cannot perform actions that
would conflict with the lock until the owner releases
it.
This process is called pessimistic control because it is
mainly used in environments where there is high
contention for data.

Optimistic concurrency control.

In optimistic concurrency control, users do not lock

data when they read it.
When an update is performed, the system checks to
see whether another user changed the data after it was
read. If another user updated the data, an error occurs.
Typically, the user who receives the error rolls back
the transaction and starts again. This situation is
called optimistic because it is mainly used in
environments where there is low contention for data.