02/12/2019

Contents
 Introduction
Transaction  Properties of a transaction
 Transaction states
NGUYEN HongPhuong  Processing a transaction
Email: [email protected]
 Transactions, read and write
Site: http://users.hust.edu.vn/phuongnh
Face: https://www.facebook.com/phuongnhbk operation, DBMS buffer
Hanoi University of Science and Technology  Some examples
 Transaction best practices

1 2

Introduction Properties of a transaction

 Transactions in SQL are a group of  The transaction has 4 standard properties,
SQL statements. If a transaction is referenced by ACID
made successfully, all data changes
made in the transaction are saved to
the database. If a transaction fails and
is rolled back, all data modifications will
be deleted (data is restored to the state
before the transaction was executed).

3 4

1
 02/12/2019

Properties of a transaction (2) Transaction states

 Atomicity: ensures that all operations within the
work unit are completed successfully. Otherwise,  A transaction is an atomic unit of work
the transaction is aborted at the point of failure that is either completed in its entirety
and all the previous operations are rolled back to or not done at all.
their former state.
 For recovery purposes, the system
 Consistency: ensures that the database properly
changes states upon a successfully committed needs to keep track of when the
transaction. transaction starts, terminates, and
 Isolation: enables transactions to operate commits or aborts.
independently of and transparent to each other.
 Durability: ensures that the result or effect of a
committed transaction persists in case of a
system failure.
5 6

Transaction states (2) Transaction states (3)

A state transition diagram  The states of the transaction can be

summarized as follows:
 The running transaction is referred to as
the Active transaction
 The transaction that completes its
execution successfully without any error is
referred to as a Committed transaction
 The transaction that does not complete it is
execution successfully is referred to as an
Aborted transaction

7 8

2
 02/12/2019

Transaction states (4) Processing a transaction

 The transaction that is not fully committed  The following commands are used to
yet is referred to as a Partially process transactions.
Committed transaction  COMMIT: to save the changes.
 If the transaction does not complete its  ROLLBACK: to return to the previous state
execution, it is referred to as a Failed before changing.
transaction, that is Aborted without being  SAVEPOINT: create points within the
committed transaction group to ROLLBACK, i.e. to return
 If the Partially Committed transaction to that status point.
completes its execution successfully, it will  SET TRANSACTION: give a name to a
be Committed, otherwise it will be Failed transaction.
then Aborted  These commands are only used with DML:
9
INSERT, UPDATE and DELETE. 10

COMMIT command ROLLBACK command

 Used to save the changes invoked by a  Used to return transactions to a state
transaction to the database. before changes have not been saved to
 Stores all transactions in the Database the database.
since the last COMMIT or ROLLBACK  Can only be used to undo transactions
command. from the last COMMIT or ROLLBACK
 The basic syntax of a COMMIT command.
command is as follows:  The basic syntax:
COMMIT; ROLLBACK;
ROLLBACK TO SavePointName;
11 12

3
 02/12/2019

SAVEPOINT RELEASE SAVEPOINT command

 A SAVEPOINT is a point in a transaction  Used to delete a SAVEPOINT that you
when you can undo the transaction to a have created.
specific point without having to roll it  The basic syntax
back to the first state before that
RELEASE SAVEPOINT SAVEPOINT_NAME;
change.
 The basic syntax of the SAVEPOINT is
as follows:  Once a SAVEPOINT has been deleted,
you can no longer use the ROLLBACK
SAVEPOINT SAVEPOINT_NAME; command to undo the transaction to
that SAVEPOINT.
13 14

Transactions, read and write operation,

SET TRANSACTION command DBMS buffer

 Can be used to initiate a Database  The database operations that form a

Transaction. This command is used to transaction can either be embedded within
characterize the transaction. an application program or they can be
specified interactively via a high-level
 For example, you can specify a
query language such as SQL.
transaction as read only or read write.
 One way of specifying the transaction
 The basic syntax boundaries is by specifying explicit begin
SET TRANSACTION [READ WRITE | READ ONLY];
transaction and end transaction
statements in an application program

15 16

4
 02/12/2019

 A read-only transaction  The basic unit of data transfer from disk to

 do not update the database but only retrieve main memory is one block
data  Executing a read_item(X) command
 To simplify, the basic database access includes the following steps:
operations that a transaction can include  Find the address of the disk block that
are as follows: contains item X
 read_item(X): Reads a database item named  Copy that disk block into a buffer in main
X into a program variable also named X. memory (if that disk block is not already in
 write_item(X): Writes the value of program some main memory buffer)
