Hands-on Experiments for a Database Course: Transaction Isolation Levels in SQL

Transcription

1 224 Int'l Conf. Frontiers in Education: CS and CE FECS'18 Hands-on Experiments for a Database Course: Transaction Isolation Levels in SQL Jamal Alsabbagh School of Computing and Information Systems Grand Valley State University, Allendale, Michigan, USA Abstract Concurrency control is one of the key services offered by database management systems in order to coordinate the reads and updates performed by the different SQL transactions that may be active simultaneously. While standard database textbooks discuss the concepts and terminology related to the topic, they lack specific hands-on examples. This paper is intended to serve as a complement to textbook discussions. It presents a number of command files that students can actually run and interpret and thereby reinforce their learning of the topic. Furthermore, database teachers can use the presented examples as templates for designing their own lab exercises and exam questions. Keywords: Database. Concurrency control. SQL transactions. Teaching tools. 1 Introduction Concurrency control among simultaneously active SQL transactions is one of the key services offered by database management systems. Therefore, the topic is covered to varying degrees of details in database courses. However, while standard database textbooks such as [1, 2, 4, and 5] cover the topic quite well at the concepts and terminology level, they lack actual hands-on examples needed to reinforce students learning. This paper bridges the gap by presenting examples that students can actually run and interpret. The examples use oracle 12c but can be easily ported to other systems. Furthermore, database teachers can use the examples as templates for designing their own lab exercises and/or exam questions. This paper is intended to serve as a useful practical complement to textbook coverage rather than being a tutorial on concurrency control. Therefore, it assumes that students have at least covered the following topics in the course prior to running the examples presented here: In order to increase system throughput and reduce transaction response time, the database system executes the transactions in an interleaved rather than serial fashion. Each possible interleaving is called a schedule. Anomalies that can occur due to interleaved execution are: dirty reads, unrepeatable reads, and the phantom problem. The SQL standard recognizes four different isolation levels; they are: read uncommitted, read committed, repeatable read, and serializable. The levels differ in terms of which anomalies they allow to manifest whereby read uncommitted provides the least isolation and allows all of the three abovementioned anomalies while serializable provides the strongest isolation and thus disallows all the anomalies. In order to enhance the level of concurrency, and based upon application semantics, the application developer may set a transaction s isolation level to one that tolerates one or more of the above anomalies. In other words, the ACID (Atomicity, Consistency, Isolation, and Durability) properties of transactions can be relaxed for certain transactions. Transactions do not communicate directly with one another. Rather, it is the responsibility of the concurrency control subsystem to govern the interactions among concurrent transactions. The examples in this paper were developed and run under oracle 12c which does not allow dirty reads [3]. More specifically, a transaction s isolation level in oracle can be set to either serializable or read committed. (Two other levels that oracle allows, but not discussed in this paper, due to space limitations are read only and read write.) The remainder of this paper is organized as follows. Section 2 describes the setup for running the examples and the naming conventions used for naming the various command files used in subsequent sections. Section 3 presents an example to demonstrate that a serializable transaction is immune from the dirty read, unrepeatable read, and the phantom anomalies. Section 4 presents an example to demonstrate that if a transaction T2 tries to update data that has been updated by a still active serializable transaction T1 then the system will block T2 until T1 commits. Section 5 presents an example to

