Professional Documents
Culture Documents
Agenda
Transactions
Data integrity & Security
Concurrency control
Copyright 2004,
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
In todays session, we would be talking about the basic concepts of transactions, online transaction
processing, database integrity, security features using DDL statements, the concept of serializability
of transactions and about concurrent transactions.+
Transaction
Logical unit of program execution that takes a database from one consistent
state to another consistent state
Copyright 2004,
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
In other words, a transaction is a sequence of database actions which must either all be done, or none of them
must be done.
if only some of the actions of a transaction are carried out the database will be left in an inconsistent state
Consider the example transaction of a transfer of funds between bank accounts
Suppose there are two bank accounts, A and B
The balance in A is Rs 1000 and that in Y is 5000
The transaction has to transfer rs100 from bank account A into bank account B.
The sequence of actions would be:
Read balance in A
Calculate A transfer amount
1000
900
900
Read balance of B
Calculate B + transfer amount
Store new value of B
5000
5100
5100
If only the steps till 3 are done, then database would be in an inconsistent state
ACID Properties
Atomicity
Consistency
Isolation
Durability
Copyright 2004,
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
`
Consistency-Application programmer
To ensure that the database remains consistent after execution of the transaction
Isolation-Concurrency control
To ensure concurrent execution of transactions results in a state equivalent to that
obtained by sequential execution
Durability-Recovery management
To ensure that after successful transaction completion, all updates persist irrespective of
system failures
active
al
fin as
e
th t h d
ter en te
Af tem xecu
sta en e
be
When normal
execution cant
proceed
partially
completed
failed
After rollback
and
restoration to
prev state
A
s u c fte r
c
com essf
p le u l
tion
aborted
committed
Copyright 2004,
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Transaction state
Active
Partially committed
Failed
Aborted
Committed
Copyright 2004,
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Copyright 2004,
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Data Integrity
Refers to :
Correctness and completeness of data
Validity of individual items
Preservation of interrelationships in the DB
Required data
Domain integrity
Entity integrity
Referential integrity
Copyright 2004,
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
To preserve correctness of data, any RDBMS imposes data integrity constraints. These constraints
restrict the data values that can be inserted / modified. The constraints commonly found in RDBMSs
are as found in the slide.
Required data
Requires a column to contain Non-NULL values
Indicated with the key word NOT NULL in create statement
An example:
CREATE TABLE EMPLOYEE (
EMP_NO
EMP_NAME
EMP_AGE
.
Copyright 2004,
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
An insert into the table without a value for the column with NOT NULL constraint fails
An update trying to set the value of the column to a NULL value fails
.
EMP_LOC
varchar(15)
Copyright 2004,
10
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Check constraint is like a search condition. This will produce a true/false value. The condition
specified in the check constraint is verified by the RDBMS for every insert and update operations. If
any violation is observed, the operation fails.
10
Entity Integrity
The database models the outside world
A tables primary key should have unique values so that it represents
some real world entity
The requirement that the primary key be unique is called Entity integrity
constraint
Copyright 2004,
11
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
When a primary key is defined on a table, DBMS automatically checks to see if any duplicates are
entered, whenever an insert or update is attempted on the table. If any duplicate is found , the
operation fails with an error message.
11
Referential integrity
Ensures that the integrity of the parent-child relationship between tables
created by primary and foreign keys is preserved
Issues:
Copyright 2004,
12
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
.
Foreign key (Cust) REFERENCES Customers
ON DELETE CASCADE,
Foreign key (Rep) REFERENCES SalesReps
ON DELETE SET NULL,
ON UPDATE CASCADE,
Foreign key (Mfr, Product)
REFERENCES Products
ON DELETE RESTRICT
12
Security
Protection of data against unauthorized disclosure, alteration or
destruction.
Access allowed to only authorized users
User identification - Authorized users connect to the database using
user id and password.
Views, Synonyms,Roles
Access Privileges
Copyright 2004,
13
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
13
GRANT .. TO
REVOKE .. FROM ...
Copyright 2004,
14
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
14
1. GRANT . database
GRANT {
[DBADM[, ]]
- Database administrator authority
[DBCTRL[,]]
- Database control authority
[DBMAINT[, ]]
- Database maintenance authority
[CREATETAB[,]] - Privilege to create table
[DROP[, ]]
- Privilege to DROP/ALTER
[STARTDB[, ]]
- Start database
[STOPDB[, ]] }
- Stop database
ON DATABASE database-name[,...]
TO [AuthID][,...]
[PUBLIC]
[WITH GRANT OPTION]
Copyright 2004,
15
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
15
Copyright 2004,
16
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
16
GRANT
{
[CREATEALIAS[, ]] - create alias
[CREATEDBA[, ]] - create DB to get DBADM authority
[CREATEDBC[, ]] - create DB to get DBCTRL authority
[CREATESG[, ]]
- to create new storage group
[SYSADM[, ]]
- to provide system ADM authority
[SYSCTRL[, ]]
- to provide system control authority
}
TO [AuthID][,...]
[PUBLIC]
[WITH GRANT OPTION]
Copyright 2004,
17
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Grants the system level privileges using which the list of actions that can be performed by a particular
user is defined
17
GRANT . TO .
E.g:
User1 is an owner of Customer table.
User1 wants User2 perform queries on it.
User1 issues following command:
GRANT SELECT
ON Customer to User2;
Copyright 2004,
18
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
18
Restricting Privileges
Copyright 2004,
19
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
By explicitly saying what kind of queries can be performed on a table/view, we can restrict the kind of
changes that may be done to a table/view by a particular user.
We can even specify what columns of a table can be updated as shown in the slide
19
Copyright 2004,
20
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
20
Copyright 2004,
21
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
21
Copyright 2004,
22
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
22
Examples of REVOKE
REVOKE INSERT
ON Customer
FROM User2;
REVOKE SELECT, INSERT
ON Customer
FROM User2, User3;
Copyright 2004,
23
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
23
Concurrency
24
Concurrency
Two or more users access a database concurrently
DBMS ensures serializability
Problems associated with concurrent execution:
Lost update
Dirty read
Non repeatable read
Phantom records
Concurrency techniques:
Locking
Time stamping
Copyright 2004,
25
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Serializability:
If two transactions T1 and T2 are executing concurrently, the DBMS would ensure that the final result will be the same as when these
transactions are executed serially (one after the other). This is called serializability of transactions.
The problems that may occur if this serializability is not ensured by the dbms are as given in the slide
Lost update:
This happens when one transaction updates a table and before it commits, another transaction reads the value (old value) and makes some
updates based on that. Consider the example below:
Let A=20
Read (A, a1)
t1
a1 = a1 + 5
t2
t3
Read (A, b1)
Write(A,a1)
t4
Commit
t5
t6
b1
= b1 * 2
t7
Write(A,b1)
t8
Commit
Here the update done by the first transaction is not taken into account at all.
Dirty read
A transaction A may read some data updated by another transaction B. B might not have yet committed. If B fails and gets aborted, the data as
read by A would not exist (database would undo all changes done by B) and hence would be incorrect.
Nonrepeatable read
This happens when a transaction A reads a value from a table, another transaction B modifies that value and A gaian reads that value. Now A
will find a different value than what it was before.
Phantom records
Lets say a transaction A reads a set of rows from a table that satisfy a where condition. Now another transaction B inserts few more rows into
the table which would also satisfy the where condition. Now if A executes the query again, it will read more records than what it fetched before
These problems are illustrated in the following few slides with examples
25
Time
Read(A,a1)
a1=a1-50
Write(A,a1)
Read(B,b1)
b1=b1+50
Write(B,b1)
B = 100
A = 135
B = 165
t1
t2
t3
t4
Trans T2
t5
Read(A,a2)
temp=a2*0.1
a2=a2-temp
Write(A,a2)
read(B,b2)
b2=b2+temp
Write(B,b2)
t6
t7
t8
Copyright 2004,
26
Infosys Technologies Ltd
A = 150
A = 135
B = 150
B = 165
ER/CORP/CRS/DB07/003
Version No: 2.0
Slide shows the serial execution of transactions T1 and T2. only after T1 finishes completely,
T2 begins.
26
A = 200
B = 100
Serialized execution
Trans T1
A = 200
A = 150
B = 100
B = 150
Read(A,a1)
a1=a1-50
Write(A,a1)
Read(B,b1)
b1=b1+50
Write(B,b1)
Commit
t1
t2
t3
t4
t5
t6
t7
t8
Copyright 2004,
27
Infosys Technologies Ltd
A = 135
B = 165
Trans T2
Read(A,a2)
temp=a2*0.1
a2=a2-temp
Write(A,a2)
Read(B,b2)
b2=b2+temp
Write(B,b2)
commit
A = 150
A = 135
B = 150
B = 165
ER/CORP/CRS/DB07/003
Version No: 2.0
Serialized execution means, interleaving the execution of the two transactions T1 and T2 in
such a way that, the effect on the database is the same as executing these two transactions
serially.
27
Lost update
A=200
A=100
Trans T1
A=100
A=100
A=150
write(A,a1)
Commit
Time
t1
t2
t3
t4
t5
t6
t7
t8
Copyright 2004,
28
Infosys Technologies Ltd
Trans T2
ER/CORP/CRS/DB07/003
Version No: 2.0
This example shows how two or more concurrent transactions which update a common
record can introduce inconsistency in the database
The Updation done by transaction T1 is totally lost even before it is seen
28
Dirty Read
Trans T1 Time
A=100
A=150
A=100
Read(A,a1)
a1 = a1+50
Write(A,a1)
Rollback
t1
t2
t3
t4
t5
t6
t7
t8
Copyright 2004,
29
Infosys Technologies Ltd
A=300
A=100
Trans T2
Read(A,b1) A=150
b1 = b1 * 2
Write(A,b1) A=300
Commit
ER/CORP/CRS/DB07/003
Version No: 2.0
This eg shows how two or more concurrent transactions that see uncommitted data of any
other transactions can introduce inconsistency in the db
Transaction T1 Updates record A at time t3 and then it decides to rollback or undo
But, Transaction T2 reads the updated data which is not the correct data, and does some
Updation on the wrong data and commits.
29
Incorrect summary
Trans T1
Time
Trans T2
A = 100
B = 200
Sum=350
A=100
A=50
B=200
B=250
Read (A,a1)
a1 = a1-50
t1
t2
t3
t4
t5
t6
t7
t8
t9
t10
t11
t12
Write(A,a1)
Read(B,a2)
a2 = a2 +50
Write(B,a2)
Commit
Sum = 0
Read(A,b1)
A=100
Sum = Sum + b1
Sum=100
Read(B,b2)
Sum = Sum + b2
Commit
B=250
Copyright 2004,
30
Infosys Technologies Ltd
Sum=350
ER/CORP/CRS/DB07/003
Version No: 2.0
This e.g. shows that in certain cases, interleaving of transactions some of which only retrieve
data and others update the data is being retrieved by the other transactions, may result in
inconsistent data being generated.
Transaction T1 Updates record A and record B
Transaction T2 which has to calculate the sum of updated record, has read record A before
Updation and Record B after Updation, resulting in Incorrect Summary
or
The transaction T2 has seen the database in an inconsistent state and has therefore
performed an INCONSISTENT ANALYSIS
30
Phantom Record
TRANS-T1
Time
TRANS-T2
T1
Sum = 0
Insert X
T2
Insert Y
T3
T4
T5
Sum=sum + Bal_X
T6
T7
Sum=sum + Bal_Y
Insert Z
T8
T9
COMMIT
T10
Copyright 2004,
31
Infosys Technologies Ltd
COMMIT
ER/CORP/CRS/DB07/003
Version No: 2.0
31
Locking
A lock is a variable
associated with each
data item in a
database.
When updated by a
transaction, DBMS
locks the data item
serializability could be
maintained by this.
Lock could be Shared
or Exclusive
An example ->
Copyright 2004,
32
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Granularity of locks
A database consists of several items that form a hierarchy. For example, the general hierarchy is:
1. A field
2. A data row or a tuple
3. A table
4. A tablespace
4. A database
The position of a database item in the hierarchy is an indication of its granularity. Thus, a field has a finer
granularity while a database has the coarsest granularity of all. Field level locking is not practically
being used because of the high overhead involved.
Shared lock is used by the DBMS when a transaction wants to read some data from the database. Another
transaction can also acquire lock on the same data item and concurrently perform a read operation.
Exclusive lock is used when a transaction wants to update data. Once exclusive lock is acquired on a data
item, another transaction cant lock the same data item (for read or write) until the first transaction releases
the lock.
To summarize the compatibility:
S
32
Locking (Example)
T1
B=200
A=100
A=300
lock-S(B)
Read(B,b1)
unlock(B)
Lock-X(A)
Read(A,a1)
Temp=a1+b1
Write(A,Temp)
unlock(A)
Copyright 2004,
33
Infosys Technologies Ltd
T2
A = 100
B = 200
lock-S(A)
Read(A,a2)
unlock(A)
lock-X(B)
Read(B,b2)
Temp=a2+b2
Write (B,Temp)
Unlock(B)
A = 300
B = 300
A=100
B=200
B=300
ER/CORP/CRS/DB07/003
Version No: 2.0
33
Intent Locking
Also called Preemptive lock
Used to tag (lock) all ancestors of a node to be locked in share or exclusive
mode.
This tag signals to other requesting transactions that locking may take place at
a finer level by the transaction that holds the intent lock
This prevents other transactions from obtaining shared or exclusive lock to the
ancestors.
A variant of this is the SIX (Share-intention exclusive ) lock
Copyright 2004,
34
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Intent locking:
The lockable units in a generalized DBMS are:Database, Tablespace, Tables, Rows and Fields.
Each node of this list can be locked. When a lock request is granted to a node at a particular level, the
requester node as well as all its descendants would be implicitly granted the same level of lock. For example, if
a transaction locks a table in exclusive mode, it means it has been implicitly given exclusive access to every row
of this table.
Thus, generalization can be made that the same lock is granted to the entire sub-tree starting at the requested
node.
Now, let us say transaction A wants to update some rows of a table, and doesnt know how many apriori.
If A locks only the row which it currently updates, then in the meantime, some other transaction B may acquire
an exclusive lock on the entire table. After this, when A wants to update few more rows, it may not be possible
because the exclusive lock that has been acquired on the entire table by B will lock all rows of the table also in
exclusive mode. A may have to wait till B releases the lock.
To avoid this, A can put an intention lock on the table (which means A has the intention to lock some nodes
under the subtree ie some rows of the table in future) . This will prevent B from acquiring an exclusive lock on
the table.
After this, A can acquire individual locks on each row it may want to read or update and complete the task.
The intention lock is of two types: intention share (IS) and intention exclusive (IX).
When a transaction A puts an IS lock on a table, it means A has the intention to lock some node under this
subtree, ie some row under the table in shared mode. This does not stop another transaction B from acquiring a
similar lock on the table. After this lock is aqcuired, if A wants to read any row of the table, it has to explicitly
acquire a shared lock on the row.
A similar principle applies for the IX mode also.
The difficulty with this scheme is that, after acquiring an intention lock on a top level node (say a table), for even
reading any row of the table, the transaction has to acquire, individual shared lock on each such row.
Please refer to notes page of the next slide for explanation on the SIX lock
34
Copyright 2004,
35
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
S Gives share access to the requested node and to all descendants of the requested node. Any other
transaction can get a S lock or IS lock
only.
X
Gives exclusive access to the requested node and to all its descendants. No other
locks are permitted in this mode.
IS
Gives intention share access to the requested node and allows the requester to
explicitly lock the descendants of this node in S , IS, IX
or SIX mode. Such explicit locking at granular level is possible only if compatibility at that finer
level is supported.
IX
Gives intention exclusive access to the requested node and allows the requester
to explicitly lock the descendants in IS or IX modes. This is again subject to compatibility with the
other mode at the descendant's level.
SIX
The subtree rooted by the node under consideration is locked explicitly in a shared
mode and a few nodes at lower levels are being locked in the exclusive mode. Only another IS lock is
allowed in this mode.
To understand the SIX mode, consider, there is an employee table which transaction T1 would be
updating. As of now, it is not known as to which all rows may be required. If T1 locks the table in the
IX mode, then some other transaction may acquire an IX lock on the same node and lock any
descendant in the x mode. If T1 now comes to know that it has to update the same node that some
other transaction has locked, it may have to wait. So, when T1 knows that it would be reading all the
records of the table and updating some records, it can obtain a shared and intention-exclusive (SIX)
lock on the table (root) so that, no other transaction can lock any child node of this table (row) in an
exclusive (X) mode
35
Two-Phase locking
Serializability of concurrently executing transactions can be guaranteed by two
phase locking
Copyright 2004,
36
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
The Lost update problem and the Dirty Read problem show that serializability requires that a
transaction updating a record should not only lock the record but also hold the lock until
COMMIT/ROLLBACK time. The Incorrect summary problem and the Phantom Record
problem require that the table itself be locked even for read transaction until the transaction
comes to an end. Thus, we can see that locks keep growing during a certain phase of the
transaction and the locks start shrinking during the COMMIT/ROLLBACK time.
Thus, there is a lock-growing phase and lock-shrinking phase. Such a scheme is called Two-phase
locking (2PL).
The 2PL theory can be summarized as:
A transaction should not operate on any object unless the transaction has acquired an appropriate
lock on the object.
The transaction should not acquire any fresh locks after releasing a lock.
We can say: If a transaction follows the 2PL protocol, then it is serializable.
It is very important to notice that all 2PL transactions are serializable. But, not all serializable
transactions follow 2PL protocol.Thus, 2PL protocol is a sufficient but not necessary condition for
serialization. 2PL is a way of ensuring serializability in a simple way.
36
Locking (Example)
T1
B=200
Lock-S(B)
Read(B,b1)
Lock-X(A)
unlock(B)
T2
A = 100
B = 200
Lock-X(B)
Read(B,b2)
A=100
A=300
A = 300
B = 500
B=200
Read(A,a1)
Temp=a1+b1
Write(A,Temp)
unlock(A)
Lock-S(A)
Read(A,a2)
unlock(A)
Temp=a2+b2
Write (B,Temp)
Unlock(B)
Copyright 2004,
37
Infosys Technologies Ltd
A=300
B=500
ER/CORP/CRS/DB07/003
Version No: 2.0
37
Deadlock
Occurs when two or more separate processes compete for resources held by
one another.
T1
T2
Write_lock A
action(s)
Read_lock B
action(s)
Write_lock B
WAIT
Read_lock A
WAIT
Copyright 2004,
38
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
Deadlock occurs when one transaction is waiting on another to release a lock it needs, and vice
versa - each then will wait forever for the other
If a deadlock occurs one of the offending transactions must be rolled back to allow the other to
proceed
There are various methods for choosing which transaction to roll back when a deadlock is detected
Time (how long the transactions have been running)
Data updated
Data remaining to update
There are schemes for preventing deadlock. But, most DBMSs allow them to occur and resolve
when they are detected
Detection may be based on:
Timeout
Wait-for-graph (shows which transactions are waiting on which other transactions
for a lock)
38
Deadlock
T1
Lock-X(A)
update A
lock-X(B)
update B
T2
t1
t2
t3
t4
t5
t4
t5
Copyright 2004,
39
Infosys Technologies Ltd
lock-X(B)
update B
lock-X(A)
update A
ER/CORP/CRS/DB07/003
Version No: 2.0
39
Summary
Transaction is a logical unit of work which takes the database from one
consistent state to the other
Atomicity, consistency, isolation and durability are the ACID properties of a
transaction
Data integrity and Security are enforced using SQL DDL statements
Transactions should be able to concurrently execute without affecting the
consistency of the database
Locking is a mechanism of achieving such controlled concurrency
Copyright 2004,
40
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
40
Thank You!
Copyright 2004,
41
Infosys Technologies Ltd
ER/CORP/CRS/DB07/003
Version No: 2.0
41