variable X into the database item named X  Copy item X from the buffer to the program
variable named X
17 18

 Executing a write_item(X) command includes the  A transaction includes read_item and

following steps:
write_item operations to access and
 Find the address of the disk block that contains item X.
 Copy that disk block into a buffer in main memory (if update the database.
that disk block is not already in some main memory
buffer).
 The read-set of a transaction is the set
 Copy item X from the program variable named X into its of all items that the transaction reads
correct location in the buffer.
 The write-set is the set of all items that
 Store the updated block from the buffer back to disk
(either immediately or at some later point in time). the transaction writes.

19 20

5
 02/12/2019

Why Concurrency Control Is Needed

 Problem
 The Lost Update
T1 T2  The Temporary Update (Dirty Read)
read_item (X); read_item (X);
X:=X-N; X:=X+M;
 The Incorrect Summary
write_item (X); write_item (X);  The Unrepeatable Read
read_item (Y);
Y:=Y+N;
write_item (Y);

21 22

The Lost Update Problem The Temporary Update Problem

 Occurs when two transactions that access the  Occurs when one transaction updates a
same database items have their operations database item and then the transaction fails for
interleaved in a way that makes the value of some reason.
some database items incorrect.  The updated item is accessed by another
T1 T2 transaction before it is changed back to its
read_item (X); original value.
X:=X-N;
read_item (X); T1 T2 Transaction T1 fails
X:=X+M; read_item (X); and must change
Time write_item (X); X:=X-N; the value of X back
read_item (Y); write_item (X); to its old value;
write_item (X); meanwhile T2 has
Y:=Y+N; Time read_item (X); read the
write_item (Y); X:=X+M; “temporary”
write_item (X); incorrect value of X.
23 read_item (Y); 24

6
 02/12/2019

The Incorrect Summary Problem The Unrepeatable Read Problem

T1 T3
 If one transaction is  A transaction T reads an item twice and
sum:=0;
calculating an
aggregate summary
read_item(A);
sum:=sum+A;
the item is changed by another
function on a number read_item(X); transaction T' between the two reads
of records while other X:=X-N;
transactions are write_item(X);  Hence, T receives different values for
read_item(X);
updating some of Time
sum:=sum+X; its two reads of the same item.
these records, the read_item(Y);
aggregate function sum:=sum+Y;
may calculate some read_item(Y);
Y:=Y+N;
values before they write_item(Y);
are updated and
others after they are T3 reads X after N is subtracted
and reads Y before N is added
updated
25 26

Why Recovery Is Needed Some examples

 The DBMS must not permit some operations of a  Using an explicit transaction
transaction T to be applied to the database while other CREATE TABLE ValueTable (id int);
operations of T are not. This may happen if a transaction INSERT INTO ValueTable VALUES(1);
fails after executing some of its operations but before INSERT INTO ValueTable VALUES(2);
executing all of them.
 There are several possible reasons for a transaction to fail BEGIN TRANSACTION;
in the middle of execution: DELETE FROM ValueTable
WHERE id = 2;
 A computer failure (system crash)
COMMIT;
 A transaction or system error
 Local errors or exception conditions detected by the
transaction
 Rolling back a transaction
 Concurrency control enforcement BEGIN TRANSACTION;
INSERT INTO ValueTable VALUES(3);
 Disk failure
INSERT INTO ValueTable VALUES(4);
 Physical problems and catastrophes ROLLBACK;

27 28

7
 02/12/2019

Some examples (2) Some examples (3)

 Naming a transaction  Marking a transaction
BEGIN TRANSACTION Del
DECLARE @TranName VARCHAR(20); WITH MARK N'Deleting a row';
DELETE FROM ValueTable WHERE id = 1;
SELECT @TranName = 'MyTransaction';
COMMIT TRANSACTION Del;
BEGIN TRANSACTION @TranName;
DELETE FROM ValueTable WHERE id = 1;
COMMIT TRANSACTION @TranName;

29 30

Transaction best practices Transaction best practices (2)

 Using the SQL Server transaction helps  Narrow the scope of the transaction
maintaining the database integrity and  Retrieve the data from the tables before
consistency. On the other hand, a badly opening the transaction if possible
written transaction may affect the overall  Access the least amount of data inside the
performance of your system by locking the transaction body
database resources for long time. To  Do not ask for user input inside the body of
the transaction
overcome this issue, it is better to
 Use a suitable mode of transactions
consider the following points when writing
 Use as suitable Isolation Level for the
a transaction:
transaction

31 32

8
 02/12/2019

33