6_transaction processing concepts, oltp, database integrity, security, con currency

8/3/2019 6_Transaction Processing Concepts, OLTP, Database Integrity, Security, Con Currency

1/41

RDBMS - Day6

OLTP basics, Concurrency, Data integrity, Security


2/41

ER/CORP/CRS/DB07/003

Version No: 2.02Copyright 2004,

Infosys Technologies Ltd

Agenda

Transactions

Data integrity & Security

Concurrency control

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 serializabilityof transactions and about concurrent transactions.+


3/41




Transaction

Logical unit of program execution that takes a database from one consistent

state to another consistent state

In other words, a transaction is a sequence of database actions which must either all be done, or none of themmust 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 1000

Calculate A transfer amount 900

Store new value of A 900

Read balance of B 5000

Calculate B + transfer amount 5100

Store new value of B 5100

If only the steps till 3 are done, then database would be in an inconsistent state


4/41




ACID Properties

Atomicity

Consistency

Isolation Durability

Atomicity- Transaction management

DBMS keeps track of the old value of a data on which the transaction acts so that, if there isa failure, the old value of the data is restored as though no transaction acted on it

`

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 thatobtained by sequential execution

Durability-Recovery management

To ensure that after successful transaction completion, all updates persist irrespective ofsystem failures


5/41




active

partiallycompleted

failed

abortedcommitted

State diagram of a transaction

While executing

Afterthe

final

statem

enth

as

been

exe

cute

d

When normalexecution cant

proceed

After rollbackand

restoration toprev state

Aftersuccessfulcompletion

Transaction state

Active

Partially committed

Failed

Aborted

Committed


6/41




SQL and Transactions

BEGIN TRANSACTION

COMMIT TRANSACTION;

ROLLBACK TRANSACTION

A transaction is typically represented by a combination of the above three operations in SQL

The COMMIT statement defines the end of a transaction

The ROLLBACK statement undoes all of the actions of a transaction. Consider the following example

Begin transaction is not standard. A new transaction begins immediately after a commit statement

COMMIT;

Update AccountSet Balance = Balance - 100

Where AccountNo = 11111;

Update Account

Set Balance = Balance + 100


COMMIT;

COMMIT;

Update Account

Set Balance = Balance - 1000


Update Account

Set Balance = Balance + 100

Where AccountNo = 22222;ROLLBACK;


7/41




On-line Transaction Processing Systems

Handle

Several concurrent transactions from

Spatially Distributed M/cs

Execution of Instructions and Queries across LAN/WAN

Geographically distributed processors

Spatially Distributed Databases

Several concurrent transactions are initiated from spatially distributed terminals.

Each transaction has the need for executing several machine instructions, retrievals, updates, and

sending or receiving messages.

Processors distributed geographically execute the programs initiated by these transactions.

There may be one or more databases which may be spatially distributed and used by thetransaction.

Typical examples are: Railway reservation, Bank transactions etc.


8/41




Data Integrity

Refers to :

Correctness and completeness of data

Validity of individual items

Preservation of interrelationships in the DB

Data integrity constraints:

Required data

Domain integrity

Entity integrity

Referential integrity

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 RDBMSsare as found in the slide.

We will discuss in detail about these constraints in the following slides..


9/41




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 integer NOT NULL,

EMP_NAME varchar (15) ,

EMP_AGE integer,

.

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


10/41




Domain Integrity-Check constraint

Specify a range of values that a column can take.

Used to specify business rules. Specified in the create statement

An example:

CREATE TABLE EMPLOYEE (

EMP_NO integer NOT NULL,

.

EMP_LOC varchar(15)

CHECK ( EMP_LOC in ( BANGALORE,

BOMBAY,DELHI)));

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. Ifany violation is observed, the operation fails.


11/41




Entity Integrity

The database models the outside world

A tables primary key should have unique values so that it representssome real world entity

The requirement that the primary key be unique is called Entity integrityconstraint

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 , theoperation fails with an error message.


12/41




Referential integrity

Ensures that the integrity of the parent-child relationship between tables

created by primary and foreign keys is preserved

Issues:

Inserting a new child row

Updating foreign key in a child row

Updating the primary key in a parent row

Deleting a parent row

Let us take the first issue: inserting a new child row:

When we try to insert a row in the child table, its foreign key value must be the same as one of the primary key values in a parent table. Forexample, The deptno is a foreign key in the employee table which refers to the dept# in the department table. let us say, we try to insert arow in the employee table, with a department number which is not there in the department table, then it indicates the data is wrong. So ,such a insert should not be allowed. Databases take care of this situation automatically

A similar check is performed when we try to modify the foreign key field

The last two issues are similar:Updating /deleting the parent row. Let us say, we are dissolving a department altogether, what will happen to the eployees who belong to the

department?

Ve to do one of the following:

1. Prevent the dept being deleted until all its employees are reallotted to some other dept

2. Automatically delete the employees who belong to the dept

3. Set the dept column for the employees who belong to the dept to NULL

4. Set the dept column of these employees to some default value which indicates they are currently not allotted to any dept

To achieve this, 4 options can be set in CREATE table command:

ON DELETE RESTRICT

ON DELETE SET NULL

ON DELETE SET DEFAULT

ON DELETE SET CASCADE

For ex:

CREATE table ORDERS

( Order_Num Integer NOT NULL,

.

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


13/41




Security

Protection of data against unauthorized disclosure, alteration or

destruction.

Access allowed to only authorized users

User identification - Authorized users connect to the database usinguser id and password.

Views, Synonyms,Roles

Access Privileges


14/41




GRANT .. TO

REVOKE .. FROM ...

Data Definition Language statements for Datasecurity

GRANT & REVOKE

Privileges on a specified database

Privileges on specified tables or views

System privileges


15/41




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]

1. GRANT . database


16/41




GRANT {

[ALTER[, ]]

[DELETE[, ]][INDEX[, ]]

[INSERT[, ]]

[SELECT[, ]]

[UPDATE [(column-name[,...])][, ]]

[REFERENCES[, ]]

| ALL [PRIVILEGES] }

ON [TABLE] {table-name[,...] | view-name[,...]}

TO [AuthID][,...]

[PUBLIC [AT ALL LOCATIONS]]

[WITH GRANT OPTION]

2. GRANT . Tables or views

Privileges on a specific table or a view created based on a table.


17/41




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]

3. GRANT .. System privileges

Grants the system level privileges using which the list of actions that can be performed by a particular

user is defined


18/41




GRANT . TO .

Used to grant access to new users;

Permission can be granted for all DML commands;

Permission is granted on a database/table/view; Permission for further grant.

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;

To allow insert permission,

User1 issues the command-

GRANT INSERT ON Customer to User2;

GRANT SELECT, INSERT ON Customer to User2;

GRANT INSERT ON Customer to User2, User3;


19/41




Restricting Privileges

GRANT SELECT, UPDATE ON Customer to User2

GRANT UPDATE ( Comm) ON Customer to User2

GRANT UPDATE (CName,City) ON Customer to User2;

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


20/412




ALL & PUBLIC arguments

GRANT ALL PRIVILEGES ON Customer to User2

GRANT ALL ON Cusomer to PUBLIC;

GRANT SELECT ON Customer to PUBLIC;


21/412




Granting with GRANT option

GRANT SELECT ON Customer To User2 WITH GRANT OPTION

GRANT SELECT ON User1.Customer To User3;

GRANT SELECT ON User1.Customer To user3 WITH GRANTOPTION;


22/412




Taking PRIVILIGES away

The syntax of REVOKE command is patterned after GRANT,

but with a reverse meaning.

REVOKE{[ALTER[, ]]

[DELETE[, ]]

[INDEX[, ]]

[INSERT[, ]]

[SELECT[, ]]

[UPDATE [(column-name[,...])][, ]]

| ALL [PRIVILEGES] }

ON [TABLE] {table-name[,...] | view-name [,...]}

FROM AuthID[,...][PUBLIC [AT ALL LOCATIONS]]

[BY {AuthID[,...] | ALL}]


23/412




Examples of REVOKE

REVOKE INSERT

ON Customer

FROM User2;

REVOKE SELECT, INSERT

ON Customer

FROM User2, User3;


24/412

Concurrency


25/412




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

Serializability:

If two transactions T1 and T2 are executing concurrently, the DBMS would ensure that the final result will be the same as when thesetransactions 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 someupdates 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

t7Write(A,b1)

t8Commit

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 asread 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 Awill 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 intothe 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


26/412

Slide shows the serial execution of transactions T1 and T2. only after T1 finishes completely,

T2 begins.




Read(A,a1)

a1=a1-50Write(A,a1)Read(B,b1)b1=b1+50Write(B,b1)

Read(A,a2)

temp=a2*0.1a2=a2-temp

Write(A,a2)read(B,b2)b2=b2+tempWrite(B,b2)

Trans T1Trans T1

Trans T2Trans T2

A = 200A = 200

B = 100B = 100

A = 150A = 150

A = 200A = 200

B = 100B = 100

B = 150B = 150

A = 150A = 150

A = 135A = 135B = 150B = 150

B = 165B = 165

A = 135A = 135

B = 165B = 165

t1

t2t3

t4

t5

t6t7

t8

TimeTime

Serial execution of two transactions


27/412

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




Trans T1Trans T1

Trans T2Trans T2Read(A,a1)a1=a1-50

Write(A,a1)Read(A,a2)temp=a2*0.1a2=a2-tempWrite(A,a2)

Read(B,b1)

b1=b1+50Write(B,b1)Commit Read(B,b2)

b2=b2+temp

Write(B,b2)commit

A = 150A = 150

A = 200A = 200

B = 100B = 100

B = 150B = 150

A = 150A = 150

A = 135A = 135

B = 150B = 150

B = 165B = 165

A = 135A = 135

B = 165B = 165A = 200A = 200

B = 100B = 100

t1

t2t3

t4t5

t6

t7

t8

Serialized execution


28/412

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




Lost update A=100A=100

Read (A, a1) t1a1 = a1 + 50 t2

t3 Read (A, b1)write(A,a1) t4Commit t5

t6 b1 = b1 * 2t7 Write(A,b1)t8 Commit

A=100A=100A=100A=100

A=100A=100A=150A=150

A=200A=200A=200A=200

TimeTimeTrans T1Trans T1 Trans T2Trans T2

A=200A=200


29/412

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 someUpdation on the wrong data and commits.




Dirty Read

A=100A=100

Read(A,a1) t1

a1 = a1+50 t2Write(A,a1) t3

t4 Read(A,b1)t5 b1 = b1 * 2

Rollback t6t7 Write(A,b1)t8 Commit

A=100A=100

A=150A=150A=150A=150

A=100A=100A=300A=300

A=300A=300

TimeTimeTrans T1Trans T1 Trans T2Trans T2


30/413

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 ininconsistent 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 beforeUpdation and Record B after Updation, resulting in Incorrect Summary

or

The transaction T2 has seen the database in an inconsistent state and has thereforeperformed an INCONSISTENT ANALYSIS




Read (A,a1) t1

a1 = a1-50 t2 Sum = 0t3 Read(A,b1)

Write(A,a1) t4t5 Sum = Sum + b1

Read(B,a2) t6a2 = a2 +50 t7Write(B,a2) t8

Commit t9t10 Read(B,b2)t11 Sum = Sum + b2t12 Commit

A = 100A = 100

B = 200B = 200TimeTimeTrans T1Trans T1 Trans T2Trans T2

A=100A=100

A=50A=50

B=200B=200

A=100A=100

Sum=100Sum=100

B=250B=250

Sum=350Sum=350

B=250B=250

Sum=350Sum=350

Incorrect summary


31/413




TRANS-T1 Time TRANS-T2

Insert XT1 Sum = 0

Insert Y

T2

T3

Read (X, Bal_X)T4

Sum=sum + Bal_XT5

Read (Y, Bal_Y)T6

Sum=sum + Bal_Y

Insert Z

T7

COMMIT

COMMIT

T8

Phantom Record

T9

T10

Until TRANS-T1 COMMITS, the TRANS-T2 cannot see the existence of Z

Thus, Z is a PHANTOM RECORD as far as TRANS-B is concerned

Unless TRANS-T2, prevents TRANS-T1 from inserting Z, the two transactions are not serializable


32/413




Locking

A lock is a variableassociated with each

data item in a

database.

When updated by a

transaction, DBMSlocks the data item

serializability could bemaintained by this.

Lock could be Shared

or Exclusive

An example ->

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 databaseThe 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 practicallybeing 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. Anothertransaction 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 dataitem, another transaction cant lock the same data item (for read or write) until the first transaction releasesthe lock.

To summarize the compatibility:

S X

S Y N

X N N


33/413




lock-S(B)Read(B,b1)

unlock(B)lock-S(A)

Read(A,a2)unlock(A)lock-X(B)Read(B,b2)Temp=a2+b2Write (B,Temp)Unlock(B)

Lock-X(A)Read(A,a1)Temp=a1+b1Write(A,Temp)

unlock(A)

Locking (Example)

T1T1 T2T2B=200B=200

A=100A=100

A=300A=300

A=100A=100

B=200B=200

B=300B=300

A = 100A = 100

B = 200B = 200A = 300A = 300

B = 300B = 300


34/413




Intent Locking

Also called Preemptive lock

Used to tag (lock) all ancestors of a node to be locked in share or exclusivemode.

This tag signals to other requesting transactions that locking may take place ata finer level by the transaction that holds the intent lock

This prevents other transactions from obtaining shared or exclusive lock to theancestors.

A variant of this is the SIX (Share-intention exclusive ) lock

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, therequester node as well as all its descendants would be implicitly granted the same level of lock. For example, ifa transaction locks a table in exclusive mode, it means it has been implicitly given exclusive access to every rowof this table.

Thus, generalization can be made that the same lock is granted to the entire sub-tree starting at the requestednode.

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 acquirean exclusive lock on the entire table. After this, when A wants to update few more rows, it may not be possiblebecause the exclusive lock that has been acquired on the entire table by B will lock all rows of the table also inexclusive 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 nodesunder the subtree ie some rows of the table in future) . This will prevent B from acquiring an exclusive lock onthe 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 thissubtree, ie some row under the table in shared mode. This does not stop another transaction B from acquiring asimilar 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 evenreading 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


35/413




Lock Compatibility matrix

S Gives share access to the requested node and to all descendants of the requested node. Any othertransaction can get a S lock or IS lock

only.

X Gives exclusive access to the requested node and to all its descendants. No otherlocks are permitted in this mode.

IS Gives intention share access to the requested node and allows the requester toexplicitly 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 finerlevel is supported.

IX Gives intention exclusive access to the requested node and allows the requesterto explicitly lock the descendants in IS or IX modes. This is again subject to compatibility with theother mode at the descendant's level.

SIX The subtree rooted by the node under consideration is locked explicitly in a sharedmode and a few nodes at lower levels are being locked in the exclusive mode. Only another IS lock isallowed in this mode.

To understand the SIX mode, consider, there is an employee table which transaction T1 would beupdating. 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 anydescendant in the x mode. If T1 now comes to know that it has to update the same node that someother transaction has locked, it may have to wait. So, when T1 knows that it would be reading all therecords 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 anexclusive (X) mode


36/413




Two-Phase locking

Serializability of concurrently executing transactions can be guaranteed by twophase locking

Each transaction is divided into two phases:

Growingphase locks can be acquired but not released

Shrinkingphase locks can be released but not acquired

The Lost update problem and the Dirty Read problem show that serializability requires that atransaction updating a record should not only lock the record but also hold the lock untilCOMMIT/ROLLBACK time. The Incorrect summary problem and the Phantom Recordproblem require that the table itself be locked even for read transaction until the transactioncomes to an end. Thus, we can see that locks keep growing during a certain phase of thetransaction and the locks start shrinking during the COMMIT/ROLLBACK time.

Thus, there is a lock-growing phaseand lock-shrinking phase. Such a scheme is called Two-phaselocking (2PL).

The 2PL theory can be summarized as:

A transaction should not operate on any object unless the transaction has acquired an appropriatelock on the object.

The transaction should not acquire any fresh locks after releasing a lock.

We can say: Ifa transaction follows the 2PL protocol, then it is serializable.

It is very important to notice that all 2PL transactions are serializable. But, not all serializabletransactions follow 2PL protocol.Thus, 2PL protocol is a sufficient but not necessary condition forserialization. 2PL is a way of ensuring serializability in a simple way.


37/413




Lock-S(B)Read(B,b1)Lock-X(A)

unlock(B)

Lock-X(B)Read(B,b2)

Read(A,a1)Temp=a1+b1Write(A,Temp)unlock(A)

Locking (Example)T1T1

T2T2

B=200B=200

A=100A=100

A=300A=300

B=200B=200

A=300A=300

B=500B=500

Lock-S(A)Read(A,a2)unlock(A)

Temp=a2+b2

Write (B,Temp)Unlock(B)

A = 100A = 100

B = 200B = 200A = 300A = 300

B = 500B = 500


38/413




Deadlock

Occurs when two or more separate processes compete for resources held byone another.

T1

Write_lock A

action(s)

Write_lock B

WAIT

T2 must wait for T1 to release lock

T1 must wait for

T2 to release lock

T2

Read_lock B

action(s)

Read_lock A

WAIT

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 backto allow the other toproceed

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 resolvewhen they are detected

Detection may be based on:

Timeout

Wait-for-graph (shows which transactions are waiting on which other transactionsfor a lock)


39/413




Lock-X(A) t1update A t2

t3 lock-X(B)t4 update B

lock-X(B) t5update B t4 lock-X(A)

t5 update A

Deadlock

T1T1

T2T2


40/414




Summary

Transaction is a logical unit of work which takes the database from oneconsistent state to the other

Atomicity, consistency, isolation and durability are the ACID properties of atransaction

Data integrity and Security are enforced using SQL DDL statements

Transactions should be able to concurrently execute without affecting theconsistency of the database

Locking is a mechanism of achieving such controlled concurrency


41/41




Thank You!

6_transaction processing concepts, oltp, database integrity, security, con currency

Documents