B.Sc (Computer Science) Database Management Systems UNIT - IV

Transcription

1 1 B.Sc (Computer Science) Database Management Systems UNIT - IV Transaction:- A transaction is any action that reads from or writes to a database. Suppose a customer is purchasing a product using credit card then after purchasing the product customer may be charged from account. So the sales transactions consists of the following parts: a) We must write a new customer invoice b) We must reduce the quantity in the product s inventory c) We must update the account transactions d) We must update the customer balance. A transaction may consists of a simple SELECT Statement to generate a list of table contents, it may consists of series of related UPDATE statements to change the attribute s values in various tables, it may consist of a series of INSERT Statements to add rows to one or more table or it may consists of a combination of SELECT, UPDATE and INSERT Statements. A transaction is a logical unit of work that must be entirely completed or entirely aborted. All of the SQL statements in the transaction must be completed successfully. If any of the SQL statements fail, the entire transaction is rolled back to the original database state that existed before the transaction started. A successful transaction changes the database from one consistent state to another. In a consistent database state all data integrity constraints are satisfied. To ensure consistency of the database, every transaction must begin with the database in a known consistent state. If the database is not in a consistent state, the transaction will yield an inconsistent database that violates its integrity and business rules. Transaction Properties:- Each individual transaction must contains the properties like a) Atomicity b) Consistency c) Isolation d) Durability e) Serializability a) Atomicity:- Atomicity requires that all operations of a transaction be completed. If not the transaction T1 has four SQL requests, all four requests must be successfully completed otherwise the entire transaction is aborted. A transaction is treated as a single, indivisible logic unit of work. b) Consistency:-

2 2 Consistency indicates the permanence of the databases consistent state. A transaction takes a database from one consistent state to another consistent state. When a transaction is completed the database must be in a consistent state, if any of the transaction parts violates an integrity constraint, the entire transaction in aborted. c) Isolation:- Isolation means that the data used during the execution of transaction can not be used by a second transaction until the first one is completed. This property is particularly useful in multi-user database environments because several users can access and update the database at the same time. d) Durability:- Durability ensures that once transaction changes are done, they con not be undone even a system failure occurs. e) Serializability:- When execution multiple transactions the DBMS must schedule the concurrent execution of the transaction s operations. This property is riffed as serializability. This property is important in multi-user and distributed databases. Transaction Management with SQL:- Transaction support is provided by two SQL statements: COMMIT and ROLLBACK. A COMMIT statement is used to make permanent all changes recorded within the database. The COMMIT statement automatically ends the SQL transaction. A ROLLBACK statement is used to abort the changes that are made to the database and the database is rolled back to its previous consistent state. For example Update emp set sal=sal+500 where deptno=20; Update student set cs=80 where rollno=2364; Commit; In the above example it is not necessary if the update statement is the last action in the application and the application terminates normally but good programming practice is that include the COMMIT statement at the end of transaction. The transaction log:- A DBMS uses a transaction log to keep track of all transactions that update the database. When a program is abnormally terminated or a system failure occurred such as network discrepancy or disk crash then ROLLBACK statement is triggered to recover the information stored in this log is used by DBMS. The transaction log stores: a) A record for the beginning of the transaction. b) For each transaction component (SQL statement) like

3 3 i. The type of operation being performed (update,delete,insert) ii. The names of the objects affected by the transaction (The name of the table) iii. The before and after values for the fields being updated. c) The ending (COMMIT) of the transaction. Although using a transaction log increase the processing overhead of a DBMS but it restores a corrupted database. If a system failure occurs, the DBMS will examine the transaction log for all uncommitted or incomplete transactions and restore (ROLLBACK) the database to its previous state on the basis of that information. When recovery process is completed, the DBMS will write in the log all committed transactions that were not physically written to the database before the failure occurred. Committed transactions are not rolled back. Therefore the transaction log is a critical pack of the database and it is usually implemented as one or more files that are managed separately from the actual database files. Concurrency Control:- The coordination of the simultaneous execution of transactions in a multi user database system is known as concurrency control. The objective of concurrency control is to ensure the serializability of transaction in a multi-user database environment. Concurrency control is important because the simultaneous execution of transactions over a shared database can several data integrity and consistency problems. The three main problems are a) Lost updates b) Uncommitted data c) Inconsistent data a) Lost updates:- The Lost Updates problem occurs when two concurrent transactions T1 and T2 are updating the same data element and one of the updates is lost. b) Uncommitted data:- Uncommitted data occurs when two transactions T1 and T2 are executed concurrently and the first transaction (T1) is rolled back after the second transaction (T2) has already accessed the uncommitted data. Thus it is violating Isolation property of transactions. c) Inconsistent retrievals:- Inconsistent retrievals occur when a transaction access data before and after another transactions finish working with such data.

