RDBMS day6 DB07 - WordPress.com · ... Railway reservation, ... to provide system control ......

1

RDBMS - Day6OLTP basics, Concurrency, Data integrity, Security

2

ER/CORP/CRS/DB07/003

Version No: 2.02Copyright © 2004,

Infosys Technologies Ltd

Agenda

� Transactions� Data integrity & Security� Concurrency control

In today’s 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.+

3




Transaction

Logical unit of program execution that takes a database from one consistentstate to another consistent state

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




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 is a 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 that obtained by sequential execution

Durability-Recovery management

•To ensure that after successful transaction completion, all updates persist irrespective of system failures

5




active

partiallycompleted

failed

abortedcommitted

State diagram of a transaction

While executing

After th

e final

statement h

as

been execu

ted

When normal execution can’t

proceed

After rollback and

restoration to prev state

After successful completion

Transaction state

Active

Partially committed

Failed

Aborted

Committed

6




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 transactionThe ROLLBACK statement undoes all of the actions of a transaction. Consider the following exampleBegin transaction is not standard. A new transaction begins immediately after a commit statementCOMMIT;

Update AccountSet Balance = Balance - 100Where AccountNo = ‘11111’;

Update AccountSet Balance = Balance + 100Where AccountNo = ‘22222’;

COMMIT;COMMIT;

Update AccountSet Balance = Balance - 1000Where AccountNo = ‘11111’;

Update AccountSet Balance = Balance + 100Where AccountNo = ‘22222’;

ROLLBACK ;

7




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 the transaction.

•Typical examples are: Railway reservation, Bank transactions etc.

8




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




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




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

11




Entity Integrity

� The database models the outside world

� A table’s 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”

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.

12




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. For example, 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 a row 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 dept2. Automatically delete the employees who belong to the dept3. Set the dept column for the employees who belong to the dept to NULL4. Set the dept column of these employees to some default value which indicates they are currently not allotted to any deptTo achieve this, 4 options can be set in CREATE table command:ON DELETE RESTRICTON DELETE SET NULLON DELETE SET DEFAULTON 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 SalesRepsON DELETE SET NULL,ON UPDATE CASCADE,

Foreign key (Mfr, Product) REFERENCES Products ON DELETE RESTRICT

13




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

14




GRANT ….. TO …REVOKE ….. FROM ...

Data Definition Language statements for Data security

� GRANT & REVOKE

Privileges on a specified database

Privileges on specified tables or views

System privileges

15




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




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




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




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




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




ALL & PUBLIC arguments

� GRANT ALL PRIVILEGES ON Customer to User2� GRANT ALL ON Cusomer to PUBLIC;� GRANT SELECT ON Customer to PUBLIC;

21




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 GRANT

OPTION;

22




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




Examples of REVOKE

REVOKE INSERT ON Customer FROM User2;

REVOKE SELECT, INSERT ON Customer FROM User2, User3;

24

Concurrency

25




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 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 slideLost 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=20Read (A, a1) t1a1 = a1 + 5 t2

t3 Read (A, b1)Write(A,a1) t4Commit 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 readA 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 readThis 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 recordsLet’s 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

26

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-tempWrite(A,a2)read(B,b2)b2=b2+tempWrite(B,b2)

Trans T1Trans T1

Trans T2Trans T2

A = 200A = 200B = 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 = 135B = 165B = 165

t1

t2t3

t4

t5

t6t7

t8

TimeTime

Serial execution of two transactions

27

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.




Trans T1Trans T1

Trans T2Trans T2Read(A,a1)a1=a1-50Write(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+tempWrite(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 = 135B = 165B = 165

A = 200A = 200B = 100B = 100

t1

t2t3

t4t5

t6t7

t8

Serialized execution

28

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) t1

a1 = a1 + 50 t2t3 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

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.




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


30

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




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

t3 Read(A,b1)Write(A,a1) t4

t5 Sum = Sum + b1Read(B,a2) t6a2 = a2 +50 t7Write(B,a2) t8Commit t9

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

A = 100A = 100B = 200B = 200


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




TRANS-T1 Time TRANS-T2

Insert X

T1 Sum = 0

Insert Y

T2

T3

Read (X, Bal_X)T4

Sum=sum + Bal_X T5

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




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 Sharedor Exclusive

� An example ->

Granularity of locksA database consists of several items that form a hierarchy. For example, the general hierarchy is:1. A field2. A data row or a tuple3. A table4. A tablespace4. 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 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 can’t lock the same data item (for read or write) until the first transaction releases the lock.

To summarize the compatibility:

S X

S Y N

X N N

33




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+b1

Write(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




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

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 doesn’t 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 ex planation on the SIX lock

35




Lock Compatibility matrix

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

36




Two-Phase locking

� Serializability of concurrently executing transactions can be guaranteed by two phase locking

� Each transaction is divided into two phases:� Growing phase locks can be acquired but not released

� Shrinking phase locks can be released but not acquired

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.

37




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

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

Read(A,a1)Temp=a1+b1 Write(A,Temp)unlock(A)

Locking (Example)T1T1

T2T2B=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+b2Write (B,Temp)Unlock(B)

A = 100A = 100B = 200B = 200

A = 300A = 300B = 500B = 500

38




Deadlock

� Occurs when two or more separate processes compete for resources held by one another.

T1Write_lock A… action(s)

Write_lock BWAIT

T2 must wait for T1 to release lock

T1 must wait for T2 to release lock

T2

Read_lock B… action(s)

Read_lock AWAIT

•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)

39




Lock-X(A) t1update A t2

t3 lock-X(B)t4 update B

lock-X(B) t5

update B t4 lock-X(A)t5 update A

Deadlock

T1T1 T2T2

40




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

41




Thank You!

RDBMS day6 DB07 - WordPress.com · ... Railway reservation, ... to provide system control ......

Documents

Transcript of RDBMS day6 DB07 - WordPress.com · ... Railway reservation, ... to provide system control ......