More on transactions…

Dealing with concurrency (OR: how to handle the pressure!) Locking Timestamp ordering Multiversion protocols Optimistic protocols (validation protocol)

Timestamping: Wait-Die (1) If the younger transaction locks first: T1 - start at time-1 (older) T2 - start at time-2 (younger) T2 - request X lock on R T2 - write R - X lock T1 - request X lock on R - wait

Timestamping: Wait-Die (2) If the older transaction locks first: T1 - start at time-1 (older) T2 - start at time-2 (younger) T1 - request X lock on R T1 - write R - X lock T2 - request X lock on R - abort T1 - release X lock on R T2 - start again at time-2 (same timestamp, so it “looks older”)

Timestamping: Wound-Wait (1) If the younger transaction locks first: T1 - start at time-1 (older) T2 - start at time-2 (younger) T2 - request X lock on R T2 - write R - X lock T1 - request X lock on R T2 - abort T1 - write R - X lock T2 - start again at time-2

Timestamping: Wound-Wait (2) If the older transaction locks first: T1 - start at time-1 (older) T2 - start at time-2 (younger) T1 - request X lock on R T1 - write R - X lock T2 - request X lock on R - wait

Other concepts Cautious waiting – can only have one transaction waiting for each item Live lock – transaction can’t finish because it is always the youngest (might occur if tx didn’t keep the original timestamp) Timeout – assume that if waited longer than X time, deadlock exists, so tx are aborted

Transactions 1+ SQL statements that are performed completely, or not at all ACID properties –Atomic –Consistent –Isolation –Durability

Transaction Demo

Recovery

Types of Failures Transaction failure –Transaction must be aborted System failure –Hardware or software problem resulting in volatile memory loss Media failure –Disks or tapes Disasters

Transaction Logs Before image –Records previous values of objects before they were changed –Can be used to "undo" the transaction After image –Records new values after they've been changed –Can be used to "redo" the transaction

Logging changes System logs record activity of db (start of tx, operation performed, end of tx) Current block of log is in memory; when full, block is written to disk Changes can be force-written to disk "Write-ahead" logging Checkpoints are also recorded in log –Commit-consistent –Cache-consistent –Fuzzy

Logging changes (con'd) In-place updating Out-of-place updating –Shadowing Undo log may also be in volatile memory, so may need to be written to disk periodically

Commit processing No flush strategy Flush strategy No steal strategy Steal strategy Deferred update Immediate update How these strategies are combined determines what needs to be done in the event of failure Trade offs

Checkpoints in Oracle Mark that database is in a consistent state Oracle SCN Written to headers of database files and to control files

The Oracle SGA (Memory) System TS (Data Dictionary) Rollback segments Temporary Data1... Index1... Redo2 Redo3 Redo1 Arch1 Arch2 Arch3 Arch4 Arch5

TX recovery in Oracle Log scanned backward from end of log to most recent checkpoint. Undo uncommitted or aborted transactions. Log scanned forward from checkpoint. Redo all committed transactions. Take new checkpoint.

Transaction states CheckpointFailure T1 T2 T3 T4 T5 C C C TIME