managing sql server transactions and locks

8/10/2019 Managing SQL Server Transactions and Locks

http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 1/20

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 thattransaction.

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 modificationssupports 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 databasesmight be left in a state where some modificationswere never written from the buffer cache to the datafiles, and there might be some modifications fromincomplete transactions in the data files.

When a copy of SQL Server is started, it runs arecovery of each database. Every modificationrecorded in the log that was not written to the datafiles is rolled forward. Every incomplete transactionfound in the transaction log is then rolled back toensure 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 awrite-ahead log.

A write-ahead log ensures that no data modifications arewritten to disk before the associated log record.

SQL Server maintains a buffer cache into which it readsdata pages when data must be retrieved.

Data modifications are not made directly to disk but areinstead made to the copy of the page in the buffer cache.

The modification is not written to disk until either thedatabase is checkpointed or until the modifications arewritten to disk so that the buffer can be used to hold anew page.



Write-ahead Transaction Log

(Cont…)

Writing a modified data page from the buffer cache todisk 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 andrecords the modification.

This log record must be written to disk before theassociated dirty page is flushed from the buffer cacheto 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 incompletetransactions (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 changea database option

When an instance of SQL Server is stopped by executing aSHUTDOWN statement or by using the SQL ServerService Control Manager to stop the service from runningan instance of the database engine

When an instance of SQL Server periodically generatesautomatic checkpoints in each database in order to reducethe amount of time that the instance would take to recoverthe 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 adatabase 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 thatwould 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 wasread. 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 inenvironments where there is low contention for data.

managing sql server transactions and locks

Documents