Transactions and Locks A Quick Reference and Summary BIT 275

Transaction A transaction is a series of steps that perform a logical unit of work. Transactions must adhere to ACID properties, that is: –Atomicity: Either all of the steps must succeed or none of them may succeed. –Consistency: The data must be left in a predictable and usable state. –Isolation: Changes made must not be influenced by other concurrent transactions. –Durability: The changes made must be permanent in the database and survive even system failures.

Transactions SQL Server records all changes made in the transaction log to allow any changes to be undone (rolled back) or redone (rolled forward) in case of a system failure. When updating or inserting a record into a database, the record is first allocated in buffer memory, and the buffer manager guarantees that the transaction log is written before the changes to the database file are written. It does this by keeping track of a log position using a log sequence number (LSN).

Checkpoints At certain intervals, SQL Server issues a checkpoint in the transaction log that issues a write from the transaction log to the data file. Depending on the setting of the transaction log defined in the database recovery model, the transaction log will keep the committed and written records in the transaction log or truncate the log.

Autorecovery This process of working with the transaction log and recording actions in the transaction log before applying them to the actual data files allows SQL Server to recover from failures in case of an unexpected shutdown.

Autorecovery The autorecovery process will check the database to see what the last-issued checkpoint and written LSN were and will then write all committed records from the transaction log that were not recorded yet in the data file to the data file. This process is a rollforward. Different from other database systems such as Oracle, SQL Server automatically issues a transaction (autocommitted) on every statement, so you don’t need to explicitly commit these transactions.

Transaction Logs SQL Server uses a buffer cache, which is an in-memory structure, into which it retrieves data pages from disk for use by applications and users. Each modification to a data page is made to the copy of the page in the buffer cache. A modified buffer page in the cache that has not yet been written to disk is called a dirty page.

Transaction Logs The modification is recorded in the transaction log before it is written to disk. For this reason, the SQL Server transaction log is called a write-ahead transaction log. SQL Server has internal logic to ensure that a modification is recorded in the transaction log before the associated dirty page is written to disk. When SQL Server writes the dirty page in the cache to the disk, it is called flushing the page.

Checkpoint The checkpoint process is designed to minimize the recovery time if the server fails by minimizing the number of pages in the buffer cache that have not been written to disk. Checkpoints occur whenever: –A CHECKPOINT statement is issued. –The ALTER DATABASE statement is used. –An instance of SQL Server is stopped normally. –An automatic checkpoint is issued.

Checkpoint Automatic checkpoints are generated periodically based on the number of records in the active portion of the transaction log, not on the amount of time that has elapsed since the last checkpoint.

Log File Organization with Available Space at the End

Log File with No Available Space at the End

Executing Implicit and Explicit Transactions By default, SQL Server automatically commits a transaction to the database, and every transaction is handled as a single process. Because this process occurs without any explicit request from you to confirm the action, this is called an autocommit.

Executing Implicit and Explicit Transactions explicit transaction: A group of SQL statements enclosed within transaction delimiters that define both the start and end of the transaction. implicit transaction: A connection option in which each SQL Statement executed by the connection is considered a separate transaction.

Transaction Rollback When you want to confirm a transaction, you issue a COMMIT TRANSACTION statement. This will close the open statements and confirm the grouped DML statements. If you don’t want a transaction to occur, that is, you want to cause a transaction rollback, you issue a ROLLBACK TRANSACTION statement.

Distributed Transaction When executing a distributed transaction, SQL Server doesn’t really differ a lot from executing an explicit transaction. The transaction, however, will be considered to execute over a remote connection and will be managed and coordinated by the Microsoft Distributed Transaction Coordinator (DTC). In a distributed environment, you work over the network segment, so the execution of the transaction will take place using a two-phase commit.

Locks Locks prevent users from reading or modifying data that other users are in the process of changing. Two main types of lock come into play: –Read locks: Read locks ensure other users don’t change the data you are retrieving but allow other users to read the data at the same time. –Write locks: Write locks ensure no other users can examine or change the data you are updating.

Deadlock A deadlock is a situation when two (or more) users, each having a lock on one piece of data, attempt to acquire a lock on the other’s piece. Unless one of the user processes is terminated, each user would wait indefinitely for the other to release the lock. SQL Server detects deadlocks and terminates one user’s process.

Locks and Serialization Locks permit the serialization of transactions, meaning only one person can change a data element at a time. During a transaction, SQL Server controls and sets the appropriate level of locking. You can control how some locks are used by including locking hints in your query.

Concurrency Specific types of locks allow users to access and update data at the same time. A SELECT may be allowed at the same time as an UPDATE, but the UPDATE blocks a second UPDATE. This concept, known as concurrency, can increase response time from the user’s perspective. Concurrency control means changes made by one person do not adversely affect modifications other users make.

Concurrency There are two types of concurrency control: –Pessimistic: Pessimistic concurrency control locks data when data are read in preparation for an update. –Optimistic: Optimistic concurrency control does not lock data when data are initially read.

Locks and Transaction Integrity When users access data concurrently, a risk exists that one user’s actions might affect the records another user is accessing. Locks can prevent the following situations that compromise transaction integrity: –Lost updates –Uncommitted dependencies (dirty read) –Inconsistent analysis (nonrepeatable read) –Phantom reads

Locks and Concurrent Transactions SQL Server uses different locking modes to control how resources can be accessed by concurrent transactions. These types of locks are: –Shared –Exclusive –Intent –Update –Schema –Bulk update

Data Manipulation Language Queries The data Manipulation Language keywords SELECT, INSERT, UPDATE, DELETE and MERGE examine and change data in your tables. To retrieve data from one or more tables, use these keywords in this order: –SELECT –FROM –WHERE –GROUP BY –HAVING –ORDER BY

Presenting Data in a Different Order The ORDER BY clause provides the primary means of organizing data, and it has two major keywords: –ASCending –DESCending

Error Handling SQL Server has greatly improved error- handling capabilities when compared to other database platforms. –RAISERROR

Error Messages ERROR_LINE ERROR_MESSAGE ERROR_NUMBER ERROR_PROCEDURE ERROR_SEVERITY ERROR_STATE

TRY…CATCH Blocks TRY…CATCH blocks are a great way to implement error handling in SQL Server. These blocks work the same as (or very similar to) any programming language that uses a TRY…CATCH construct and they will catch every error that has a severity level greater than 10 but not cause any termination in the database connection. TRY…CATCH blocks can also be used in stored procedures and triggers.

Using INSERT and DELETE Operations During an INSERT operation the inserted table is dynamically created and during a DELETE operation the deleted table is likewise created in memory for the life of the transaction. Now, instead of a trigger, you may use the OUTPUT clause to manipulate these data.

Summary Working with transactions allows you to roll back or cancel a transaction to execute in case of a certain event or condition, or even roll back multiple grouped statements in a distributed environment

Summary SQL Server supports various recovery models. The most common—but also the one with the biggest transaction log size—is the Full recovery model. However, if you perform large amounts of batch and bulk inserts, it might be useful not to set the recovery model to Full and instead use the Bulk-Logged recovery model.

Summary The error-handling in SQL Server is one of the best error-handling capabilities so far in the SQL language because it implements a TRY…CATCH block, just as do programming languages such as Visual Basic and C#.