Reference no: EM13336584
Design considerations and calculation
Question 1
Consider a database with objects X and Y and assume that there are two transactions T1 and T 2. Transaction T 1 reads objects X and Y and then writes object X. Transaction T 2 reads objects X and Y and then writes objects X and Y.
1. Give an example schedule with actions of transactions T1 and T 2 on objects X and Y that results in a write-read conflict.
2. Give an example schedule with actions of transactions T1 and T 2 on objects X and Y that results in a read-write conflict.
3. Give an example schedule with actions of transactions T1 and T 2 on objects X and Y that results in a write-write conflict.
4. For each of the three schedules, show that Strict 2PL disallows the schedule.
Question 2
Answer the following questions: SQL supports four isolation-levels and two access-modes, for a total of eight combinations of isolation-level and access-mode. Each combination implicitly defines a class of transactions; the following questions refer to these eight classes:
1. Consider the four SQL isolation levels. Describe which of the phenomena can occur at each of these isolation levels: dirty read, unrepeatable read, and phantom problem.
2. For each of the four isolation levels, give examples of transactions that could be run safely at that level.
3. Why does the access mode of a transaction matter?
Question 3
Consider the following classes of schedules: serializable, conflict-serializable, viewserializable, recoverable, avoids-cascading-aborts, and strict. For each of the following schedules, state to which of the preceding classes it belongs. If you cannot decide whether a schedule belongs in a certain class based on the listed actions, explain briefly.The actions are listed in the order they are scheduled and prefixed with the transaction name. If a commit or abort is not shown, the schedule is incomplete; assume that abort or commit must follow all the listed actions.
1. T1:R(X), T2:R(X), T1:W(X), T2:W(X)
2. T1:W(X), T2:R(Y), T1:R(Y), T2:R(X)
3. T1:R(X), T2:R(Y), T3:W(X), T2:R(X), T1:R(Y)
4. T1:R(X), T1:R(Y), T1:W(X), T2:R(Y), T3:W(Y), T1:W(X), T2:R(Y)
5. T1:R(X), T2:W(X), T1:W(X), T2:Abort, T1:Commit
6. T1:R(X), T2:W(X), T1:W(X), T2:Commit, T1:Commit
7. T1:W(X), T2:R(X), T1:W(X), T2:Abort, T1:Commit
8. T1:W(X), T2:R(X), T1:W(X), T2:Commit, T1:Commit
9. T1:W(X), T2:R(X), T1:W(X), T2:Commit, T1:Abort
10. T2: R(X), T3:W(X), T3:Commit, T1:W(Y), T1:Commit, T2:R(Y), T2:W(Z), T2:Commit
11. T1:R(X), T2:W(X), T2:Commit, T1:W(X), T1:Commit, T3:R(X), T3:Commit
12. T1:R(X), T2:W(X), T1:W(X), T3:R(X), T1:Commit, T2:Commit, T3:Commit
Question 4
Consider the execution shown in the following figure. In addition, the system crashes during recovery after writing two log records to stable storage and again after writing another two log records.
LSN LOG
00 begin_checkpoint
10 end_checkpoint
20 update: T1 writes P1
30 update: T2 writes P2
40 update: T3 writes P3
50 T2 commit
60 update: T3 writes P2
70 T2 end
80 update: T1 writes P5
90 T3 abort
X CRASH, RESTART
1. What is the value of the LSN stored in the master log record?
2. What is done during Analysis?
3. What is done during Redo?
4. What is done during Undo?
5. Show the log when recovery is complete, including all non-null prevLSN and undonextLSN values in log records.