Distributed Database Design and Relational Query Language
Download as PPTX, PDF0 likes136 views
1) The document discusses topics related to distributed database design and relational query languages including transaction management, serializability, blocking, deadlocks, and query optimization. 2) A transaction begins with the first SQL statement and ends when committed or rolled back. It has ACID properties - atomicity, consistency, isolation, and durability. 3) Serializability ensures transactions are processed in a consistent order. Conflict serializability allows swapping non-conflicting operations while view serializability requires equivalent initial reads, write-read sequences, and final writers.
Distributed Database Design and Relational Query Language
- 1. Distributed database Design & Relational Query Language
- 2. Content • Transaction Management • Serializability • Blocking • Deadlock • Query Optimization
- 3. Transaction Management • A transaction is a logical unit of work that contains one or more SQL statements. A transaction is an atomic unit. • A transaction begins with the first executable SQL statement. A transaction ends when it is committed or rolled back, either explicitly with a COMMIT or ROLLBACK statement or implicitly when a DDL statement is issued. • For example : Lets consider a banking database. When a bank customer transfers money from a savings account to a checking account, the transaction can consist of three separate operations:
- 5. Transaction States There are the following six states in which a transaction may exist: A) Active: The initial state when the transaction has just started execution. B) Partially Committed: At any given point of time if the transaction is executing properly, then it is going towards it COMMIT POINT. The values generated during the execution are all stored in volatile storage. C) Failed: If the transaction fails for some reason. The temporary values are no longer required, and the transaction is set to ROLLBACK. It means that any change made to the database by this transaction up to the point of the failure must be undone. If the failed transaction has withdrawn Rs. 100/- from account A, then the ROLLBACK operation should add Rs 100/- to account A. D) Aborted: When the ROLLBACK operation is over, the database reaches the BFIM. The transaction is now said to have been aborted.
- 6. Transaction States Continue.. E) Committed: If no failure occurs then the transaction reaches the COMMIT POINT. All the temporary values are written to the stable storage and the transaction is said to have been committed. F) Terminated: Either committed or aborted, the transaction finally reaches this state. Partially committed Committed Terminated AbortedFailed Active
- 7. Properties of Transaction A Transaction has four properties, taking the initial letters of these four properties we collectively call them the ACID Properties. 1. Atomicity: This means that either all of the instructions within the transaction will be reflected in the database, or none of them will be reflected. for example, we have two accounts A and B, each containing Rs 1000/-. We now start a transaction to deposit Rs 100/- from account A to Account B. Read A; A = A – 100; Write A; Read B; B = B + 100; Write B;
- 8. Properties of Transaction 2. Consistency: If we execute a particular transaction in isolation or together with other transaction, (i.e. presumably in a multi- programming environment), the transaction will yield the same expected result. • To give better performance, every database management system supports the execution of multiple transactions at the same time, using CPU Time Sharing. Concurrently executing transactions may have to deal with the problem of sharable resources, i.e. resources that multiple transactions are trying to read/write at the same time. • For example . A transaction which deposits Rs 100/- to account A must deposit the same amount whether it is acting alone or in conjunction with another transaction that may be trying to deposit or withdraw some amount at the same time.
- 9. Properties of Transaction 3. Isolation: In case multiple transactions are executing concurrently and trying to access a sharable resource at the same time, the system should create an ordering in their execution so that they should not create any anomaly in the value stored at the sharable resource. 4. Durability: It states that once a transaction has been complete the changes it has made should be permanent. • As we have seen in the explanation of the Atomicity property, the transaction, if completes successfully, is committed. Once the COMMIT is done, the changes which the transaction has made to the database are immediately written into permanent storage. So, after the transaction has been committed successfully, there is no question of any loss of information even if the power fails. Committing a transaction guarantees that the AFIM has been reached.
- 10. Serializability Serializability is a concept that helps to identify which non-serial schedules are correct and will maintain the consistency of the database. Why? When multiple transactions run concurrently, then it may give rise to inconsistency of the database. • Serializable Schedules- If a given schedule of ‘n’ transactions is found to be equivalent to some serial schedule of ‘n’ transactions, then it is called as a serializable schedule.
- 11. Serializability Continue.. 1. Properties of Serializable Schedules- Serializable schedules behave exactly same as serial schedules. So, they are always- Consistent Recoverable Casacadeless Strict 2. Difference between Serial Schedules and Serializable Schedules- The only difference between serial schedules and serializable schedules is that- In serial schedules, only one transaction is allowed to execute at a time i.e. no concurrency is allowed. Whereas in serializable schedules, multiple transactions can execute simultaneously i.e. concurrency is allowed.
- 12. Types of Serializability Serializability is mainly of two types- 1. Conflict Serializability 2. View Serializability Figure : Types of serializability
- 13. Conflict Serializability If a given schedule can be converted into a serial schedule by swapping its non-conflicting operations, then it is called as a conflict serializable schedule. • What are conflicting operations? Two operations are called as conflicting operations if all the following conditions hold true for them- – Both the operations belong to different transactions. – Both the operations are on same data item – At least one of the two operations is a write operation
- 14. Conflict Serializability Example- Consider the following schedule- In this schedule, W1 (A) and R2 (A) are called as conflicting operations because all the above conditions hold true for them.
- 15. Checking of conflict serializable schedule 1) Step-01: Find and list all the conflicting operations. 2) Step-02: Start creating a precedence graph by drawing one node for each transaction. 3) Step-03: Draw an edge for each conflict pair such that if Xi (V) and Yj (V) forms a conflict pair then draw an edge from Ti to Tj which ensures that Ti gets executed before Tj. 4) Step-04: Check if there is any cycle formed in the graph. If there is no cycle found, then the schedule is conflict serializable otherwise not.
- 16. View Serializability- If a given schedule is found to be view equivalent to some serial schedule, then it is called as a view serializable schedule. What are view equivalent schedules? • Consider two schedules S1 and S2 each consisting of two transactions T1 and T2. Schedules S1 and S2 are called view equivalent if the following three conditions hold true for them- Condition-01: If transaction Ti reads a data item X from the database initially in schedule S1, then in schedule S2 also, Ti must perform the initial read of the data item X from the database. The same has to be true for all the data items.
- 17. View Serializability- Thumb rule “Initial reads must be same for all data items”. Condition-02: • If transaction Ti reads a data item that has been updated by the transaction Tj in schedule S1, then in schedule S2 also, transaction Ti must read the same data item that has been updated by transaction Tj. Thumb rule “Write-read sequence must be same.”.
- 18. View Serializability- Condition-03: • If data item X has been updated at last by transaction Ti in schedule S1, then in schedule S2 also, the data item X must be updated at last by transaction Ti • The same has to be true for all the data items. Thumb rule “Final writers must be same for all data items”. How to check whether a given schedule is view serializable or not? Method-01: Check whether the given schedule is conflict serializable or not. • If the given schedule is conflict serializable, then it is surely view serializable. Stop and report your answer.
- 19. Continue.. If the given schedule is not conflict serializable, then it may or may not be view serializable. Go and check using other methods. Thumb rule All conflict serializable schedules are view serializable but all view serializable schedules may or may not be conflict serializable. Method-02: Check if there exists any blind write operation (writing without reading a value is known as a blind write). • If there does not exist any blind write, then the schedule is surely not view serializable. Stop and report your answer.
- 20. Continue.. • If there exists any blind write, then the schedule may or may not be view serializable. Go and check using other methods. Thumb rule No blind write means not a view serializable schedule. Method-03: • In this method, try finding a view equivalent serial schedule. • By using the three conditions mentioned above, write all the dependencies and then draw a graph using those dependencies. If there exists no cycle, then the schedule is view serializable otherwise not.
- 21. Deadlock • In a database, a deadlock is an unwanted situation in which two or more transactions are waiting indefinitely for one another to give up locks. • Deadlock is said to be one of the most feared complications in DBMS as it brings the whole system to a Halt. • Example – let us understand the concept of Deadlock with an example : Suppose, Transaction T1 holds a lock on some rows in the Students table and needs to update some rows in the Grades table. Simultaneously, Transaction T2 holds locks on those very rows (Which T1 needs to update) in the Grades table but needs to update the rows in the Student table held by Transaction T1.
- 22. Deadlock
- 23. Deadlock Avoidance • When a database is stuck in a deadlock, It is always better to avoid the deadlock rather than restarting or aborting the database. Deadlock avoidance method is suitable for smaller database whereas deadlock prevention method is suitable for larger database. • One method of avoiding deadlock is using application consistent logic. In the above given example, Transactions that access Students and Grades should always access the tables in the same order. In this way, in the scenario described above, Transaction T1 simply waits for transaction T2 to release the lock on Grades before it begins. When transaction T2 releases the lock, Transaction T1 can proceed freely. • Another method for avoiding deadlock is to apply both row level locking mechanism and READ COMMITTED isolation level. However, It does not guarantee to remove deadlocks completely.
- 24. Deadlock Detection • Deadlock Detection – When a transaction waits indefinitely to obtain a lock, The database management system should detect whether the transaction is involved in a deadlock or not. • Wait-for-graph is one of the methods for detecting the deadlock situation. This method is suitable for smaller database. In this method a graph is drawn based on the transaction and their lock on the resource. If the graph created has a closed loop or a cycle, then there is a deadlock. • For Example: When a transaction Ti requests for a lock on an item, say X, which is held by some other transaction Tj, a directed edge is created from Ti to Tj. If Tj releases item X, the edge between them is dropped and Ti locks the data item.
- 25. Wait-for Graph
- 26. Deadlock Prevention To prevent any deadlock situation in the system, the DBMS aggressively inspects all the operations, where transactions are about to execute. The DBMS inspects the operations and analyzes if they can create a deadlock situation. If it finds that a deadlock situation might occur, then that transaction is never allowed to be executed. • There are deadlock prevention schemes that use timestamp ordering mechanism of transactions in order to predetermine a deadlock situation.
- 27. Deadlock Prevention 1. Wound-Wait Scheme • In this scheme, if a transaction requests to lock a resource (data item), which is already held with conflicting lock by some another transaction, one of the two possibilities may occur − • If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back − that is Ti wounds Tj. Tj is restarted later with a random delay but with the same timestamp. • If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource is available. Note: This scheme, allows the younger transaction to wait; but when an older transaction requests an item held by a younger one, the older transaction forces the younger one to abort and release the item.
- 28. Deadlock Prevention 2. Wait-Die Scheme • In this scheme, if a transaction requests to lock a resource (data item), which is already held with a conflicting lock by another transaction, then one of the two possibilities may occur − • If TS(Ti) < TS(Tj) − that is Ti, which is requesting a conflicting lock, is older than Tj − then Ti is allowed to wait until the data-item is available. • If TS(Ti) > TS(tj) − that is Ti is younger than Tj − then Tidies. Ti is restarted later with a random delay but with the same timestamp. Note: This scheme allows the older transaction to wait but kills the younger one.