Upload
vadgamabhavin
View
227
Download
0
Embed Size (px)
Citation preview
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
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 2/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 3/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 4/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 5/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 6/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 7/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 8/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 9/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 10/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 11/20
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
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 12/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 13/20
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
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 14/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 15/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 16/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 17/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 18/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 19/20
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.
8/10/2019 Managing SQL Server Transactions and Locks
http://slidepdf.com/reader/full/managing-sql-server-transactions-and-locks 20/20
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.