CS122 Lecture 19 Winter Term,

Transcription

1 CS122 Lecture 19 Winter Term,

2 2 Dirty Page Table: Last Time: ARIES Every log entry has a Log Sequence Number (LSN) associated with it Every data page records the LSN of the most recent operation applied to the page The Dirty Page Table records all pages in memory that are currently dirty RecLSN is LSN of the write that made the page dirty 1 PgID PageLSN RecLSN LSN PageLSN 303 A = 50 B = 90 A = 50 B = T 37 : start T 40 : start T 40 : C, 350, 250 T 37 : A, 100, 50 T 37 : B, 40, 90 T 40 : D, 100, 200 T 37 : commit PageLSN 362 C = 350 D = C = 250 D = 200 Volatile Memory Nonvolatile Memory PrevLSN T 40 : D, T 40 : C, T 40 : abort 362

3 3 ARIES Checkpoints ARIES also supports fuzzy checkpoints An ARIES checkpoint record includes: A table of all active transactions, including the ID of each transaction, and its LastLSN value: The log sequence number of the last WAL record generated for that transaction The dirty page table, specifying all dirty pages at time of checkpoint, along with their PageLSN and RecLSN values The fuzzy checkpoint procedure is similar to before: Write and Xlush all in- memory log records to disk Write and Xlush the checkpoint record to disk

4 4 ARIES Checkpoints (2) ARIES doesn t require Xlushing all dirty pages to disk as a part of the fuzzy checkpoint Makes checkpointing very unintrusive to other transaction- processing operations Rather, buffer manager writes out dirty pages on a regular basis, during normal execution Can schedule dirty page writes to minimize disk seeks When a dirty page is Xlushed to disk: Easy to follow the WAL rule, using PageLSN value stored in each page e.g. when Xlushing page 2, simply ensure that write- ahead log is Xlushed to record with LSN PageLSN 303 A = 50 B = A = 50 B = 90 2 PageLSN 362 C = 350 D = C = 250 D = 200 Volatile Memory Nonvolatile Memory

5 5 ARIES Recovery ARIES recovery- processing involves three phases: Analysis phase, redo phase, undo phase Analysis phase performs three important tasks: Determine the starting point (LSN) in the write- ahead log where redo processing must commence from Determine the set of data pages that must be brought into sync with the write- ahead log state Determine the set of incomplete transactions that must be rolled back (In ARIES paper, these are called loser transactions)

6 6 Recovery: Analysis Phase Checkpoint record contains a copy of dirty page table Use this table to determine initial value of RedoLSN, the LSN where the redo phase should start from e.g. given this dirty page table: RedoLSN should be 345 General rule: Set RedoLSN to smallest value of RecLSN that appears in dirty page table If checkpoint s dirty page table is empty, set RedoLSN to the LSN of the checkpoint record Dirty Page Table: PgID PageLSN RecLSN

7 7 Recovery: Analysis Phase (2) Next, analysis phase determines the set of dirty pages, and the set of incomplete transactions Initial dirty page table, and initial set of incomplete transactions are both taken from the checkpoint state Start scanning forward through write- ahead log, starting with the checkpoint record (not RedoLSN!) (We are not replaying history, just determining the set of dirty pages, and the set of incomplete transactions)

8 8 Recovery: Analysis Phase (3) Scan forward from the checkpoint record: If a <T i : begin> record is seen, add T i to set of incomplete transactions, with LastLSN set to LSN of record Allows us to know where to start undoing T i, if we have to If a <T i : commit> or <T i : abort> record is seen, remove T i from set of incomplete transactions For T i update records: <T i : X j, V 1, V 2 > or <T i : X j, V> Update transaction T i s LastLSN to LSN of the update record If X j s data page is not in the dirty page table, add it to the table with RecLSN set to the LSN of the update record, and PageLSN taken from the data page on disk When this scan is complete, analysis phase is complete

9 9 Recovery: Redo Phase Database now has an up- to- date dirty page table From earlier: ARIES uses each page s PageLSN value to ensure that each update is only applied to a page once Required to make recovery processing idempotent, since some ARIES redo- operations may only be applied once Redo phase: repeat history! For each update record <T i : X j, V 1, V 2 > or <T i : X j, V>: If X j s page is in dirty page table then apply the update If not, we know update already hit the data page on disk; no need to apply the update twice!