4 4 The Scheduler:- The database consistency can be ensured only before and after the execution of transactions. The Scheduler is a special DBMS process that establishes the order in shish the operations with in concurrent transactions are executed. The scheduler interleaves the execution of database operations to ensure serializability and isolation of transactions. To determine the appropriate order the scheduler bases its actions on concurrency control algorithms such as locking methods or time stamping methods. The scheduler s main job is to create a serializable schedule of a transaction s operations. The DBMS determines what transactions are serializable and proceeds to interleave the execution of the transaction s operations. So the scheduler makes sure that the computer s CPU and Storage System are used efficiently. When transactions are not serializable then they are executed on first come, first served basis by the DBMS. The problem with this approach is processing time of CPU is wasted. The scheduler also facilitates data isolation to insure that two transactions do not update the same data element at the same time. Concurrency Control with Locking Methods:- A transaction acquires a lock prior to data access, the lock is released (Unlocked) when the transaction is completed, so that another transaction can lock the data item. Transaction T2 does not have access to a data item that is currently being used by transaction T1. Most multi-user DBMS automatically initiate and enforce locking procedures. All lock information is managed by a lock manager, which is responsible for assigning and policing the locks used by the transactions. Lock Granularity :- (or) Locking Level Lock granularity indicates the level of lock use. Locking can take place at the following level. a) Database level b) Table level c) Page level d) Row level e) Field (attribute level) a) Database level:- In database level lock the entire database is locked. So if transaction T1 is accessing that database, then transaction T2 can not access it.

5 5 This level of locking is good for batch processes but it is unsuitable for multi user DBMS. Because thousands of transactions had to wait for the previous transaction to be completed before the next one could reserve the entire database. So the data access would be slow. Table level:- In table level lock the entire table is locked that means if transaction T1 is accessing a table then transaction T2 can not access the same table. If a transaction requires access to several tables, each table may be locked. Table level locks are less restrictive than database level locks. Table level locks are not suitable for multi-user DBMS. The draw back of table level lock is suppose transaction T1 and T2 can not access the same table even when they try to use different rows; T2 must wait until T1 unlocks the table. Page level:- In a page level lock, the DBMS will lock on entire disk page. A disk page or page is also referred as a disk block, which is described as a section of a disk. A page has a fixed size such as 4k, 8k or 16k. A table can span several pages, and a page can contain several rows of one or more tables. Page level locks are currently frequently used multi-user DBMS locking method. Page level lock is shown in the following fig. Payroll Database T1 is accessing Page1 Page2 T2 is accessing In the above fig. T1 and T2 access the same table while locking different disk pages. If T2 requires the use of a row located on a page that is locked by T1, T2 must wait until the page is unlocked. Row level:- A row level lock is mush less restrictive than the other locks. The DBMS allows concurrent transactions to access different rows of the same table even the rows are located on the same pages. The row level locking approach improves the availability of data. But row level locking management requires high overhead because a lock exist for each row in a table of the database. So it involves a conflicting transaction. Field level:-

