Transcription

1

2

3

4

5

6

7

8

9

10

11

12

13 A can be implemented as a separate process to which transactions send lock and unlock requests

14 The lock manager replies to a lock request by sending a lock grant messages (or a message asking the transaction to roll back, in case of a deadlock) The requesting transaction waits until its request is answered The lock manager maintains a datastructure called a to record granted locks and pending requests The lock table is usually implemented as an in-memory hash table indexed on the name of the data item being locked Black rectangles indicate granted locks, white ones indicate waiting requests Lock table also records the type of lock granted or requested New request is added to the end of the queue of requests for the data item, and granted if it is compatible with all earlier locks Unlock requests result in the request being deleted, and later requests are checked to see if they can now be granted. If transaction aborts, all waiting or granted requests of the transaction are deleted o lock manager may keep a list of locks held by each transaction, to implement this efficiently Each transaction is issued a timestamp when it enters the system. If an old transaction has time-stamp TS(), a new transaction is assigned time-stamp TS() such that TS() <TS(). The protocol manages concurrent execution such that the time-stamps determine the serializability order. In order to assure such behavior, the protocol maintains for each data two timestamp values: () is the largest time-stamp of any transaction that executed () successfully.

15 () is the largest time-stamp of any transaction that executed () successfully. The timestamp ordering protocol ensures that any conflicting and operations are executed in timestamp order. Suppose a transaction Ti issues a () 1. If TS() -timestamp(), then needs to read a value of that was already overwritten. Hence, the operation is rejected, and is rolled back. 2. If TS() -timestamp(), then the operation is executed, and R-timestamp() is set to the maximum of Rtimestamp() and TS(). Suppose that transaction issues (). If TS() < R-timestamp(), then the value of that is producing was needed previously, and the system assumed that that value would never be produced. Hence, the operation is rejected, and is rolled back. If TS() < W-timestamp(), then is attempting to write an obsolete value of. Hence, this operation is rejected, and is rolled back. Otherwise, the operation is executed, and W-timestamp() is set to TS(). The Database Engine uses intent locks to protect placing a shared (S) lock or exclusive (X) lock on a resource lower in the lock hierarchy. Intent locks are named intent locks because they are acquired before a lock at the lower level, and therefore signal intent to place locks at a lower level. Intent locks serve two purposes: To prevent other transactions from modifying the higher-level resource in a way that would invalidate the lock at the lower level. To improve the efficiency of the Database Engine in detecting lock conflicts at the higher level of granularity. For example, a shared intent lock is requested at the table level before shared (S) locks are requested on pages or rows within that table. Setting an intent lock at the table level prevents another transaction from subsequently acquiring an exclusive (X) lock on the table containing that page. Intent locks improve performance because the Database Engine examines intent locks only at the table level to determine if a transaction can safely acquire a lock on that table. This removes the requirement to examine every row or page lock on the table to determine if a transaction can lock the entire table.

16 Intent locks include intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX). Intent shared (IS) Protects requested or acquired shared locks on some (but not all) resources lower in the hierarchy. Intent exclusive (IX) Protects requested or acquired exclusive locks on some (but not all) resources lower in the hierarchy. IX is a superset of IS, and it also protects requesting shared locks on lower level resources. Shared with intent exclusive (SIX) Protects requested or acquired shared locks on all resources lower in the hierarchy and intent exclusive locks on some (but not all) of the lower level resources. Concurrent IS locks at the top-level resource are allowed. For example, acquiring a SIX lock on a table also acquires intent exclusive locks on the pages being modified and exclusive locks on the modified rows. There can be only one SIX lock per resource at one time, preventing updates to the resource made by other transactions, although other transactions can read resources lower in the hierarchy by obtaining IS locks at the table level. Intent update (IU) Protects requested or acquired update locks on all resources lower in the hierachy. IU locks are used only on page resources. IU locks are converted to IX locks if an update operation takes place. Shared intent update (SIU) A combination of S and IU locks, as a result of acquiring these locks separately and simultaneously holding both locks. For example, a transaction executes a query with the PAGLOCK hint and then executes an update operation. The query with the PAGLOCK hint acquires the S lock, and the update operation acquires the IU lock.