10 10 Recovery: Redo Phase (2) At end of redo phase, database will be in exactly the same state as when the system crash occurred The redo phase only loads data pages that need to be updated. No updates are applied multiple times! Makes for a much faster recovery process than before After redo phase, there will be incomplete transactions Roll these back in the undo phase

11 11 Recovery: Undo Phase Undo phase must roll back all incomplete transactions At end of analysis phase, had a table of all incomplete transactions, along with LastLSN of each transaction Can roll back these transactions in any order Could roll each transaction back separately, or could roll all transactions back in a single pass LSN Each log record specixies the LSN of 257 T the previous operation in that txn, so 37 : start 262 T 40 : start rolling back these operations is easy 267 T 40 : C, 350, T As before, must write Compensation Log 37 : A, 100, T 37 : B, 40, 90 Records to WAL when undoing an update 321 T 40 : D, 100, T of the form <T i : X j, V 1, V 2 >! 37 : commit PrevLSN

12 12 ARIES Logging/Recovery Checkpoints are often performed during recovery to guard against further crashes during recovery Next recovery attempt will begin further down the line ARIES is a very complex logging/recovery system Provides many txn- processing features and benexits Checkpoints and recovery processing are both very fast DeXinitely worth the added complexity! Extensive use of ARIES demonstrates this very clearly

13 13 TransacDon IsolaDon ACID Properties: Atomicity, Consistency, Isolation, Durability Have talked about atomicity, consistency, durability Important whether the DB is single- user or multi- user Traditional approach is to use a write- ahead log, although shadow- page technique shows up in some places Transaction isolation is very important when a DB can be used by multiple clients at the same time Multiple concurrent operations against same data values Without proper precautions, DB will produce spurious results Five kinds of spurious results can occur, without proper transaction isolation

14 14 TransacDon IsolaDon Issues Dirty writes: A transaction T 1 writes a value to X Another transaction T 2 also writes a value to X, before T 1 commits or aborts If T 1 or T 2 aborts, what should be the value of X? Dirty reads: A transaction T 1 writes a value to X T 2 reads X before T 1 commits If T 1 aborts, T 2 has an invalid value for X Nonrepeatable reads: T 1 reads X T 2 writes to X, or deletes X, then commits If T 1 reads X again, value is now different or gone

15 15 TransacDon IsolaDon Issues (2) Phantom rows, a.k.a. phantoms: Transaction T 1 reads rows that satisfy a predicate P Transaction T 2 then writes rows, some of which satisfy P If T 1 repeats its read, it gets a different set of results If T 1 writes values based on original read, new rows aren t considered! Lost updates: Transaction T 1 reads the value of X Transaction T 2 writes a new value to X T 1 writes to X based on its previously read value

16 16 Serial TransacDon ExecuDon A simple solution to transaction isolation issues: Only allow one transaction to execute at a time Transactions are executed in a serial order Problem: this is really slow Doesn t maximize utilization of DB server resources Transaction throughput will be really low Most of the time, transactions work with completely different records Isolation: For every pair of transactions T i and T j, it appears that either T i completes before T j starts, or that T j completes before T i starts

17 17 Serializable ExecuDon Most databases interleave transaction operations As long as database is careful to maintain isolation, yields much higher transaction processing throughput Goal: ensure that transactions are executed in a way that is equivalent to a serial execution schedule For every pair of transactions T i and T j, it appears that either T i completes before T j starts, or that T j completes before T i starts Called a serializable execution schedule Several different kinds of serializable schedules, with different characteristics Not all serializable schedules are created equal!

18 18 SQL IsolaDon Levels Sometimes applications are immune to certain kinds of spurious results e.g. nonrepeatable reads or phantom rows App doesn t have queries that are affected by these behaviors, e.g. if most transactions are simple retrievals or updates Can dexine weaker forms of isolation Weaker isolation allows greater concurrency, and therefore greater transaction throughput Weaker isolation also allows more kinds of spurious results SQL dexines four isolation levels for use in applications Can set individual txns to have a specixic isolation level

19 19 SQL IsolaDon Levels (2) Serializable: Concurrent transactions produce the same result as if they were run in some serial order The serial order may not necessarily correspond to the exact order that transactions were issued Called strong isolation Only level that satisxies original dexinition of isolation: For every pair of transactions T i and T j, it appears that either T i completes before T j starts, or that T j completes before T i starts

20 20 SQL IsolaDon Levels (3) Other isolation levels are called weak isolation Allow various kinds of spurious behavior in concurrent transactions Repeatable reads: During a transaction, multiple reads of X produce same results, regardless of committed writes to X in other transactions Other transactions committed changes do not become visible in the middle of a transaction (If the txn changes X, it sees its own modixications )

