http://www.csee.umbc.edu/courses/461/current/burt/lectures/lec25/recovery.html Stages of transaction Initiation of transaction Partially committed transaction ( not written to phy.

. Buffers ) Failures Committed stage of transaction Aborted transaction Properties of transaction Automicity :- It must be all or none. Correctness :- Consistency should be maintained. Isolation :- Effects of transaction should not be felt outside unless and until committed. Durability :- Once transaction gets committed its effects should be permanent or durable. Serializability :- Transaction must be serializable. Schedules generated by transaction must be serialazible. If volatile memory fails due to above aborted transactions then there are three mechanisms or recovery. Log Based Recovery Shadow Paging Techniques

Check Point Mechanism Log Based Recovery Also called as journals. Log is nothing but a simple data file, maintained on stable storage. It contains history to the accesses of database. History means tran. No., Before image, After image, time, User Id., Record Id. Etc. ). All such files are maintained by DBMS itself. Normally these are sequential files. Recovery has two factors Rollback ( Undo )and Roll forward ( Redo ). Two types of log Write Ahead Log ( Writes in physical buffer first ) Differed Log ( Writes in log file first ) Check - Point If millions of transactions at a point then for recovery the method is check point mechanism. It is an extension to a log based mechanism. It is a decided interval at decided frequency. The contents ( may be in incomplete stage ) are dumped on non volatile storage. There is a separate check-point record in log file which have all contents after say 1 hour. It is a efficient mechanism. No need of going by to history. Database administrator will look after the period of checkpoint. Shadow Paging Technique A page in memory is a segment which is accessible. It is a logical concept. Page table is an index of pages ( where pages are on HD, kept in this table ). As transaction goes on, concurrent page table gets changed. Shadow page table is a copy current page table which is maintained on stable memory. It is alive during the life of transaction only. And current page table become shadow page for next transaction. Shadow paging technique leads to problem of garbage and garbage collection problem (garbage means wastage of space in memory. ) Utilities Defrag Garbage collection routine Concurrency Control When many transactions are being executed simultaneously then it is called as concurrent transactions. Concurrency is required to increase time efficiency and to utilize resources more freely. Concurrency control is required to maintain consistency of data and to avoid Phantom phenomena. Concurrency control mechanisms

Locks Time stamp based mechanism Optimistic scheduling Multiversion technique Locks : Lock is nothing but a variable associated with data item and which gives status of data item whether it is assessable or not. Lock indicates binary value i.e. open or closed / on or off. Locks are of different types such as Exclusive Lock : No one can read and write the value of the data item except the owner. Shared Lock : It is also called as read only lock where other transaction can refer the value but can not write. Wait Lock : It is put when data item is locked by some other transaction. A separate wait queue is maintained to decide the order. There are two protocols are used to implement the locks Two Phase Protocol : It is having two phases in the locking mechanism. 1. Growing Phase : In which transaction obtains locks may not release. 2. Shrinking Phase : in which transaction may release locks but may not obtain. Intention locks : it provides explicit locking at the lower lever of the tree (finer granularity) and intention locks on all ancestors. Time stamp based mechanism : A serial order is created among the concurrent transactions by assigning to each transaction a unique non decrementing number, normally the system clock value, at the start of the transaction is assigned hence the name time stamp ordering. This value can used in deciding the order in which conflict between two transactions can be resolved. It enforces serialisability through chronological order of the time stamp of concurrent transactions. A conflict occurs when an older transaction tries to read a value written by a younger transaction or older transaction tries to modify a value already read or written by a younger transaction. Optimistic Scheduling : It assumes that all data items can be successfully updated at the end of the transaction and to read in data values without locking. Reading is done and if any data item is found inconsistent with respect to the value in, at the end of the transaction then the transaction is rolled back. Optimistic scheduling has 3 steps. Read phase : various data items are read and stored in temporary local variables. All operations are performed in these variables without actually updating the database. Validation phase : All concurrent data items in data base are checked. Any change in the value causes the transaction rollback. Write phase : If second phase is passed, the transaction gets committed. Optimistic scheduling doesn't use any locks hence deadlock free. However problem of starvation of popular data item may occur. Multiversion Technique : In MVT each write and update of a data item is achieved by making a new copy or version of that data item. This is also called as time domain addressing scheme. It follows accounting principle of never overwrite a value. History of the evolution of data item values is recorded in the database. In case of read operation DBMS selects one of the versions for processing. There are two major problems with MVT 1. it is little bit slower in operations 2. Rollbacks are expensive

Crash recovery
Transactions (or units of work) against a database can be interrupted unexpectedly. If a failure occurs before all of the changes that are part of the unit of work are completed and committed, the database is left in an inconsistent and unusable state. Crash recovery is the process by which the database is moved back to a consistent and usable state. This is done by rolling back

incomplete transactions and completing committed transactions that were still in memory when the crash occurred (Figure 2). When a database is in a consistent and usable state, it has attained what is known as a "point of consistency". Figure 2. Rolling Back Units of Work (Crash Recovery)

A transaction failure results from a severe error or condition that causes the database or the database manager to end abnormally. Partially completed units of work, or UOW that have not been flushed to disk at the time of failure, leave the database in an inconsistent state. Following a transaction failure, the database must be recovered. Conditions that can result in transaction failure include:

A power failure on the machine, causing the database manager and the database partitions on it to go down A hardware failure such as memory corruption, or disk, CPU, or network failure. A serious operating system error that causes DB2(R) to go down