17 Update intent exclusive (UIX) A combination of U and IX locks, as a result of acquiring these locks separately and simultaneously holding both locks. A system is in a deadlock state if there exists a set of transactions such that every transaction in the set is waiting for another transaction in the set. More precisely, there exists a set of waiting transactions 0, 1 such that 0 is waiting for a data item that 1 holds, and 1 is waiting for a data item that 2 holds, and, and 1 is waiting for a data item that holds, and is waiting for a data item that 0 holds. None of the transactions can make progress in such a situation. The only remedy to this undesirable situation is for the system to invoke some drastic action, such as rolling back some of the transactions involved in the deadlock. Rollback of a transaction may be partial: That is, a transaction may be rolled back to the point where it obtained a lock whose release resolves the deadlock. There are two principal methods for dealing with the deadlock problem. We can use a protocol to ensure that the system will enter a deadlock state. Alternatively, we can allow the system to enter a deadlock state, and then try to recover by using a and scheme. As we shall see, both methods may result in transaction rollback. Prevention is commonly used if the probability that the system would enter a deadlock state is relatively high; otherwise, detection and recovery are more efficient. Note that a detection and recovery scheme requires overhead that includes not only the run-time cost of maintaining the necessary information and of executing the detection algorithm, but also the potential losses inherent in recovery from a deadlock. Consider the following two transactions: System is deadlocked if there is a set of transactions such that every transaction in the set is waiting for another transaction in the set.

18 protocols ensure that the system will enter into a deadlock state. Some prevention strategies : Require that each transaction locks all its data items before it begins execution (predeclaration). Impose partial ordering of all data items and require that a transaction can lock data items only in the order specified by the partial order (graph-based protocol). Following schemes use transaction timestamps for the sake of deadlock prevention alone. older transaction may wait for younger one to release data item. Younger transactions never wait for older ones; they are rolled back instead. a transaction may die several times before acquiring needed data item older transaction (forces rollback) of younger transaction instead of waiting for it. Younger transactions may wait for older ones. may be fewer rollbacks than scheme. Both in and in schemes, a rolled back transactions is restarted with its original timestamp. Older transactions thus have precedence over newer ones, and starvation is hence avoided. a transaction waits for a lock only for a specified amount of time. After that, the wait times out and the transaction is rolled back.thus deadlocks are not possible simple to implement; but starvation is possible. Also difficult to determine good value of the timeout interval. Deadlocks can be described as a, which consists of a pair = (,), is a set of vertices (all the transactions in the system) is a set of edges; each element is an ordered pair. If is in, then there is a directed edge from to, implying that is waiting for to release a data item. When requests a data item currently being held by, then the edge is inserted in the wait-for graph. This edge is removed only when is no longer holding a data item needed by. The system is in a deadlock state if and only if the wait-for graph has a cycle. Must invoke a deadlockdetection algorithm periodically to look for cycles.

19 Wait-for graph without a cycle Wait-for graph with a cycle When deadlock is detected : Some transaction will have to rolled back (made a victim) to break deadlock. Select that transaction as victim that will incur minimum cost. Rollback -- determine how far to roll back transaction Total rollback: Abort the transaction and then restart it. More effective to roll back transaction only as far as necessary to break deadlock. Starvation happens if same transaction is always chosen as victim. Include the number of rollbacks in the cost factor to avoid starvation If two-phase locking is used : A operation may be performed only if the transaction deleting the tuple has an exclusive lock on the tuple to be deleted. A transaction that inserts a new tuple into the database is given an X-mode lock on the tuple Insertions and deletions can lead to the. A transaction that scans a relation (e.g., find all accounts in Perryridge) and a transaction that inserts a tuple in the relation (e.g., insert a new account at Perryridge) may conflict in spite of not accessing any tuple in common. If only tuple locks are used, non-serializable schedules can result: the scan transaction may not see the new account, yet may be serialized before the insert transaction. The transaction scanning the relation is reading information that indicates what tuples the relation contains, while a transaction inserting a tuple updates the same information. The information should be locked. Associate a data item with the relation, to represent the information about what tuples the relation contains.