2 Int'l Conf. Frontiers in Education: CS and CE FECS' demonstrate that a read committed transaction can be susceptible to the unrepeatable read and the phantom anomalies. Finally, section 6 concludes the paper. 2 Setup and naming conventions The examples presented in this paper were run using oracle 12c under Linux. In order to run the examples, the following preparatory tasks need to be performed first: 1. Connect to oracle s sqlplus using two different user accounts. The two accounts used in this paper are called session1 and session2. 2. In the directory of user session1, create a text file called create.sql that contains the code depicted in figure 1. It needs to be run as a command file (i.e. script) by user session1 at the beginning of every example in order to create a test database containing two rows and then granting privileges to user session2 on the test database: -- create DB and grant privileges SET ECHO ON DROP TABLE Item; CREATE TABLE Item ( id INT PRIMARY KEY, type CHAR, price INT); INSERT INTO Item VALUES(1, 'A', 10); INSERT INTO Item VALUES(3, 'B', 30); GRANT SELECT, UPDATE, INSERT ON Item TO session2; Figure 1: Command file to create the sample database 3. Create the following four text command files in the directory of user session1: e1s1.sql, e2s1.sql, and e3s1.sql that are listed in the left columns in figures 2, 4, and Create the following text command files in the directory of user session2: e1s2.sql, e2s2.sql, and e3s2.sql that are listed in the right columns in figures 2, 4, and 6. As a naming convention in this paper, the command files in steps 3 and 4 above, are named e<n>s<m>.sql where n is either 1, 2, or 3 to indicate whether the file is used in experiment-1, experiment-2, or experiment-3. Also m is either 1 or 2 to indicate whether the command file will be run in session1 or session2. Furthermore, the transactions within a command file are named e<n>s<m>tx<k> where k is the transaction number in the command file e<n>s<m>. 3 Example-1: Serializability This example demonstrate that an active serializable transaction is immune from the dirty read, unrepeatable read, and phantom anomalies. Figure 2 shows the two command files e1s1.sql and e1s2.sql used to run this example. In order to run example-1, one needs to perform the following tasks: 1. In session1, run the sqlplus in order to create the initial database instance. 2. In session1, run the sqlplus 3. In session2, run the sqlplus 4. Follow the prompts that will appear in both sessions asking for which session to resume and when. (Resuming a session simply requires pressing the ENTER key in the session.) Command file e1s1.sql ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE; -- transaction: e1s1tx1 PAUSE +++A1+++ resume session2 UPDATE Item SET price = price + 5 WHERE id=1; INSERT INTO item VALUES (5, 'B', 50); PAUSE +++B1+++ resume session2 Command file e1s2.sql ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE; -- transaction: e1s2tx1 PAUSE +++A2+++ resume session1 PAUSE +++B2+++ resume session1 PAUSE +++C2+++ press ENTER to continue -- transaction: e1s2tx2 Figure 2: The command files for experiment-1

3 226 Int'l Conf. Frontiers in Education: CS and CE FECS'18 Now due to the placement of the PAUSE commands in the command files e1s1.sql and e1s2.sql, the system will execute the concurrent schedule depicted in figure 3. The leftmost column in the figure indicates the steps (i.e. sequence) in which the system executes the SQL commands in the two sessions. Furthermore, the output from the two sessions is staggered across the two other columns for clarity. As can be seen in figure 3, session1 contains one transaction e1s1tx1 (which begins at step 2 and commits at step 13) while session2 contains the two transactions e1s2tx1 (which begins at step 5 and commits at step 15), and transaction e1s2tx2 (which begins at step 17 and commits at step 18.) step Session1 (e1s1.sql) serializable Session2 (e1s2.sql) serializable 1 ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE; -- transaction: e1s1tx1 2 3 PAUSE +++A1+++ start session2 4 ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE; -- transaction: e1s2tx1 5 6 PAUSE +++A2+++ resume session1 7 UPDATE Item SET price = price + 5 WHERE id=1; 8 INSERT INTO item VALUES (5, 'B', 50); 9 10 PAUSE +++B1+++ resume session PAUSE +++B2+++ resume session e1s1tx e1s2tx1 16 PAUSE +++C2+++ press ENTER to continue -- transaction: e1s2tx e1s2tx2 Figure 3: The concurrent schedule in Experiment-1

