Final Exam CSE232, Spring 97

Name:

Time: 2hrs 40min. Total points are 148.

Serializability I (8)

Consider the following schedule S, consisting of transactions T1, T2 and T3

T1

T2

T3

w(A)

 

 

 

r(A)

 

 

 

w(B)

w(B)

 

 

 

 

w(B)

 

w(A)

 

 

 

r(B)

 

r(B)

 

Serializability II (15)

Two transactions are not interleaved in a schedule S if every operation of one transaction precedes every operation of the other. (Note, the schedule may not be serial.) Give an example of a serializable schedule S that has all of the following properties:

Hint: The schedule may include more than two transactions.

Serializability III (15)

Consider two non-identical schedules S and S’ consisting of transactions T1,…, Tn where n>1. For each of the following set of conditions decide whether S and S’

The conditions are

  1. S only reads, S and S’ are serial and n=2
  2. All transactions T1,…, Tn write a specific item A exactly once and S and S’ are serial.
  3. The precedence graphs of S and S’ are identical and acyclic.
  4. S is serializable but S’ is not serializable.
  5. No two serial schedules (of T1,…, Tn) are equivalent and S and S’ are serializable.

 

equivalent

Nonequivalent

impossible to decide

can not hold

1

 

 

 

 

2

 

 

 

 

3

 

 

 

 

4

 

 

 

 

5

 

 

 

 

Two Phase Lock (20)

For each one of the following schedules decide whether

and check in the table below all entries that apply. Justify your answers in a concrete way. For example, if a schedule is 2PL show a series of lock/unlock operations that are compatible with the 2PL rules (you can use the empty lines of the schedules to place lock/unlock operations.) Answers of the form "it is serializable because I can see that I can swap the operations" will not get full credit. Assume that shared locks can be used if in this way you can make a schedule 2PL or strict 2PL.

T1

T2

T3

 

 

 

 

 

r(D)

 

 

 

w(A)

 

 

 

 

 

 

r(B)

 

 

 

 

 

 

w(D)

 

 

 

w(B)

 

 

 

 

 

 

r(D)

 

 

 

 

T1

T2

T3

 

 

 

w(A)

 

 

 

 

 

 

r(B)

 

 

 

 

 

 

w(D)

 

 

 

w(B)

 

 

 

 

 

 

r(D)

 

 

 

 

 

 

w(D)

 

T1

T2

T3

 

 

 

 

 

 

 

 

r(D)

 

 

 

w(A)

 

 

 

 

 

 

r(B)

 

 

 

 

w(B)

 

 

 

 

 

 

 

 

 

r(D)

 

 

 

 

 

 

w(D)

 

 

 

 

serializable

2PL

Strict 2PL

1

 

 

 

2

 

 

 

3

 

 

 

 

Recovery I (10)

  1. Undo logging requires that before an item X is modified on disk the log records pertaining to X are in the disk. (This is the WAL rule.) Show using an example that an inconsistent database may result if log records for X are not output to the disk before X.
  2. Redo logging: Show using an example that an inconsistent database may result if some items are written on the disk before the commit is written on the log, even if WAL holds.
  3. Undo logging: Show using an example that an inconsistent database may result if some items are not written in the disk by the time the commit is written. Assume that WAL holds.

Your examples should involve a crash and should clearly show (I) the write actions of the transaction, (II) the state of the log and the database at the time of the crash, and (III) why successful recovery can not be accomplished.

Recovery II (20)

We know that non strict 2PL may cause cascading aborts. Even worse, it could be the case that a crash occurs while cascading aborts take place. The goal of this exercise is to develop an Undo logging system that can handle cascading aborts, i.e., upon restart it can abort the transactions that have to be aborted and so on.

  1. What additions are needed in the Undo logging data for handling cascading aborts
  2. Write the rules of your enhanced "cascading abort Undo logging" (in the spirit of the notes). Try to pose rules that are not very restrictive.
  3. Write an algorithm for recovery (restart) using notation similar with the notes.

Clarification on notes: In the slide of "Undo Logging Recovery" the condition "NO <T, Commit> (or <T, Abort>) in log" is parenthesized as "(NO <T, Commit>) OR <T, Abort> in log".

Recovery III (18)

Consider a transaction that performs the following actions in the given order

  1. Write object A
  2. Write object B
  3. Commit

Decide whether each one of the following snapshots of the database and the log are possible or impossible at any point during or after the end of the transaction. The snapshots refer to data that are actually in the disk. Assume that if we do not mention explicitly that something is stored on the disk then it is not stored on the disk. For each item give an answer for both Undo and Redo logging.

  1. Log has entry for write(A) and the database has the new value of A
  2. The database has the new value for A
  3. The log has entries for write(A) and write(B) and also has the commit entry
  4. The log has entries for write(A) and write(B). The database has the new values for A and B
  5. The log has entries for write(A), write(B), and the commit entry. The database has the new value for A
  6. Log has entry for write(A) and commit and the database has the new value of A

 

UNDO

LOGGING

 

possible

impossible

1

 

 

2

 

 

3

 

 

4

 

 

5

 

 

6

 

 

 

REDO

LOGGING

 

possible

impossible

1

 

 

2

 

 

3

 

 

4

 

 

5

 

 

6

 

 

 

Query Processing II (22)

.Consider the following query:

SELECT *

FROM R, S, T

WHERE R.A = S.A and R.B = T.B AND T.C = S.C

AND R.D = 16 AND S.F = 17

  1. Give six algebraic expressions that (I) contain no cartesian product, (II) have pushed selections down, (III) each join is associated with an atomic condition (not a conjunctive condition).
  2. Find the optimum plan, i.e., an algebraic expression where selections and projections are annotated with execution primitives. The execution primitives are SCAN and INDEX for the selection operator and LOOPS, INDEX, MERGE, and HASH for join. Compute an estimation of the optimal plan’s cost.

Assume the following schemas and statistics for the relations.

Assume the block size is 4096 Bytes, the block header size is 96 bytes, each indexed attribute occupies 5 bytes and the tuple size of each relation is 80 bytes.

To estimate the size of the joins use the following information:

Assume there is one megabyte of main memory available. Hint: You should use the main memory to avoid copying intermediate results to the disk, if there is enough space in main memory.

      1. Solution