If you want the rollback of incomplete units of work to be done automatically by the database manager, enable the automatic restart (auto restart) database configuration parameter by setting it to ON. (This is the default value.) If you do not want automatic restart behavior, set the auto restart database configuration parameter to OFF. As a result, you will need to issue the RESTART DATABASE command when a database failure occurs. If the database I/O was suspended before the crash occurred, you must specify the WRITE RESUME option of the RESTART DATABASE command in order for the crash recovery to continue. The administration notification log records when the database restart operation begins. 7 If crash recovery is applied to a database that is enabled for forward 7 recovery (that is, the logarchmeth1 configuration parameter 7 is not set to OFF), 7 and an error occurs during crash recovery that is attributable 7 to an individual table space, that table space will be taken offline, and cannot 7 be accessed until it is repaired. 7 Crash recovery continues. 7 At the completion of crash recovery, the other table spaces in the database will be 7 accessible, and connections to the database can be established. 7 However, if the table space that is taken offline is the table space that contains the 7 system catalogs, it must be repaired before any connections will be permitted.

Shadow paging
In computer science, shadow paging is a technique for providing atomicity and durability (two of the ACID properties) in database systems. A page in this context refers to a unit of physical storage (probably on a hard disk), typically of the order of to bytes. Shadow paging is a copy-on-write technique for avoiding in-place updates of pages. Instead, when a page is to be modified, a shadow page is allocated. Since the shadow page has no references (from other pages on disk), it can be modified liberally, without concern for consistency constraints, etc. When the page is ready to become durable, all pages that referred to the original are updated to refer to the new replacement page instead. Because the page is "activated" only when it is ready, it is atomic. If the referring pages must also be updated via shadow paging, this procedure may recurse many times, becoming quite costly. One solution, employed by the WAFL file system (Write Anywhere File Layout) is to be lazy about making pages durable (i.e. write-behind caching). This increases performance significantly by avoiding many writes on hotspots high up in the referential hierarchy (e.g.: a file system superblock) at the cost of high commit latency. Write ahead logging is a more popular solution that uses in-place updates.[citation needed] Shadow paging is similar to the old master-new master batch processing technique used in mainframe database systems. In these systems, the output of each batch run (possibly a day's work) was written to two separate disks or other form of storage medium. One was kept for backup, and the other was used as the starting point for the next day's work. Shadow paging is also similar to purely functional data structures, in that in-place updates are avoided.

Log-Based Recovery
The most widely used structure for recording database modifications is the log. The log is a sequence of log records and maintains a history of all update activities in the database. There are several types of log records. An update log record describes a single database write:

Transactions identifier. Data-item identifier. Old value. New value.

Whenever a transaction performs a write, it is essential that the log record for that write be created before the database is modified. Once a log record exists, we can output the modification that has already been output to the database. Also we have the ability to undo a modification that has already been output to the database, by using the old-value field in the log records. For log records to be useful for recovery from system and disk failures, the log must reside on stable storage. However, since the log contains a complete record of all database activity, the volume of data stored in the log may become unreasonable large.

Deferred Database Modification

The deferred-modification technique ensures transaction atomicity by recording all database modifications in the log, but deferring all write operations of a transaction until the transaction partially commits (i.e., once the final action of the transaction has been executed). Then the information in the logs is used to execute the deferred writes. If the system crashes or if the transaction aborts, then the information in the logs is ignored.

Immediate Database Modification

The immediate-update technique allows database modifications to be output to the database while the transaction is still in the active state. These modifications are called uncommitted modifications. In the event of a crash or transaction failure, the system must use the old-value field of the log records to restore the modified data items.

Checkpoints
When a system failure occurs, we must consult the log to determine those transactions that need to be redone and those that need to be undone. Rather than reprocessing the entire log, which is time-consuming and much of it unnecessary, we can use checkpoints:
1. Output onto stable storage all the log records currently residing in main memory. 2. Output to the disk all modified buffer blocks. 3. Output onto stable storage a log record, <checkpoint>.

Now recovery will be to only process log records since the last checkpoint record.

Shadow Paging
Shadow paging is an alternative to log-based recovery techniques, which has both advantages and disadvantages. It may require fewer disk accesses, but it is hard to extend paging to allow multiple concurrent transactions. The paging is very similar to paging schemes used by the operating system for memory management. The idea is to maintain two page tables during the life of a transaction: the current page table and the shadow page table. When the transaction starts, both tables are identical. The shadow page is never changed during the life of the transaction. The current page is updated with each write operation. Each table entry points to a page on the disk. When the transaction is committed, the shadow page entry becomes a copy of the current page table entry and the disk block with the old data is released. If the shadow is stored in nonvolatile memory and a system crash occurs, then the shadow page table is copied to the current page table. This guarantees that the shadow page table will point to the database pages corresponding to the state of the database prior to any transaction that was active at the time of the crash, making aborts automatic. There are drawbacks to the shadow-page technique:

Commit overhead. The commit of a single transaction using shadow paging requires multiple blocks to be output -- the current page table, the actual data and the disk address of the current page table. Log-based schemes need to output only the log records. Data fragmentation. Shadow paging causes database pages to change locations (therefore, no longer contiguous. Garbage collection. Each time that a transaction commits, the database pages containing the old version of data changed by the transactions must become inaccessible. Such pages are considered to be garbage since they are not part of the free space and do not contain any usable information. Periodically it is necessary to find all of the garbage pages and add them to the list of free pages. This process is called garbage collection and imposes additional overhead and complexity on the system.