4 Int'l Conf. Frontiers in Education: CS and CE FECS' Steps 1 through 6 simply set the isolation levels to serializable, inspect the initial database and then pause the transactions. In step 7, session1 resumes and updates the price of Item(1,A,10) to Item(1,A,15). It then continues to step 8 where it inserts a new row Item(5,B,50), inspects the database in step 9 and then pauses in step 10. As expected, step 9 shows that session1, while still active, does see its own update and insert in the database. In step 11, session2 resumes whereby it inspects the database and, being serializable, it does not see the update or the insert by the yet uncommitted transaction e1s1tx1 of session1 since these are, respectively, a dirty read and a phantom as far as transaction e1s2tx1 of session2 is concerned. In fact, even after e1s1tx1 commits in step 13, e1s2tx1 still doesn t see, in step 14, the update or insert since it has not itself committed yet an action that occurs later in step 15. Now a new transaction e1s2tx2 starts in session2 in step 17 and, as expected, it does see both the update and the insert done by the already committed transaction e1s1tx1 of session1. 4 Example-2: Serializability and locking This example demonstrates that the system will lock the rows being updated by a still active serializable transaction in order to prevent any updates to the same rows by other transactions. Figure 4 shows the two command files e2s1.sql and e2s2.sql that are used to run this example. In order to run example-2, one needs to perform the following tasks that are comparable to those required in Command file e2s1.sql ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE; -- transaction e2s1tx1 PAUSE +++A1+++ start session2 UPDATE Item SET price = price + 5 WHERE id=1; PAUSE +++B1+++ resume session2 PAUSE +++C1+++ resume session2 PAUSE +++D1+++ press ENTER to continue -- transaction e2s1tx2 PAUSE +++E1+++ resume session2 -- transaction e2s1tx3 PAUSE PAUSE +++F1+++ resume session2 example-1: 1. In session1, run the sqlplus in order to create the initial database instance. 2. In session1, run the sqlplus 3. In session2, run the sqlplus 4. Follow the prompts that will appear in both sessions asking for which session to resume and when. Now due to the placement of the PAUSE commands in the command files e2s1.sql and e2s2.sql, the system will execute the concurrent schedule depicted in figure 5 which is staggered in the fashion explained earlier in experiment-1. As can be seen in figure 5, session1 contains three transactions: e2s1tx1 (which begins at step 3 and commits at step 17), e2s1tx2 (which begins at step 20 and commits in step 21), and e2s1tx3 (which begins at step 26 and commits at step 27.) Session2, on the other hand, contains two transactions: e2s2tx1 (which begins at step 6 and commits at step 24) and transaction e2s2tx2 (which begins at step 29 and commits at step 30.) Steps 1 through 7 simply set the isolation levels to serializable, inspect the initial database and then pause the transactions. In steps 8, 9, and 10, transaction e2s1tx1 updates Item(1,A,10) to Item(1,A,15), and pauses. In step 11, transaction e2s2tx1 updates Item(3,B,30) to Item(3,B,36) successfully since the row is not being updated by e2s1tx1. As expected, steps 12 and 14 show that, since the two transactions are serializable and still active, they do see their own updates but not each other s updates. Command file e2s2.sql ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE; -- transaction: e2s2tx1 PAUSE +++A2+++ resume session1 UPDATE session1.item SET price = price + 6 WHERE id=3; PAUSE +++B2+++ resume session1 UPDATE session1.item SET price = price + 7 WHERE id=1; PAUSE +++C2+++ resume session1 PAUSE +++D2+++ resume session1 -- transaction: e2s2tx2 Figure 4: The command files for experiment 2

