COT 5611 – Spring 2012 Operating Systems Design Principles

Slides:



Advertisements
Similar presentations
Chapter 16: Recovery System
Advertisements

Transaction Program unit that accesses the database
Crash Recovery John Ortiz. Lecture 22Crash Recovery2 Review: The ACID properties  Atomicity: All actions in the transaction happen, or none happens 
1 CSIS 7102 Spring 2004 Lecture 9: Recovery (approaches) Dr. King-Ip Lin.
TRANSACTION PROCESSING SYSTEM ROHIT KHOKHER. TRANSACTION RECOVERY TRANSACTION RECOVERY TRANSACTION STATES SERIALIZABILITY CONFLICT SERIALIZABILITY VIEW.
1 CPS216: Data-intensive Computing Systems Failure Recovery Shivnath Babu.
Lock-Based Concurrency Control
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
Chapter 20: Recovery. 421B: Database Systems - Recovery 2 Failure Types q Transaction Failures: local recovery q System Failure: Global recovery I Main.
CSCI 3140 Module 8 – Database Recovery Theodore Chiasson Dalhousie University.
Database Systems, 8 th Edition Concurrency Control with Time Stamping Methods Assigns global unique time stamp to each transaction Produces explicit.
CMPT Dr. Alexandra Fedorova Lecture X: Transactions.
Crash Recovery. Review: The ACID properties A A tomicity: All actions in the Xaction happen, or none happen. C C onsistency: If each Xaction is consistent,
Recovery 10/18/05. Implementing atomicity Note, when a transaction commits, the portion of the system implementing durability ensures the transaction’s.
Transaction Management and Concurrency Control
Quick Review of May 1 material Concurrent Execution and Serializability –inconsistent concurrent schedules –transaction conflicts serializable == conflict.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 23 Database Recovery Techniques.
Chapter 19 Database Recovery Techniques. Slide Chapter 19 Outline Databases Recovery 1. Purpose of Database Recovery 2. Types of Failure 3. Transaction.
1 Implementing Atomicity and Durability Chapter 25.
©Silberschatz, Korth and Sudarshan17.1Database System Concepts 3 rd Edition Chapter 17: Recovery System Failure Classification Storage Structure Recovery.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
July 16, 2015ICS 5411 Coping With System Failure Chapter 17 of GUW.
Transactions and Recovery
TRANSACTIONS A sequence of SQL statements to be executed "together“ as a unit: A money transfer transaction: Reasons for Transactions : Concurrency control.
1 Recovery Control (Chapter 17) Redo Logging CS4432: Database Systems II.
Academic Year 2014 Spring. MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 1) Academic Year 2014 Spring.
1 Database Systems CS204 Lecture 21 Transaction Processing I Asma Ahmad FAST-NU April 7, 2011.
Switch off your Mobiles Phones or Change Profile to Silent Mode.
HANDLING FAILURES. Warning This is a first draft I welcome your corrections.
Lecture 12 Recoverability and failure. 2 Optimistic Techniques Based on assumption that conflict is rare and more efficient to let transactions proceed.
CMPT 454, Simon Fraser University, Fall 2009, Martin Ester 294 Database Systems II Coping With System Failures.
Chapter 16 Recovery Yonsei University 1 st Semester, 2015 Sanghyun Park.
CSCI Recovery Control Techniques 1 RECOVERY CONTROL TECHNIQUES Dr. Awad Khalil Computer Science Department AUC.
Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011.
Chapter 10 Recovery System. ACID Properties  Atomicity. Either all operations of the transaction are properly reflected in the database or none are.
Academic Year 2014 Spring. MODULE CC3005NI: Advanced Database Systems “DATABASE RECOVERY” (PART – 2) Academic Year 2014 Spring.
COP 5611 Operating Systems Spring 2010 Dan C. Marinescu Office: HEC 439 B Office hours: M-Wd 1:00-2:00 PM.
Transaction Management Transparencies. ©Pearson Education 2009 Chapter 14 - Objectives Function and importance of transactions. Properties of transactions.
Chapter 17: Recovery System
1 Chapter 6 Database Recovery Techniques Adapted from the slides of “Fundamentals of Database Systems” (Elmasri et al., 2003)
Recovery technique. Recovery concept Recovery from transactions failure mean data restored to the most recent consistent state just before the time of.
Database Recovery Zheng (Godric) Gu. Transaction Concept Storage Structure Failure Classification Log-Based Recovery Deferred Database Modification Immediate.
Jun-Ki Min. Slide Purpose of Database Recovery ◦ To bring the database into the last consistent stat e, which existed prior to the failure. ◦