6 6 The field level lock allows concurrent transactions to access the same row as long as they require the use of different fields (attributes) with in that row. Although field level locking clearly yields the most flexible multi user data access, but it is rarely implemented in a DBMS because it requires an extreme High Level computer overhead. Lock Types:- The DBMS use different lock types like a) Binary Locks b) Shared/Exclusive Locks. a) Binary Locks:- A binary lock has two states: a) Locked b) Unlocked In an object is locked by a transaction no other transaction can use that object. The object may be a database, table, page or row. If an object is unlocked, any transaction can lock the object for its use. Every database operation requires that the affected object be locked. A transaction must unlock the object after its termination. Therefore every transaction requires a lock and unlocks operation for each data item that is accessed. Such operations are automatically managed and scheduled by the DBMS. Every DBMS has a default locking mechanism. If the end user wants to override the default, the LOCK TABLE and other SQL commands are available. Using binary locks the lost update problem is eliminated in concurrency control because the lock released until the WRITE statement is completed. But binary locks are how considered too restrictive to yield optional concurrency conditions For example the DBMS will not allow two transactions to read the same database object even though neither transaction updates the database. Shared/Exclusive Locks:- A shared lock exists when concurrent transactions are granted read access on the basic of a common lock. A shared lock produces no conflict as long as all the concurrent transactions are read only. An exclusive lock exists when access is reserved specifically for the transaction that locked the object. The exclusive lock must be used when conflicts exists lock one transaction is READ and other is WRITE. So a shared lock is issued when a transaction wants to read data from the data base and an exclusive lock is issued when a transaction wants to update (WRITE) a data item. Using Shared/Exclusive locking concept a lock can have 3 states a) Unlocked b) Shared (read) c) Exclusive (write)

7 7 Example for shared lock: If transaction T1 has shared lock on data item X and transaction T2 wants to read data item X. So T2 may also obtain a shared lock on data item X.\ Example for Shared/Exclusive lock: If transaction T1 has Shared/Exclusive lock on data item X and transaction T2 wants an exclusive lock to update data item X. But an exclusive lock can not be granted to transaction T2 and it must wait till T1 is saved. So The exclusive lock is granted if and only if no other are held on the data item. Shared/Exclusive locks are more efficient but these increase the lock manager s overhead because of the following reasons. a) The type of the lock must be held before a lock is granted. b) First lock type has to check, then lock is issued and then release the lock. Shared/Exclusive locks can lead to two major problems: a) The resulting transaction schedule might not be serializable. b) The schedule might create deadlock. Two Phase Locking to ensure Serializability:- Two phase locking defines how transactions acquire locks. Two phase locking guarantees Serializability but it does not prevent dead locks. The two phases are a) A growing phase in which a transaction acquires all required locks with out unlocking any data. Once all locks have been acquired the transaction is in its locked point. b) A shrinking phase, in which a transaction releases all locks and can not obtain any new lock. In two phase locking protocol the transaction acquires all the locks until it reaches its locked point. When the locked point is reached, the data are modified to conform to the transaction requirements. Finally the transaction is completed, and then it releases all the locks which are acquired. The two phase locking increase the transaction processing cost but the drawback is it might create deadlocks. Dead Locks:- A dead lock occurs when two transactions wait indefinitely for each other to unlock data For example a dead lock occurs when two transactions, T1 and T2 exist in the following mode. T1: access data items X and Y. T2: access data items Y and X. T1 and T2 transactions are executing simultaneously so, T1 has locked data item X and T2 has locked data item Y. Now transaction T1 is waiting to lock data item Y but it is already locked by T2. Simultaneous T2 is waiting to lock X but it is already locked by T1. So both transactions are waiting to access other items. Thus condition is referred as Dead Lock.

