Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 92 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
92
Dung lượng
2,51 MB
Nội dung
Ho Chi Minh City University of Technology Faculty of Computer Science and Engineering Chapter 5: Introduction to Transaction Processing Concepts and Theory Database Management Systems (CO3021) Computer Science Program Dr Võ Thị Ngọc Châu (chauvtn@hcmut.edu.vn) Semester – 2020-2021 Course outline Chapter Overall Introduction to Database Management Systems Chapter Disk Storage and Basic File Structures Chapter Indexing Structures for Files Chapter Query Processing and Optimization Chapter Introduction to Transaction Processing Concepts and Theory Chapter Concurrency Control Techniques Chapter Database Recovery Techniques References [1] R Elmasri, S R Navathe, Fundamentals of Database Systems- 6th Edition, Pearson- Addison Wesley, 2011 R Elmasri, S R Navathe, Fundamentals of Database Systems- 7th Edition, Pearson, 2016 [2] H G Molina, J D Ullman, J Widom, Database System Implementation, Prentice-Hall, 2000 [3] H G Molina, J D Ullman, J Widom, Database Systems: The Complete Book, Prentice-Hall, 2002 [4] A Silberschatz, H F Korth, S Sudarshan, Database System Concepts –3rd Edition, McGraw-Hill, 1999 [Internet] … Content 5.1 Introduction to Transaction Processing 5.2 Transaction and System Concepts 5.3 Desirable Properties of Transactions 5.4 Characterizing Schedules based on Recoverability 5.5 Characterizing Schedules based on Serializability 5.6 Transaction Support in SQL 5.1 Introduction to Transaction Processing Transaction processing systems are systems with large databases and hundreds of concurrent users executing database transactions High availability and fast response time for hundreds of concurrent users Examples: airline reservations, banking, credit card processing, online retail purchasing, stock markets, supermarket checkouts, etc the concept of a transaction, which is used to represent a logical unit of database processing that must be completed in its entirety to ensure correctness 5.1 Introduction to Transaction Processing Single-user vs multi-user database systems Concurrent execution of transactions in a multiuser system Recovery from transaction failures when transactions fail while executing The number of users who can use the system concurrently-that is, at the same time Single-user if at most one user at a time can use the system Multiuser if many users can use the system - and hence access the database - concurrently 5.1 Introduction to Transaction Processing Interleaved processing versus parallel processing of concurrent transactions Figure 20.1, [1], pp 747 Concurrent execution of processes is actually interleaved Interleaving keeps the CPU busy when a process requires an input or output (I/O) operation, such as reading a block from disk The CPU is switched to execute another process rather than remaining idle during I/O time Interleaving also prevents a long process from delaying other processes If the computer system has multiple hardware processors (CPUs), parallel processing of multiple processes is possible 5.1 Introduction to Transaction Processing A Transaction: logical unit of database processing that includes one or more database access operations (read – retrieval, write – insert, update, delete) Typically implemented by a computer program that includes database commands The database operations that form a transaction can either be embedded within an application program or they can be specified interactively via a high-level query language such as SQL Transaction boundaries: Begin and End transaction statements An application program may contain several transactions separated by the transaction boundaries 5.1 Introduction to Transaction Processing SIMPLE MODEL OF A DATABASE (for purposes of discussing transactions): A database - collection of named data items Granularity of data - a field, a record , or a whole disk block (Concepts are independent of granularity) Basic operations are read and write read_item(X): Reads a database item named X into a program variable To simplify our notation, we assume that the program variable is also named X write_item(X): Writes the value of program variable X into the database item named X 5.1 Introduction to Transaction Processing READ AND WRITE OPERATIONS: Basic unit of data transfer from the disk to the computer main memory is one block In general, a data item (what is read or written) will be the field of some record in the database, although it may be a larger unit such as a record or even a whole block read_item(X) command includes the following steps: Find the address of the disk block that contains item X Copy that disk block into a buffer in main memory (if that disk block is not already in some main memory buffer) Copy item X from the buffer to the program variable named X 10 5.6 Transaction Support in SQL Potential problem with lower isolation levels: Dirty Read: Reading a value that was written by a transaction which failed Nonrepeatable Read: Allowing another transaction to write a new value between multiple reads of one transaction A transaction T1 may read a given value from a table If another transaction T2 later updates that value and T1 reads that value again, T1 will see a different value Consider that T1 reads the employee salary for Smith Next, T2 updates the salary for Smith If T1 reads Smith's salary again, then it will see a different value for Smith's salary 78 5.6 Transaction Support in SQL Potential problem with lower isolation levels: Phantoms: New rows being read using the same read with a condition A transaction T1 may read a set of rows from a table, perhaps based on some condition specified in the SQL WHERE clause Now suppose that a transaction T2 inserts a new row that also satisfies the WHERE clause condition of T1, into the table used by T1 If T1 is repeated, then T1 will see a row that previously did not exist, called a phantom 79 5.6 Transaction Support in SQL Sample SQL transaction: EXEC SQL whenever sqlerror go to UNDO; EXEC SQL SET TRANSACTION READ WRITE DIAGNOSTICS SIZE ISOLATION LEVEL SERIALIZABLE; EXEC SQL INSERT INTO EMPLOYEE (FNAME, LNAME, SSN, DNO, SALARY) VALUES ('Robert','Smith','991004321',2,35000); EXEC SQL UPDATE EMPLOYEE SET SALARY = SALARY * 1.1 WHERE DNO = 2; EXEC SQL COMMIT; GOTO THE_END; UNDO: EXEC SQL ROLLBACK; THE_END: 80 5.6 Transaction Support in SQL [1], pp 775 81 5.6 Transaction Support in DBMSs with SQL A transaction in Oracle a logical, atomic unit of work with one or more SQL statements Oracle Database assigns every transaction a unique identifier called a transaction ID All Oracle transactions obey the basic properties of a database transaction, ACID Statement-level atomicity: a SQL statement is an atomic unit of work and either completely succeeds or completely fails A single SQL statement executes successfully if the database parses and runs it without error as an atomic unit, as when all rows are changed in a multirow update If a SQL statement causes an error during execution, then it is not successful and so all effects of the statement are rolled back This operation is a statement-level rollback Source: Oracle 19c 82 5.6 Transaction Support in DBMSs with SQL System Change Numbers (SCNs) A system change number (SCN) is a logical, internal time stamp used by Oracle Database SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction Oracle Database uses SCNs to mark the SCN before which all changes are known to be on disk so that recovery avoids applying unnecessary redo The database also uses SCNs to mark the point at which no redo exists for a set of data so that recovery can stop Every transaction has an SCN Modifications in this transaction have the same SCN When a transaction commits, the database records an SCN for this commit Oracle Database increments SCNs in the system global area (SGA) When a transaction modifies data, the database writes a new SCN to the undo data segment assigned to the transaction The log writer process then writes the commit record of the transaction immediately to the online redo log The commit record has the unique SCN of the transaction Oracle Database also uses SCNs as part of its instance recovery and media recovery mechanisms Source: Oracle 19c 83 5.6 Transaction Support in DBMSs with SQL Transaction control statements in Oracle The COMMIT statement ends the current transaction and makes all changes performed in the transaction permanent COMMIT also erases all savepoints in the transaction and releases transaction locks The ROLLBACK statement reverses the work done in the current transaction; it causes all data changes since the last COMMIT or ROLLBACK to be discarded The ROLLBACK TO SAVEPOINT statement undoes the changes since the last savepoint but does not end the entire transaction The SAVEPOINT statement identifies a point in a transaction to which you can later roll back Source: Oracle 19c 84 5.6 Transaction Support in DBMSs with SQL Oracle Database Transaction Isolation Levels Read Committed Isolation Level (default) Serializable Isolation Level Every query executed by a transaction sees only data committed before the query—not the transaction—began A transaction sees only changes committed at the time the transaction—not the query—began and changes made by the transaction itself A serializable transaction operates in an environment that makes it appear as if no other users were modifying data in the database Read-Only Isolation Level similar to the serializable isolation level, but read-only transactions not permit data to be modified in the transaction unless the user is SYS Source: Oracle 19c 85 Summary Single-user vs multiuser systems Problems with uncontrolled execution of concurrency in multiuser systems: Lost update, temporary read, incorrect summary, non-repeatable read, phantom Failures & recovery issues & the system log Transaction: a logical unit of database processing (read, write) ACID properties Commit point 86 Summary Schedule (or history) as an execution sequence of the operations of several transactions with interleaving characterized schedules in terms of their recoverability Recoverable, Cascadeless, Strict Non-recoverable characterized schedules in terms of their serializability Conflict-serializable Precedence graph for testing its conflict-serializability Transaction support in SQL: isolation levels 87 Chapter 5: Introduction to Transaction Processing Concepts and Theory 88 Check for Understandings 5.1 Differentiate multiuser systems from single-user systems Give their examples 5.2 Describe different types of failures and give their examples 5.3 What is a transaction? Give examples 5.4 Discuss the ACID properties of a transaction 5.5 What is a system log? What records are stored in the log? Write the content of the log for your transactions in 4.3 5.6 What is a commit point? Give an example 89 Check for Understandings 5.7 What is a schedule? Give an example 5.8 Given the following transactions: T1: r1(X); r1(Z); w1(X); c1; T2: r2(Z); r2(Y); w2(Z); w2(Y); c2; T3: r3(X); r3(Y); w3(Y); c3; What are valid schedules? Write their log contents S1: r1(X); r1(Z); r3(X); r3(Y); w1(X); w3(Y); c1; c3; S2: r2(Z); r3(X); r2(Y); r3(Y); w2(Z); w3(Y); w2(Y); a3; c2; S3: r2(Z); r1(X); r1(Z); w2(Z); w1(X); r2(Y); w2(Y); c2; c1; S4: r1(X); r3(Y); r1(Z); w3(Y); w1(X); c1; r3(X); c3; 90 Check for Understandings 5.9 What are recoverable schedules? What are cascadeless schedules? What are strict schedules? 5.10 What is the recoverability characteristic of each following schedule? S5: r1(X); r2(Z); r1(Z); r3(X); r3(Y); w1(X); c1; w3(Y); c3; r2(Y); w2(Z); w2(Y); c2; S6: r1(X); r2(Z); r1(Z); r3(X); r3(Y); w1(X); w3(Y); r2(Y); w2(Z); w2(Y); c1; c2; c3; S7: r1(X); r2(Z); r3(X); r1(Z); r2(Y); r3(Y); w1(X); c1; w2(Z); w3(Y); w2(Y); c3; c2; S8: r1(A); r2(B); w1(B); c1; w2(C); c2; r3(B); r3(C); w3(D); c3; S9: r1(A); w1(B); c1; r2(B); w2(C); c2; r3(C); w3(D); c3; S10: r2(A); r3(A); r1(A); w1(B); c1; r2(B); r3(B); w2(C); c2; r3(C); c3; S11: r2(A); r3(A); r1(A); w1(B); r3(B); w2(C); r3(C); a1; a2; a3; 91 Check for Understandings 5.11 What are conflict-serializable schedules? 5.12 What is the conflict-serializable characteristic of each following schedule? Draw their precedence graphs Determine their equivalent serial schedules S12: r1(X); r3(X); w1(X); r2(X); w3(X); S13: r1(X); r3(X); w3(X); w1(X); r2(X); S14: r3(X); r2(X); w3(X); r1(X); w1(X); S15: r3(X); r2(X); r1(X); w3(X); w1(X); S16: r1(X); r2(Z); r1(Z); r3(X); r3(Y); w1(X); w3(Y); r2(Y); w2(Z); w2(Y); S17: r1(X); r2(Z); r3(X); r1(Z); r2(Y); r3(Y); w1(X); w2(Z); w3(Y); w2(Y); S18: r2(X); r1(X); r3(Y); w3(Y); r1(Y); w2(X); w1(X); w1(Y); S19: r1(Z); r1(X): r2(Y); w2(Y); r3(X); r2(Z); w1(Z); w1(X); r2(X); w3(X); w2(X); S20: r1(X); w1(X); r2(Y); r2(X); w2(Y); r1(Y); w2(X); r3(Y); w1(Y); r3(X); w3(X); w2(Y); w3(Y); 92