Database recovery techniques
Database Recovery Techniques
Database Recovery Techniques
DURABILITY OF TRANSACTIONS AND CRASH RECOVERY
Implementing Atomicity and Durability
Recovery Control (Chapter 17)
Database Applications (15-415) DBMS Internals- Part XIII Lecture 22, November 15, 2016 Mohammad Hammoud.
Database Recovery Techniques
File Processing : Recovery
Chapter 10 Recover System
Advanced Operating Systems - Fall 2009 Lecture 8 – Wednesday February 4, 2009 Dan C. Marinescu Office: HEC 439 B. Office hours: M,
Database Systems (資料庫系統)
Database Recovery Techniques
COT 5611 Operating Systems Design Principles Spring 2014
Chapter 16: Recovery System
COT 5611 – Spring 2012 Operating Systems Design Principles
Chapter 10 Transaction Management and Concurrency Control
Database Applications (15-415) DBMS Internals- Part XIII Lecture 25, April 15, 2018 Mohammad Hammoud.
Module 17: Recovery System
Recovery System.
Transaction management
Database Recovery 1 Purpose of Database Recovery
Database Applications (15-415) DBMS Internals- Part XIII Lecture 24, April 14, 2016 Mohammad Hammoud.
Data-intensive Computing Systems Failure Recovery
Concurrency Control.
COP 5611 Operating Systems Spring 2010
Presentation transcript:

COT 5611 – Spring 2012 Operating Systems Design Principles Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 5:00-6:00 PM

Lecture 23 – Wednesday April 4, 2012 Reading assignment: Chapter 9 from the on-line text Last time – Atomicity All-or nothing and before-or-after atomicity Applications of atomicity 12/7/2018 Lecture 23

Today - Cell storage versus journal storage - All-or-nothing atomicity - Before-or-after atomicity 12/7/2018 Lecture 23

Cell storage versus journal storage random-access memory and disk  a set of named, shared, and rewritable cells hard to implement all-or-nothing semantics: storing destroys old data storing data reveals data to the later threads immediately if the result consists of several output values, all of which should be exposed simultaneously it is harder to construct the all-or-nothing action Journal storage: associate with every named variable not a single cell, but a list of cells in non-volatile storage that represent the history of the variable add a layer between the application and the cell storage; this layer appends a new prospective new value 12/7/2018 Lecture 23

12/7/2018 Lecture 23

The state transitions of a journal storage system 12/7/2018 Lecture 23

Read and write procedures: caller_id is the action identifier returned by NEW_ACTION 12/7/2018 Lecture 23

Example: a thread has created a new record with: data_id=A, new_value=75, and client_id=1794. The procedure READ_CURRENT_VALUE will return value 24 for A and ignore versions aborted or pending. 12/7/2018 Lecture 23

An all-or-nothing transfer using journal storage Note: the transaction is not before-or-after It checks if there are enough funds in the credit_account. The order of steps is unconstrained Problems: updates to version history and changes to the outcome must be all-or-nothing. But these can be done by overriding a single cell. 12/7/2018 Lecture 23

Atomicity logs and journal storage Log  An interleaved version of all variables; the information about the update of each data forms a record appended at the end of the log. Easy access to a log, only the pointer to the last record is needed Combine all-or-nothing atomicity of journal storage with the speed of cell storage. Two steps Log  carry out the change in the journal storage Install  change the cell storage by overriding the previous version of each record The log is the authoritative record of the outcome of an action; the cell storage can be reconstructed using the log. The log should reside in non-volatile memory. 12/7/2018 Lecture 23

Types of logs Atomicity log. Allows a crash recovery procedure to undo all-or-nothing actions that didn’t complete, or finish all-or-nothing actions that committed but that didn’t record all of their effects. Archive log. Many uses for archive information: watching for failure patterns, reviewing the actions of the system preceding and during a security breach, recovery from application-layer mistakes fraud control, and compliance with record-keeping requirements. Performance log. Most mechanical storage media have much higher performance for sequential access than for random access. Since logs are written sequentially, they are ideally suited to such storage media. When combined with a cache that eliminates most disk reads, a performance log can provide a significant speed-up. 4. Durability log. If the log is stored on a non-volatile medium (e.g., magnetic tape) that fails in ways and at times that are independent from the failures of the cell storage medium (e.g., magnetic disk) then the copies of data in the log are replicas that can be used as backup in case of damage to the copies of the data in cell storage. Any log that uses a non-volatile medium also helps support durability. 12/7/2018 Lecture 23

Logging configurations 12/7/2018 Lecture 23

Logging protocols Reason for write-ahead-log  log append while install overwrites Log record Id of the all-or-nothing action performing the update The do or redo action  component action that can perform the install if the system crashes before the install. The undo action  component action that can reverse the effects if the system crashes during the install. Four types of log records BEGIN  NEW_ACTION writes this record and records the action id CHANGE  written by the pre-commit phase OUTCOME  written by the COMMIT or by the ABORT procedures END  the final step of an action 12/7/2018 Lecture 23