8 8 So in real world DBMS, many transactions can be executed simultaneously, there by increasing the probability of generating dead Locks. The 3 basic techniques to control dead locks are a) Dead Lock Prevention:- A transaction requesting a new lock is aborted when there is the possibility that a dead lock can occur. If the transaction is aborted, all changes made by this transaction are rolled back, and all locks obtained by the transaction are released. This method is used when there is existing high probability of dead lock. b) Dead Lock Detection:- The DBMS tests the database for dead locks. If a dead lock is found, one of the transactions is aborted and the other transaction continues. This method is used when there is un probability of dead locks. c) Dead Lock Avoidance:- The transaction must obtain all of the locks if needs before it can be executed. This technique avoids the rollback of conflicting transactions. Concurrency Control with Time Stamping Methods:- Time stamping methods are used to manage concurrency transaction execution. In time stamping approach, for each transaction unique time stamp assigned. Time stamps must have two properties. a) Uniqueness: It specifies unique time stamp value exist, that means no equal time stamp values can exist. b) Monotonicity: It specifies that time stamp values always increase. The disadvantage of time stamping approach is that each values stored in the database requires two additional time stamp fields. They are a) One field is for the last time the field was read b) Another field is for the last update. So time stamping increases memory needs and the database s processing overhead. Wait/die and Wound/wait Schemes:- The wait/die and wound/wait scheme are used in time stamping method. Example: Assume that we have two conflicting transactions: T1 and T2, each with a unique time stamp. Suppose T1 has time stamp of and T2 has a time stamp of So T1 is the order transaction and T2 is newer (younger) transaction. Using the wait/die scheme:- a) If the transaction requesting the lock is the order of the two transactions, it will wait until the other transactions is completed, and the locks are relapsed.

9 9 b) If the transaction requesting the lock is the younger of the two transactions, it will die (rollback) and is rescheduled using the same time stamp. That means in wait/die scheme, the order transaction waits for the younger to complete and release its locks. Using the wound/wait scheme:- a) If the transaction requesting the lock is the older of the two transactions, it will preempt (wound) the younger transaction (by rolling it back). The younger transaction is rescheduled using the same time stamp. b) If the transaction requesting the lock is the younger of the two transactions, it will wait until the other transaction is completed and the locks are released. That means in the wound/wait scheme, the older transaction rolls back the younger transaction and reschedules it. Concurrency Control with Optimistic methods:- The optimistic approach is based on the assumption that the majority of the database operations do not conflict. The optimistic approach requires neither locking nor time stamping techniques. Using an optimistic approach, each transaction moves through three phases. They are a) Read Phase b) Validation Phase c) Write Phase. During the read phase, the transaction reads the database, executes the needed computations, and makes the updates to a private copy of the data base values. All the update operations of the transaction are recorded in a temporary update file, which is not accessed by the remaining transactions. During the validation phase the transaction is validated to ensure that the changes made will not affect the integrity and consistency of the database. If the validation test is positive, the transaction goes to the write phase. If the validation test is negative, the transaction is restarted and the changes are discarded. Database Recovery Management:- Database recovery restores a database from an inconsistent to a previous consistent state. If, for some reason any transaction operation can not be completed, the transaction must be rolled back. That means transaction recovery reverses all of the changes that the transaction made to the database before the transaction was aborted. Recovery techniques also apply to the database and to the system after some type of critical error has occurred. Examples of critical events are: a) Hardware/Software failures:- Failure of this type could be a hard disk failure, a bad capacitor on a mother board or a failing memory. b) Human Caused incidents:-

10 10 This type of events can be categorized as unintentional and intentional. An unintentional failure is caused by carelessness by end users. Such errors include deleting the wrong rows from a table, pressing wrong key on the keyboard or shutting down the main database server by accident. Intentional events are securing threats caused by hackers trying to gain unauthorized access to data resources and virus attacks. c) Natural disasters:- This category includes fires, earthquakes, floods etc. A critical error can render the database in an inconsistent state. Transaction Recovery:- Database transaction recovery uses data in the transaction log to recover a database from an inconsistent state to a consistent state. Database recovery process involves bringing the database to a consistent state after a failure. Transaction recovery procedures generally make use of differed-write and writethrough techniques. When the recovery procedure uses a differed-write technique, the transaction operations do not immediately update the physical database. Only the transaction log is updated. The database is physically updated only after the transaction reaches its commit point, using information from the transaction log. If the transaction aborts before it reaches its commit point, no changes need to be made to the database because the database was never updated. When the recovery procedure uses a write-through technique, the database is immediately updated by transaction operations during the transactions execution, even before the transaction reaches its commit point. If the transaction aborts before it reaches its commit point, a ROLLBACK or undo operation needs to be done to restore the database to a consistent state. In this case the ROLLBACK operation will use transaction log before values.