5 228 Int'l Conf. Frontiers in Education: CS and CE FECS'18 step Session_1 (e2s1.sql) serializable Session_2 (e2s2.sql) serializable 1 ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE; 2 -- transaction e2s1tx1 3 4 PAUSE +++A1+++ start session2 5 ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE; -- transaction: e2s2tx1 6 7 PAUSE +++A2+++ resume session1 8 UPDATE Item SET price = price + 5 WHERE id=1; 9 10 PAUSE +++B1+++ resume session2 11 UPDATE session1.item SET price = price + 6 WHERE id=3; PAUSE +++B2+++ resume session PAUSE +++C1+++ resume session2 16 UPDATE session1.item SET price = price + 7 WHERE id=1; *** Note: The system blocks this transaction (e2s2tx1) here. To continue, we need to resume session1 now e2s1tx1 -- Note: system displays: [error message: ORA "can't serialize access for this transaction ] as soon as e2s1tx1 commits 18 PAUSE +++C2+++ resume session1 19 PAUSE +++D1+++ press ENTER to continue -- transaction e2s1tx e2s1tx2 22 PAUSE +++E1+++ resume session e2s2tx1 25 PAUSE +++D2+++ resume session1 -- transaction e2s1tx e2s1tx3 28 PAUSE PAUSE +++F1+++ resume session2 -- transaction: e2s2tx e2s2tx2 Figure 5: The concurrent schedule in Experiment-2

6 Int'l Conf. Frontiers in Education: CS and CE FECS' In step16, transaction e2s2tx1 attempts to update the price of Item(1,A,10) while e2s1tx1 is still active. At this point, the system blocks e2s2tx1 since the row Item(1,A,10) has been locked on behalf of transaction e2s1tx1 in step 8 due to its request for update. Now as soon as e2s1tx1 is resumed, it commits in step 17 and the system displays, in session2, the message [ORA can t serialize access for this transaction ] indicating that the attempted update in step 16 by e2s2tx1 has failed. The remaining steps (18 through 30) demonstrate that updates become visible system-wide only after a transaction commits (at step 17 for e2s1tx1 and step 24 for e2s2tx1). 5 Example-3: Read Committed While example-1 and example-2 in the previous two sections demonstrated the behavior of serializable transactions, this example demonstrates the behavior of a transaction running under the read committed isolation level whereby an active transaction T2 can see, even before it commits, the updates made by another concurrent transaction T1 as soon as T1 commits. Figure 6 shows the two command files e3s1.sql and e3s2.sql that are used to run this example. In order to run example-3, one needs to perform the following tasks that are comparable to those required in examples-1 and and example-2: 1. In session1, run the sqlplus in order to create the initial database instance. 2. In session1, run the sqlplus Command file e3s1.sql ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE; -- transaction: e3s1tx1 PAUSE +++A1+++ start session2 UPDATE Item SET price = price + 5 WHERE id=1; INSERT INTO item VALUES (5, 'B', 50); PAUSE +++B1+++ resume session2 PAUSE +++C1+++ resume session2 3. In session2, run the sqlplus 4. Follow the prompts that will appear in both sessions asking for which session to resume and when. Due to the placement of the PAUSE commands in the command files e3s1.sql and e3s2.sql, the system will execute the concurrent schedule depicted in figure 7 which is staggered in the fashion explained earlier in examples 1 and 2. As can be seen in the figure, session1 contains the serializable transaction e3s1tx1 (which begins at step 2 and commits at step 17) and session2 contains the read committed transaction e3s2tx1 (which begins at step 6 and commits at step 19.) Steps 1 through 7 simply set session1 to serializable and session2 to read committed and then inspect the initial database in both sessions. In steps 8 and 9, transaction e3s1tx1 updates Item(1,A,10) to Item(1,A,15) and then inserts a new row Item(5,B,50). In steps 11 and 12 transaction e3s2tx1 updates Item(3,B,30) to Item(3,B,35) and then inserts a new row Item(2,A,20). Now steps 14 and 16 show that both transactions see their own, but not each other s, update/insert since neither of them has committed yet. However, once e3s1tx1 commits in step 17, its update/insert become visible to e3s2tx1 in step 18 even though the latter transaction has not committed yet. In other words, the transaction e3s2tx1 which is running under the read committed isolation level is susceptible to the unrepeatable read anomaly as evidenced by it seeing Item(1,A,10) in step 6 and later seeing that same row but now updated to Item(1,A,15) in step 18. It is also susceptible to the phantom problem since it can see Item(5,B,50) in step 18 that didn t exist in the database at step 6. Command file e3s2.sql ALTER SESSION SET ISOLATION_LEVEL = READ COMMITTED; -- transaction: e3s2tx1 PAUSE +++A2+++ resume session1 UPDATE session1.item SET price = price + 5 WHERE id=3; INSERT INTO session1.item VALUES (2, 'A', 20); PAUSE +++B2+++ resume session1 PAUSE +++C2+++ resume session1 Figure 6: The command files for experiment-3

7 230 Int'l Conf. Frontiers in Education: CS and CE FECS'18 step Session1 (e3s1.sql) serializable Session2 (e3s2.sql) read committed 1 ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE; -- transaction: e3s1tx1 2 3 PAUSE +++A1+++ resume session2 4 ALTER SESSION SET ISOLATION_LEVEL = READ COMMITTED; 5 -- transaction: e3s2tx1 6 7 PAUSE +++A2+++ resume session1 8 UPDATE Item SET price = price + 5 WHERE id=1; 9 INSERT INTO item VALUES (5, 'B', 50); 10 PAUSE +++B1+++ resume session2 11 UPDATE Item SET price = price + 5 WHERE id=3; 12 INSERT INTO item VALUES (2, 'A', 20); 13 PAUSE +++B2+++ resume session PAUSE +++C1+++ resume session A 20 3 B e3s1tx A 20 3 B e2s2tx1 Figure 7: The concurrent schedule in Experiment-3 6 Conclusions This paper presented hands-on examples that can be used in a database course to demonstrate key aspects of concurrency control in database systems in order to complement the descriptive nature in which the topic is covered in textbooks. The examples can be easily ported to systems other than oracle in database courses that use other systems. The examples can also serve as templates for creating exam questions to test students mastery of the topic. References 1. Elmasri and Navathe, Fundamentals of Database Systems, 7th edition, Addison-Wesley, Kifer, Bernstein, and Lewis, Database Systems: An Application Oriented Approach, Complete Version, 2 nd edition, Pearson Publishing, Oracle Corporation, SQL Language Reference, available at 4. Ramakrishnan and Gehrke, Database Management Systems, 3rd edition, McGraw-Hill, Silberschatz, Korth, and Sudarshan, Database Systems Concepts, 6th edition, McGraw Hill, 2011.