20 Transactions scanning the relation acquire a shared lock in the data item, Transactions inserting or deleting a tuple acquire an exclusive lock on the data item. (Note: locks on the data item do not conflict with locks on individual tuples.) Above protocol provides very low concurrency for insertions/deletions. Index locking protocols provide higher concurrency while preventing the phantom phenomenon, by requiring locks on certain index buckets. Serializability is the classical concurrency scheme. It ensures that a schedule for executing concurrent transactions is equivalent to one that executes the transactions serially in some order. It assumes that all accesses to the database are done using read and write operations. A schedule is called ``correct'' if we can find a serial schedule that is ``equivalent'' to it. Given a set of transactions T1...Tn, two schedules S1 and S2 of these transactions are equivalent if the following conditions are satisfied: : If a transaction reads a value written by another transaction in one schedule, then it also does so in the other schedule. : If a transaction overwrites the value of another transaction in one schedule, it also does so in the other schedule. These two properties ensure that there can be no difference in the effects of the two schedules. As an example, consider the schedule in Figure 1. It is equivalent to a schedule in which T2 is executed after T1. There are several approaches to enforcing serializability. Let us consider a schedule in which there are two consecutive instructions and, of transactions and, respectively ( = ). If and refer to different data items, then we can swap and without affecting the results of any instruction in the schedule. However, if and refer to the same data item, then the

21 order of the two steps maymatter. Since we are dealing with only read and write instructions, there are four cases that we need to consider: = read(), = read(). The order of and does not matter, since the same value of is read by and, regardless of the order. = read(), = write(). If comes before, then does not read the value of that is written by in instruction. If comes before, then reads the value of that is written by. Thus, the order of and matters. = write(), = read(). The order of and matters for reasons similar to those of the previous case. = write(), = write(). Since both instructions are write operations, the order of these instructions does not affect either or. However, the value obtained by the next read() instruction of is affected, since the result of only the latter of the two write instructions is preserved in the database. If there is no other write() instruction after and in, then the order of and directly affects the final value of in the database state that results from schedule. In this section, we consider a form of equivalence that is less stringent than conflict equivalence, but that, like conflict equivalence, is based on only the read and write operations of transactions. Consider two schedules and, where the same set of transactions participates in both schedules. The schedules and are said to be if three conditions are met: For each data item, if transaction reads the initial value of in schedule, then transaction must, in schedule, also read the initial value of. For each data item, if transaction executes read() in schedule, and if that value was produced by a write() operation executed by transaction, then the read() operation of transaction must, in schedule, also read the value of that was produced by the same write() operation of transaction. For each data item, the transaction (if any) that performs the final write() operation in schedule must perform the final write() operation in schedule. The isolation level used during the execution of SQL statements determines the degree to which the activation group is isolated from concurrently executing activation groups.thus, when activation group P executes an SQL statement, the isolation level determines: * The degree to which rows retrieved by P and database changes made by P are available to other concurrently executing activation groups. * The degree to which database changes made by concurrently executing activation groups can affect P. to this approach: read-intensive applications typically want more index structures, data redundancies, and even other views of data. Transaction processing systems want the best

22 write throughput while incurring only the most minimal overhead. The access patterns of readers and writers typically differ: Readers are more prone to larger analysis types of queries, and writers are more prone to singleton inserts, updates, and deletes. When these activities are separated, the administrator can focus on recovery strategies for a smaller, more manageable transaction processing system. OLTP databases tend to be much smaller than data redundant decision-support or analysis-oriented databases. 1. READ UNCOMMITTED 2. READ COMMITTED 3. REPEATABLE READ 4. SERIALIZABLE When it's used, SQL Server not issue shared locks while reading data. So, you can read an uncommitted transaction that might get rolled back later. This isolation level is also called dirty read. This is the lowest isolation level. It ensures only that a physically corrupt data will not be read. This is the default isolation level in SQL Server. When it's used, SQL Server will use shared locks while reading data. It ensures that a physically corrupt data will not be read and will never read data that another application has changed and not yet committed, but it does not ensure that the data will not be changed before the end of the transaction. When it's used, the dirty reads and nonrepeatable reads cannot occur. It means that locks will be placed on all data that is used in a query, and another transactions cannot update the data. Most restrictive isolation level. When it's used, then phantom values cannot occur. It prevents other users from updating or inserting rows into the data set until the transaction is complete. A is a of program execution that accesses and possibly updates various data items. Understanding the concept of a transaction is critical for understanding and implementing updates of data in a database, in such a way that concurrent executions and failures of various forms do not result in the database becoming inconsistent. Transactions are required to have the ACID properties: atomicity, consistency, isolation, and durability. Atomicity ensures that either all the effects of a transaction are reflected in the database, or none are; a failure cannot leave the database in a state where a transaction is partially executed.