Example of log records 12/7/2018 Lecture 23

Example: all-or-nothing TRANSFER with logging 12/7/2018 Lecture 23

Recovery procedures for databases in volatile storage We need recovery procedures in case of a system crash The log is not affected as it resides on non-volatile memory Abandon the in-core database and all all-or-nothing actions in progress Two steps: Backwards scan the log and identify all actions with an OUTCOME record showing that the action has been COMMITTED, call them winner actions Forward scan the log and identify REDO actions of every winner whose OUTCOME record shows that the action has been COMMITTED. Reinstall all committed action values in cell storage. The recovery procedure should be idempotent  if the system crashes during recovery we should be able to start again. The ABORT procedure should also be idempotent 12/7/2018 Lecture 23

12/7/2018 Lecture 23

Recovery for databases on non-volatile storage (disk) Large databases cannot be kept in main memory. Access to disk (reads and writes) is slower Installs survive a system crash and we are faced with new problems. A. The recovery procedure must reverse the effects of pending AONA that have installed changes. B. The entire database must be reinstalled, time consuming for large databases!! We assume a write-through cache to avoid complications as the multi-level memory manager may defer writing. To address A: Backward log scan phase look for losers (rather than winners) – a loser is an action in progress at the time of the crash, has no END record. UNDO the CHANGE record of a loser action. Roll back all INSTALLS performed by losersas if the actions of losers never occurred Perform a forward log scan and perform the REDO of all COMMITTED actions Add an END record to all losers Blind write overwrite a data without reference to its previous value. Idempotent operation for UNDO and REDO actions during the recovery. Necessary to make recovery idempotet. 12/7/2018 Lecture 23

12/7/2018 Lecture 23

Undo logging or rollback recovery To address B  undo logging or rollback recovery Additional requirement to avoid to REDO any INSTALLs  perform all INSTALLs before logging it in the OUTCOME record  all INSTALLS are in the non-volatile storage, no need to REDO them UNDO only the INSTALLs of losers and skip the forward scan 12/7/2018 Lecture 23

Summary of atomicity logging Log to journal storage before installing in cell storage For non-volatile storage Only UNDO the INSTALLs of incomplete actions if the INSTALL is carried out before logging the OUTCOME record Only REDO the installs of incomplete actions when logging is done before INSTALL Otherwise do both UNDO and REDO. 12/7/2018 Lecture 23

Before-or-after atomicity Simple serialization  assume each transaction has a unique t_id t_id is from a compact set of integers; at initialization time the system creates a transaction with t_id=0. The rule transaction with t_id=n must wait before reading or writing any data that transaction with t_id=n-1 has either committed or aborted Produces correct results It is too conservative, it does not allow any parallelism 12/7/2018 Lecture 23

12/7/2018 Lecture 23

A transaction needs to know the version history of all variables it affects, it does not need to wait for previous one to complete if they are disjoint, e.g. t4 and t3 12/7/2018 Lecture 23

The mark-point discipline A transaction identifies the data it intends to modify - marks it; creates a pending version of the variable mark point  the instance when a transaction has finished updating the marking all variables it intended to change announces that it has passed its marking point  sets a flag in the OUTCOME record A transaction has to wait until all preceding ones have reached the marking point before it can begin reading variables marked by preceding transactions 12/7/2018 Lecture 23

Skip versions of a variable created by transaction with t_id > id_current_transaction Wait for pending versions of the variable created by transactions with t_id < id_current_transaction 12/7/2018 Lecture 23

Marking becomes a sequence on calls to NEW_VERSION and WRITE_VALUE 12/7/2018 Lecture 23

The system should be initialized with a call to NEW_OUTCOME_RECORD to ensure that there is a previous transaction as required by BEGIN_TRANSACTION 12/7/2018 Lecture 23

More on mark-point discipline The result is guaranteed to be the same as if the transactions were executed sequentially. Potential interaction of before-or-after and all-or-nothing atomicity if pending versions survive a system crash at the restart all PENDING transactions must be identified and marked as ABORTED The discipline never creates deadlock  there is no circular WAIT, a transaction must wait only for preceding ones. If a transaction waits to announce its mark point after the COMMIT or ABORT this becomes simple serialization. Two possible errors: A transaction calls NEW_VERSION after announcing its mark_point WRITE_VALUE attempts to write a value for a variable for which a new version has never been created Example: the TRANFER transaction with using mark point to achieve before-or-after atomicity 12/7/2018 Lecture 23

12/7/2018 Lecture 23

Optimistic before-or-after atomicity Assume that the interference between concurrent transactions is unlikely and allow them to proceed; if interference occurs recover e.g., abort and restart. Increases concurrency. Read-capture startegy 12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23

12/7/2018 Lecture 23