Database Tuning Outline What Is a Transaction?1 ACID Properties
Total Page：16
File Type：pdf, Size：1020Kb
Concurrency Tuning Introduction to Transactions Outline Database Tuning Concurrency Tuning 1 Concurrency Tuning Nikolaus Augsten Introduction to Transactions Lock Tuning University of Salzburg Weaken Isolation Guarantees Department of Computer Science Database Group Transaction Chopping Unit 4 – WS 2015/16 Adapted from “Database Tuning” by Dennis Shasha and Philippe Bonnet. Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 1 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 2 / 74 Concurrency Tuning Introduction to Transactions Concurrency Tuning Introduction to Transactions What is a Transaction?1 ACID Properties A transaction is a unit of program execution that accesses and possibly updates various data items. Example: transfer $50 from account A to account B Database system must guarantee ACID for transactions: 1. R(A) Atomicity: either all operations of the transaction are executed or none 2. A A 50 Consistency: execution of a transaction in isolation preserves the ← − 3. W (A) consistency of the database 4. R(B) Isolation: although multiple transactions may execute concurrently, 5. B B + 50 each transaction must be unaware of the other concurrent transactions. ← 6. W (B) Durability: After a transaction completes successfully, changes to the Two main issues: database persist even in case of system failure. 1. concurrent execution of multiple transactions 2. failures of various kind (e.g., hardware failure, system crash) 1 Slides of section “Introduction to Transactions” are adapted from the slides “Database System Concepts”, 6th Ed., Silberschatz, Korth, and Sudarshan Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 3 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 4 / 74 Concurrency Tuning Introduction to Transactions Concurrency Tuning Introduction to Transactions Atomicity Consistency Example: transfer $50 from account A to account B Example: transfer $50 from account A to account B 1. R(A) 2. A A 50 1. R(A) ← − 2. A A 50 3. W (A) 3. W←(A) − 4. R(B) 5. B B + 50 4. R(B) ← 5. B B + 50 6. W (B) 6. W←(B) Consistency in example: sum A + B must be unchanged What if failure (hardware or software) after step 3? Consistency in general: money is lost explicit integrity constraints (e.g., foreign key) database is inconsistent implicit integrity constraints (e.g., sum of all account balances of a Atomicity: bank branch must be equal to branch balance) either all operations or none Transaction: updates of partially executed transactions not reflected in database must see consistent database during transaction inconsistent state allowed after completion database must be consistent again Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 5 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 6 / 74 Concurrency Tuning Introduction to Transactions Concurrency Tuning Introduction to Transactions Isolation – Motivating Example Isolation Trivial isolation: run transactions serially Example: transfer $50 from account A to account B Isolation for concurrent transactions: For every pair of transactions Ti 1. R(A) and Tj , it appears to Ti as if either Tj finished execution before Ti 2. A A 50 started or T started execution after T finished. 3. W←(A) − j i 4. R(B) Schedule: 5. B B + 50 specifies the chronological order of a sequence of instructions from 6. W←(B) various transactions Imagine second transaction T : equivalent schedules result in identical databases if they start with 2 identical databases T : R(A), R(B), print(A + B) 2 Serializable schedule: T2 is executed between steps 3 and 4 T2 sees an inconsistent database and gives wrong result equivalent to some serial schedule serializable schedule of T 1 and T 2 is either equivalent to T 1, T 2 or T 2, T 1 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 7 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 8 / 74 Concurrency Tuning Introduction to Transactions Concurrency Tuning Introduction to Transactions Durability Locks When a transaction is done it commits. Example: transaction commits too early A lock is a mechanism to control concurrency on a data item. transaction writes A, then commits Two types of locks on a data item A: A is written to the disk buffer exclusive– xL(A): data item A can be both read and written then system crashes shared– sL(A): data item A can only be read. value of A is lost Lock request are made to concurrency control manager. Durability: After a transaction has committed, the changes to the database persist even in case of system failure. Transaction is blocked until lock is granted. Commit only after all changes are permanent: Unlock A – uL(A): release the lock on a data item A either written to log file or directly to database database must recover in case of a crash Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 9 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 10 / 74 Concurrency Tuning Introduction to Transactions Concurrency Tuning Introduction to Transactions Lock Compatibility Locking Protocol Lock compatibility matrix: Example transaction T2 with locking: T1 T2 shared exclusive ↓ → 1. sL(A), R(A), uL(A) shared true false 2. sL(B), R(B), uL(B) exclusive false false 3. print(A + B) T1 holds shared lock on A: T2 uses locking, but is not serializable shared lock is granted to T2 A and/or B could be updated between steps 1 and 2 exclusive lock is not granted to T2 printed sum may be wrong T2 holds exclusive lock on A: Locking protocol: shared lock is not granted to T2 set of rules followed by all transactions while requesting/releasing locks exclusive lock is not granted to T2 locking protocol restricts the set of possible schedules Shared locks can be shared by any number of transactions. Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 11 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 12 / 74 Concurrency Tuning Introduction to Transactions Concurrency Tuning Introduction to Transactions Pitfalls of Locking Protocols – Deadlock Pitfalls of Locking Protocols – Starvation Example: two concurrent money transfers T : R(A), A A + 10, R(B), B B 10, W (A), W (B) 1 ← ← − Starvation: transaction continues to wait for lock T2: R(B), B B + 50, R(A), A A 50, W (A), W (B) possible concurrent← scenario with← locks:− Examples: T1.xL(A), T1.R(A), T2.xL(B), T2.R(B), T2.xL(A), T1.xL(B),... the same transaction is repeatedly rolled back due to deadlocks T1 and T2 block each other – no progress possible a transaction continues to wait for an exclusive lock on an item while a Deadlock: situation when transactions block each other sequence of other transactions are granted shared locks Handling deadlocks: Well-designed concurrency manager avoids starvation. one of the transactions must be rolled back (i.e., undone) rolled back transaction releases locks Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 13 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 14 / 74 Concurrency Tuning Introduction to Transactions Concurrency Tuning Introduction to Transactions Two-Phase Locking Two-Phase Locking – Example Example: two concurrent money transfers Protocol that guarantees serializability. T1: R(A), A A + 10, R(B), B B 10, W (A), W (B) Phase 1: growing phase T : R(A), A ← A 50, R(B), B ← B +− 50, W (A), W (B) 2 ← − ← transaction may obtain locks Possible two-phase locking schedule: transaction may not release locks 1. T : xL(A), xL(B), R(A), R(B), W (A A + 10), uL(A) 1 ← Phase 2: shrinking phase 2. T2 : xL(A), R(A), xL(B) (wait) transaction may release locks 3. T1 : W (B B 10), uL(B) 4. T : R(B),←W (A− A 50), W (B B + 50), uL(A), uL(B) transaction may not obtain locks 2 ← − ← Equivalent serial schedule: T1, T2 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 15 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 16 / 74 Concurrency Tuning Lock Tuning Concurrency Tuning Lock Tuning Outline Concurrency Tuning Goals Performance goals: reduce blocking (one transaction waits for another to release its locks) 1 Concurrency Tuning avoid deadlocks and rollbacks Introduction to Transactions Correctness goals: Lock Tuning serializability: each transaction appears to execute in isolation Weaken Isolation Guarantees note: correctness of serial execution must be ensured by the Transaction Chopping programmer! Trade-off between performance and correctness! Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 17 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 18 / 74 Concurrency Tuning Lock Tuning Concurrency Tuning Lock Tuning Ideal Transaction Lock Tuning Acquires few locks. Favors shared locks over exclusive locks. 1. Eliminate unnecessary locks only exclusive locks create conflicts 2. Control granularity of locking Acquires locks with fine granularity. 3. Circumvent hot spots granularities: table, page, row 4. Isolation guarantees and snapshot isolation reduces the scope of each conflict 5. Split long transactions Holds locks for a short time. reduce waiting time Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 19 / 74 Nikolaus Augsten (DIS) DBT – Concurrency Tuning Unit 4 – WS 2015/16 20 / 74 Concurrency Tuning Lock Tuning Concurrency Tuning Lock Tuning 1. Eliminate Unnecessary Locks 2. Control Granularity of Locking Locks can be defined at different granularities: row-level locking (also: record-level locking)