23 Consistency ensures that, if the database is initially consistent, the execution of the transaction (by itself) leaves the database in a consistent state. Isolation ensures that concurrently executing transactions are isolated from one another, so that each has the impression that no other transaction is executing concurrently with it. Durability ensures that, once a transaction has been committed, that transaction s updates do not get lost, even if there is a system failure. Concurrent execution of transactions improves throughput of transactions and system utilization, and also reduces waiting time of transactions. When several transactions execute concurrently in the database, the consistency of data may no longer be preserved. It is therefore necessary for the system to control the interaction among the concurrent transactions. Since a transaction is a unit that preserves consistency, a serial execution of transactions guarantees that consistency is preserved. A captures the key actions of transactions that affect concurrent execution, such as read and write operations, while abstracting away internal details of the execution of the transaction. We require that any schedule produced by concurrent processing of a set of transactions will have an effect equivalent to a schedule produced when these transactions are run serially in some order. A system that guarantees this property is said to ensure. There are several different notions of equivalence leading to the concepts of and. Serializability of schedules generated by concurrently executing transactions can be ensured through one of a variety of mechanisms called schemes. Schedules must be recoverable, to make sure that if transaction sees the effects of transaction, and then aborts, then also gets aborted. Schedules should preferably be cascadeless, so that the abort of a transaction does not result in cascading aborts of other transactions. Cascadelessness is ensured by allowing transactions to only read committed data. >>Transaction >>ACID properties >>Atomicity >>Isolation >>Durability >>Concurrent executions >>Serial execution >>Schedules >>Conflict of operations >>Conflict equivalence >>Consistency >>Conflict serializability >>View equivalence >>View serializability 1. A is a of program execution that accesses and possibly updates various data items ensures that either all the effects of a transaction are reflected in the database, or none are. 3. In a property, After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures.

24 4. Concurrency is the ability of the DBMS to process more than one transaction at a time. a. Concurrency b. Transaction c. Recovery d. None of the above a. Recovery b. Schedule c. Concurrency d. None of the above? a. Precedence Graph b. Serializability Graph c. Only a d. Only b e. Both a and b a. True b. False a. Recovery b. Schedule c. Concurrency d. None of the above a. True b. False a. Crash Recovery b. Concurrency c. Consistency d. Commit a. explicit transaction and transaction b. explicit transaction and transaction c. explicit transaction and transaction d. explicit transaction and transaction a. Serializable Schedule b. Equivalent Schedule c. Serial Schedule a. None of the above a. True b. False 1.Define Transaction? 2.What are the properties of transaction? 3.What is serial schedule? 4.Define serializability?

25 5.What is conflict serializability? 6.What is view serializability? 7.How will you test conflict serializaility? 8.What is timestamp? 9.What timestamp values are associated with a data item? 10. What are the primitives of transaction? 11. What are the two types of lock modes? 12. List out the concurrency control techniques? 13. What are the different types of failure? 14. What is redo and undo operation? 15. Difference between immediate & deferred update recovery schemes? 16. What is rollback? 1. Explain the four important properities of transaction that a DBMS must ensure to maintain database. 2. (i) What is concurrenct control? How is it implemented in DBMS? Explain. (ii) Explain various recovery techniques during ttansaction in detail. 3. (i) Explain the different fi\orms of serializability. (ii) What are the different types of schdules are acceptable for recoverability? 4. (i) Explain on two-phase locking protocol and timestemp-based protocol. (ii) Write short notes on log-based recovery.