Università degli Studi di Roma Tor Vergata Database ICT and Internet Engineering Instructor: Andrea Giglio andrea.giglio@uniroma2.it 1
Concurrency Concurrent execution of user programs is essential for good DBMS performance. Because disk accesses are frequent, and relatively slow, it is important to keep the cpu humming by working on several user programs concurrently. Interleaving actions of different user programs can lead to inconsistency. DBMS ensures such problems don t arise: users can pretend they are using a single-user system. 2
Concurrency A multiuser DBMS should allow multiple users to simultaneously access the database essential if data for multiple applications need to be integrated and maintained in a single database The DBMS must contain software for concurrency control ensuring that multiple users who are trying to update the same data can do it in a controlled manner, so that the result of the updates is correct A key function is to ensure that concurrent transactions are operating properly 3
Transaction Key concept is transaction, which is an atomic sequence of database actions (reads/writes). Each transaction, executed completely, must leave the DB in a consistent state if DB is consistent when the transaction begins. Users can specify some simple integrity constraints on the data, and the DBMS will enforce these constraints. Beyond this, the DBMS does not really understand the semantics of the data. (e.g., it does not understand how the interest on a bank account is computed). Thus, ensuring that a transaction (run alone) preserves consistency is ultimately the user s responsibility! 4
Transaction Example: start transaction select balance from Account where Account_Number='9001'; select balance from Account where Account_Number='9002'; update Account set balance=balance-900 where Account_Number='9001' ; update Account set balance=balance+900 where Account_Number='9002' ; commit; //if all sql queries succed rollback; //if any of sql queries failed or error 5
Concurrent Transactions DBMS ensures that execution of {T1,..., Tn} is equivalent to some serial execution T1... Tn. Before reading/writing an object, a transaction requests a lock on the object, and waits till the DBMS gives it the lock. All locks are released at the end of the transaction. (Strict 2PL locking protocol.) Idea: If an action of Ti (say, writing X) affects Tj (which perhaps reads X), one of them, say Ti, will obtain the lock on X first and Tj is forced to wait until Ti completes; this effectively orders the transactions. What if Tj already has a lock on Y and Ti later requests a lock on Y? (Deadlock!) Ti or Tj is aborted and restarted! 6
Concurrent Transactions Strict 2PL locking protocol: Each transaction is executed in 2 phases Growing Phase: the transaction obtains locks Shrinking Phase: the transaction releases locks 7
Concurrent Transactions Deadlock Example: 8
Concurrent Transactions Deadlock Example: 9
Integrity constraints Many databases applications offer the possibility of defining integrity constraints on data The simplest form of constraint is the assignment of a type to a field, which specifies the characteristics Integer String Date/Time The DBMS is responsible for determining that such constraints are respected 10
Backup & Crash Recovery A DBMS must provide mechanisms for data backup and recovery: Backup: data is stored on optical media, such as CDs and DVDs, or on magnetic tapes or external drives Recovery: in the event database crash, data is restored to a stable and consistent situation as previously stored 11
Backup Example (Cpanel) 12
Restore Example (cmd) 13
Atomicity DBMS ensures atomicity (all-or-nothing property) even if system crashes in the middle of a transaction. Idea: Keep a log (history) of all actions carried out by the DBMS while executing a set of transactions: Before a change is made to the database, the corresponding log entry is forced to a safe location. (WAL protocol; OS support for this is often inadequate.) After a crash, the effects of partially executed transactions are undone using the log. (Thanks to WAL, if log entry wasn t saved before the crash, corresponding change was not applied to database!) 14
The Log The following actions are recorded in the log: Ti writes an object: the old value and the new value. Log record must go to disk before the changed page! Ti commits/aborts: a log record indicating this action. Log records chained together by Xact id, so it s easy to undo a specific Xact (e.g., to resolve a deadlock). Log is often duplexed and archived on stable storage. All log related activities (and in fact, all CC related activities such as lock/unlock, dealing with deadlocks etc.) are handled transparently by the DBMS. 15
The Log This example transaction log shows interleaved operations from multiple simultaneous transactions. Source: http://rusanu.com/2014/03/10/how-to-read-and-interpret-the-sql-server-log/ 16
DBMS Structure 17
People who work with databases DBA (DataBase Administrator) responsibile for designing and maintaining the database Design of the Conceptual and Physical Schemas Security and Authorization Data Availability and Recovery from Failures Database Tuning DB application programmers Programmers who realize applications interacting with a DBMS End Users Sophisticated users use these applications to access stored data Unsophisticated users performing data access operations using an interactive language or graphical interfaces 18
End User Example 1 The user is interacting with a web-form 19
End User Example 2 The user is sending SQL commands using a query browser 20
The lecture notes have incorporated course materials developed by Jeffrey Ullman and Jennifer Widom ( A First Course in Database Systems book) and Johannes Gehrke and Raghu Ramakrishnan («Database Management Systems» book) 21