<<

System Implementation Project

Spring 2006-2007 Lecture 5 Transaction Properties

• A transaction system must satisfy the ACID properties • Atomicity – Either all the operations within the transaction are reflected properly in the database, or none are • Consistency – When a transaction completes, the database must be in a consistent state; i.e. all constraints must hold •Isolation – When multiple transactions execute concurrently, they must appear to execute one after the other, in isolation of each other • Durability – After a transaction commits, all changes should persist, even when a system failure occurs Bank Account Example

• Transfer $400 from account A-201 to A-305 – Clearly requires multiple steps • If transaction isn’t atomic: – Perhaps only one account shows the change! • If transaction isn’t consistent: – Sum of account balances may not stay constant • If transaction isn’t isolated: – Multiple operations involving either account could result in inaccurate balances • If transaction isn’t durable: – If DB crashes, could end up with inaccurate balances! Transaction Properties

• A database system must provide transactions with ACID properties • Several components must work together to provide ACID properties: – A transaction manager ensures atomicity of transactions – A concurrency-control system ensures proper isolation of concurrent transactions – A recovery manager ensures durability of transactions – Database application programmers must ensure consistency of their transactions Transaction States

• Transactions go through a series of states •Active – Transaction starts in this state, and stays active as it progresses • Partially committed – Last operation in transaction has completed successfully, but transaction may still be aborted – e.g. a hardware failure may require the transaction to be aborted during recovery • Committed – Transaction is completed; all changes are visible in the States (2)

• Failed – Transaction can no longer complete successfully – Transaction cannot be committed, only aborted • Aborted – Transaction has been completely rolled back; DB is in original state • Transaction state diagram:

partially committed committed

active

failed aborted Shadow Copies

• Can provide atomicity and durability using a shadow copy scheme • Requires only one transaction at a time • Approach: – When transaction needs to write to database, the entire database is copied – All modifications in the transaction go against the shadow copy – When transaction is committed, the new copy replaces the old version in one atomic operation Shadow Copies (2)

db pointer

old copy new copy of database of database

• A db-pointer refers to the last committed state • When changes are made, they go against a complete copy of the database • When transaction is committed, db-pointer is changed to new copy (delete old version) • If transaction is aborted, just delete new version Shadow Copies (3)

• Very inefficient strategy for atomicity, durability – Can only support one transaction at a time! • Most text editors use this model – During transaction: • foo.txt is the current copy • #foo.txt# is the shadow copy – At transaction- (“save document”): • foo.txt renamed to foo.txt~ • #foo.txt# renamed to foo.txt – Ideally, changing the db-pointer is an atomic operation provided by the OS • Necessary for guaranteeing survival of system failures Transaction Operations

• Transactions are modeled as a series of read and write operations • Example: – Transfer $400 from account A-201 to A-305

– Transaction T1 schedule:

read(X1)

X1 := X1 –400

write(X1)

read(X2)

X2 := X2 + 400

write(X2) Disk Operations

data is stored in one or more files – Data files are read at a page granularity – Can model these operations: • input(B) transfers block B from disk to memory • output(B) writes block B from memory to disk • include a buffer manager – Disk pages are kept in a shared buffer – Dramatically reduces number of disk reads and writes – read() and write() use buffer pages in memory – Buffer manager must interact closely with recovery manager Log-Based Recovery

• Most databases use a to provide durable transactions • Table data is distributed across multiple files – Providing atomic operations involving multiple files is very difficult • Operations are logged to a single file – Virtually all OSes provide atomic operations for interacting with a single file • Can use the transaction log in recovery processing to ensure transaction durability • These schemes are for single-version storage – Only one copy/version of each record is stored Log-Based Recovery (2)

• Several different kinds of log records:

• Transaction Ti was started • Transaction Ti wrote to data item Xj • Old value was V1, new value is V2 • Transaction Ti was committed • Transaction Ti was aborted Log-Based Recovery (3)

• Update log records: – Records every write operation a transaction performs

–V1 is the old value, V2 is the new value • If a txn needs to be redone, can rewrite V2 to Xj –V2 is “redo data” • If a txn needs to be undone, can rewrite V1 to Xj –V1 is “undo data” • A data value Xj may have multiple updates in transaction Ti – Transaction log will have multiple update records for that value Deferred Modification