21 21 SQL IsolaDon Levels (4) Read committed: During a transaction, other transactions committed changes become visible immediately Value of X can change during a transaction, if other transactions write to X and then commit Read uncommitted: Uncommitted changes to X in other transactions become visible immediately Aside: Many DBs also now include snapshot isolation They sometimes call it serializable isolation, but it isn t! Will discuss this isolation level in a few lectures

22 22 SQL IsolaDon Levels (5) Different SQL isolation levels allow different kinds of spurious behaviors: Isolation Level Dirty Writes Dirty Reads Nonrepeatable Reads Phantoms serializable NO NO NO NO repeatable reads NO NO NO YES read committed NO NO YES YES read uncommitted NO YES YES YES

23 23 SQL IsolaDon Levels (6) Databases often allow clients to set the desired transaction isolation level SQL syntax: SET TRANSACTION ISOLATION LEVEL [ SERIALIZABLE REPEATABLE READS READ COMMITTED READ UNCOMMITTED ] Databases don t always support all isolation levels! DB2, SQLServer, MySQL support all four isolation levels Oracle and PostgreSQL only support SERIALIZABLE and READ COMMITTED isolation levels (And by serializable isolation they mean snapshot )

24 24 TransacDon Schedules As before, model transactions as a series of reads and writes on various data items The sequences of operations that txns perform are called schedules A schedule can only perform one operation at a time A serial schedule never allows the reads and writes of two transactions to be interleaved Very slow, but avoids all spurious results T i : read(a); A := A 50; read(b); B := B + 50; write(b); commit. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit.

25 25 Serializable Schedules Want to interleave transaction operations to improve throughput Need to make sure that results are still valid Require that execution schedules are equivalent to a serial schedule i.e. the schedule is serializable T i : read(a); A := A 50; read(b); B := B + 50; write(b); commit. What makes a schedule serializable? How do we know two schedules are equivalent? T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit.

26 26 Serializable Schedules (2) Given: A schedule S containing operations performed by two transactions, T i and T j In the schedule, instruction I from transaction T i is adjacent to instruction J from T j In what situations can we swap the order of instructions I and J without affecting the results? If we cannot swap instructions I and J without affecting the results, we say that the operations conmlict

27 27 Avoiding Conflicts A simple example: Two adjacent instructions I and J, from different transactions T i and T j, respectively Instruction I is read(a) or write(a), on a data- item A Instruction J is read(b) or write(b), on a different data- item B Does it matter what order we execute I and J? If instructions I and J refer to different data- items, they do not conxlict. We can execute I and J in any order.

28 28 Avoiding Conflicts (2) Instructions I and J could conxlict if they read or write the same data item If I = read(q) and J = read(q), can we swap them without affecting the results? Yes! Both transactions will see the same value for Q, regardless of the order. If I = read(q) and J = write(q), can we swap them without affecting the results? No! If I executes before J, T i will see the old value of Q. If I executes after J, T i will see the new value of Q.

29 29 Avoiding Conflicts (3) Same issue if I = write(q) and J = read(q) Cannot swap order of I and J without affecting the results If I = write(q) and J = write(q), can we swap them without affecting the results? The write operations themselves will not be affected but the next read of Q will see different results based on the order of I and J Cannot swap order of I and J without affecting the results

30 30 Conflict Equivalence Given a transaction execution schedule S, with two adjacent operations I and J from different transactions Instructions I and J conxlict if: I and J operate on the same data item At least one of the operations is a write If the instructions I and J do not conxlict: We can swap them to produce an equivalent schedule S Execution of S or S will produce the exact same results

31 31 Conflict Equivalence (2) A pair of schedules S and S are conmlict equivalent if: One schedule can be transformed into the other, solely by swapping adjacent non- conxlicting operations A schedule S is conmlict serializable if it is conxlict equivalent to a serial schedule

32 32 Previous Example Schedules Are these schedules conxlict equivalent? Yes: only non- conxlicting operations are swapped. T i : read(a); A := A 50; read(b); B := B + 50; write(b); commit. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit. T i : read(a); A := A 50; read(b); B := B + 50; write(b); commit. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit.

33 33 Previous Example Schedules (2) Is the right schedule conxlict serializable? Yes! Left schedule is a serial execution schedule. T i : read(a); A := A 50; read(b); B := B + 50; write(b); commit. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit. T i : read(a); A := A 50; read(b); B := B + 50; write(b); commit. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit.