• Deferred-modification technique – All updates are recorded to transaction log first – Table writes are deferred until txn partially commits

• At commit time for transaction Ti: – record is written to log – Transaction log is flushed to disk

– Records for Ti are used to perform deferred writes • Undo data is unnecessary with this scheme – A table’s data is never written before the txn commits • Can be very inefficient for large transactions – Generate many records, then replay them at commit! Log-Based Recovery

• When DB system crashes, can scan log to restore DB to a consistent state – “Replay the log” against the database

• If log has both and logs for transaction Ti, redo that transaction – Replay all update operations for Ti – Model as a redo(Ti) function • If no commit record for Ti, don’t redo its updates • redo() function must be idempotent – Applying redo() multiple times must be equivalent to applying it only once – DB may also crash during recovery processing Immediate Modification

• Immediate-modification technique – Table writes are allowed before a txn commits • Called uncommitted modifications – If a transaction must be rolled back, old values of data items are required! • Transaction log is maintained as before – Update records must be written to log before corresponding table writes may occur! • Technique is called write-ahead logging (WAL) – Transaction log is called a write-ahead log – All updates are logged in WAL before written to tables Immediate Modification (2)

• A new recovery procedure is needed: undo(Ti) – undo() must also be idempotent – Update records are applied in reverse order

– For each record, V1 (old value) is written back to Xj •If a txnTi is aborted during normal operation – Use txn-log to undo all operations in Ti: undo(Ti) • During recovery, scan entire log:

–If Ti has and logs: redo(Ti) –If Ti has only , or and logs: undo(Ti) – Order of application is important! (more later) Immediate Modification (3)

• Usually more efficient than deferred modification – Most transactions will commit successfully – Undoing a transaction will be infrequent •Must carefully manage disk writes and flushes! – Transaction logging and buffer management are tightly coupled – Can’t flush a buffer page to disk until corresponding txn-log writes for that page have been flushed Checkpoints

• Transaction logs can grow very large – At recovery time, entire log must be replayed – Log may need to be scanned twice or more times • Can write checkpoints to the transaction log – Indicates that all transaction-log records before the checkpoint are reflected in stable storage – Only need to replay log from most recent checkpoint • Checkpoint procedure: – Flush all transaction log data to disk – Flush all modified table data to disk – Write a checkpoint record to the disk Checkpoints (2)

• No other writes may occur during checkpoint – Transactions may be active at time of checkpoint – Write operations are suspended until checkpoint completes • Can delete transaction logs before a checkpoint – Those log records are reflected in all table data • DBs often keep two most recent checkpoints – If most recent checkpoint was corrupted, DB can go back to second most recent checkpoint – If second most recent checkpoint is also corrupted, recovery fails Concurrent Transactions

• When transactions are serialized, at most one transaction is interrupted – Need to undo at most one transaction – May need to redo several transactions • When transactions proceed concurrently, several transactions may be interrupted – Checkpoint record specifies transactions that are in flight at time of checkpoint • Order of redo() and undo() application is critical – Transactions often write to the same data values Concurrent Transactions (2)

• Must make sure that applying undo(Ti) doesn’t accidentally overwrite redo(Tj) • Must also apply undo operations backwards – A txn can write the same data item multiple times • Recovery procedure: – Generate a list of transactions to redo, and a list of transactions to undo – Perform all undo operations first, scanning backward through log – Then perform all redo operations, scanning forward through log and Recovery

• A major assumption: – Concurrency control system prevents cascade aborts! – Aborting a transaction will not cause any other transaction to abort • Concurrency control systems avoid this by using two-phase locking procedure

– undo(Ti) only involves log records for Ti • Multi-version concurrency control (MVCC) – When a record changes, a new version is stored – The old version of the record is still available on disk – Undo processing becomes unnecessary: the new version of the record can simply be ignored Next Week

• Next class is mid-term project presentations – Aim for 10-15 minutes long – Can use slides, hand-outs, etc. if you want • Focus: – Describe the project you are pursuing • Give an overview of the project for everyone • Specific aspects you are focusing on – Describe your current implementation status • What has been completed so far (and any issues) • What you are going to do for the rest of the term • What you hope to demonstrate at the end of the term