34 34 Another Example Again, is the right schedule conxlict serializable? Yes. Left schedule is serial; right is conxlict equivalent. T i : read(a); A := A 50; read(b); B := B + 50; write(b); commit. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit. T i : read(a); A := A 50; read(b); B := B + 50; write(b); commit. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit.

35 35 A New Problem What if we have this execution schedule, but T i aborts? This execution schedule violates atomicity! T i modixies data- item A Then T j also modixies A, based on T i s changes! Then T j commits, preserving T i s changes to A, even though T i is eventually aborted. Could preserve atomicity by aborting T j when T i aborts That would violate durability!! T i : read(a); A := A 50; read(b); B := B + 50; write(b); abort. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit.

36 36 Recoverable Schedules This is a nonrecoverable execution schedule Can t properly enforce atomicity, consistency and durability with this schedule Want to constrain ourselves to only recoverable schedules A schedule S is recoverable if, for every pair of txns T i and T j : If T j reads a data- item previously written by T i, then T j is not allowed to commit until T i Xirst commits T i : read(a); A := A 50; read(b); B := B + 50; write(b); abort. T j : read(a); A := A 30; read(c); C := C + 30; write(c); commit.

37 37 Recoverable Schedules (2) Can make this schedule recoverable simply by delaying T j s commit operation T j enters partially committed state initially When T i aborts, T j is also aborted Transaction T j is dependent on T i : T j reads a value that T i has written to General rule: Dependent transactions may not commit until the initial transaction commits T i : read(a); A := A 50; read(b); B := B + 50; write(b); abort. T j : read(a); A := A 30; read(c); C := C + 30; write(c); partially committed abort.

38 38 Recoverable Schedules (3) If T i aborts then we must abort T j too Called a cascading rollback This can get very expensive Very easy to introduce dependencies between interleaved transactions Aborting one transaction can cause a large amount of work to be discarded T i : read(a); A := A 50; read(b); B := B + 50; write(b); abort. T j : read(a); A := A 30; read(c); C := C + 30; write(c); abort. T k : read(c); C := C * 1.03; write(c); abort.

39 39 Cascadeless Schedules Cascadeless schedules disallow cascading rollbacks from occurring A schedule S is cascadeless if, for every pair of transactions T i and T j : If T j reads a data- item previously written by T i, then T j is not allowed to perform this read until T i Xirst commits Question: What if T j writes (but never reads) a data- item that T i previously wrote, and then T i is aborted? Don t need to cascade the rollback to T j T j never saw the old value!

40 40 Blind Writes One more example: Original value of A is 1 All writes in these transactions are blind writes The data item is not read before it is written Is this schedule cascadeless? This schedule is cascadeless T j doesn t read A at all T i : A := 2 abort. T j : A := 3 abort.

41 41 Blind Writes (2) As these txns are executed, write- ahead log is updated When T i aborts, it issues a compensating log record, as usual When T j aborts, it also issues a compensating log record except that the old value of A is from an aborted transaction Original value of A was 1, but after T i and T j are aborted, it s 2! T i : A := 2 abort. T j : A := 3 abort. Write- Ahead Log: T i : start T i : A, 1, 2 T j : start T j : A, 2, 3 T i CLR: A, 1 T i : abort T j CLR: A, 2 T j : abort

42 42 Blind Writes (3) Problem: The before- value of A written to the write- ahead log for T j was taken from the incomplete transaction T i If T i aborts, the before- value T j has is useless for rollback! Writes to a data- item also introduce subtle dependencies between txns, through the write-ahead log! T i : A := 2 abort. T j : A := 3 abort. Write- Ahead Log: T i : start T i : A, 1, 2 T j : start T j : A, 2, 3 T i CLR: A, 1 T i : abort T j CLR: A, 2 T j : abort

43 43 Strict Schedules To simplify recovery processing, further constrain transaction schedules to be strict A schedule S is strict if, for every pair of txns T i and T j : If T j reads or writes a data- item previously written by T i, then T j is not allowed to do this until T i Xirst commits If the database only uses strict execution schedules: When a transaction Xirst writes to any given data- item, the update record written to the WAL will never contain an uncommitted value from another transaction This makes recovery processing much simpler

44 44 TransacDon Schedule Hierarchy Can subdivide space of transaction schedules based on classixications discussed today: All execution schedules Recoverable schedules Cascadeless schedules Strict schedules ConXlict- serializable schedules Serial schedules