Chapter 15 Recovery. Topics in this Chapter Transactions Transaction Recovery System Recovery Media...
-
Upload
kelley-lloyd -
Category
Documents
-
view
229 -
download
4
Transcript of Chapter 15 Recovery. Topics in this Chapter Transactions Transaction Recovery System Recovery Media...
Chapter 15
Recovery
Topics in this Chapter
• Transactions• Transaction Recovery• System Recovery• Media Recovery• Two-Phase Commit• SQL Facilities
Recovery
• Recovery means to restore the database to a correct state after some failure has rendered the current state incorrect or suspect
• Recovery is based on redundancy (!)• To recover a database, the source for the
recovery must be information that has been stored redundantly somewhere else
• Physical redundancy is desirable; logical redundancy is not
Recovery
“Manually:”
Make a backup copy of the database
Make change 1, change 2, etc.
If any problem arises, go back to the backup copy and start again
Everything OK, discard the backup
Recovery
A DBMS is expected to provide support
DBMS can do it more efficiently
DBMS can do it more safely
User must play a role by defining transactions
Transactions
• A transaction is a logical unit of work• It begins with BEGIN TRANSACTION• It ends with COMMIT or ROLLBACK• The transaction manager is sometimes known as
the TP Monitor (transaction processing monitor)• Atomicity: The manager guarantees that if any
part of the transaction fails, the entire transaction will be rolled back, and the database set to its state before BEGIN
Transaction Manager
• COMMIT signifies transaction has completed successfully
• ROLLBACK signifies transaction has encountered an error
• Implicit ROLLBACK: if the transaction manager does not receive an explicit COMMIT, it will default to ROLLBACK
• After COMMIT or ROLLBACK, a message is returned to the user
Example
• Add a new employee with two dependents to the database
• Add employee to EMPLOYEES• Add dependents to DEPENDENTS• Must do it “atomically” since “partial”
success produces inconsistency– Add dependent(s) without adding
employee– Add one dependent, add employee
with 1 dependents
Example
// begin transaction
try
stmt.executeUpdate(<insert employee>);
stmt.executeUpdate(<insert employee>);
stmt.executeUpdate(<insert employee>);
stmt.executeUpdate(“COMMIT”);
}
catch (SQLException ex)
stmt.executeUpdate(“ROLLBACK”);
}
// end transaction
no explicit “begin transaction” required
transaction ends with COMMIT or ROLLBACK
Transactions
• Atomicity of transaction is user’s responsibility
• Atomicity of statements is DBMS responsibility
UPDATE EMPLOYEESSET SALARY = SALARY*1.1 WHERE DEPT# = ‘K43’
• Can’t quit in the middle with DB partially updated
Transactions
• Changes are temporary (kept in buffers) until COMMIT or ROLLBACK
• COMMIT: makes temporary changes permanent
• ROLLBACK: discards the changes• COMMIT or ROLLBACK will close an
open CURSOR
Transactions
• The transaction is the “unit of recovery”
• When a transaction is committed, the changes are permanent even if the system subsequently crashes
• DBMS must provide for this
Recovery Log
• A recovery log or journal keeps the before and after state for each transaction
• An active (online) log is kept for immediate recovery of recent activity
• An archive log is kept offline for more extensive recovery requirements
• Atomicity must be at the statement level (set processing)
• Transactions must not be nested
Correctness
• The database must always be consistent, which is defined as not violating any known integrity constraint
• The DBMS can enforce consistency, but not correctness
• The DBMS must assume the correctness of transactions
• If the transaction is correct, and the prior state of the database was correct, then the resulting state of the database will be correct
COMMIT Point
• Database updates are kept in buffers, and written to disk after COMMIT
• The log must be written before COMMIT (“write-ahead” log rule) so the database can recover if the system crashes after COMMIT but before disk writing is complete
• On COMMIT (defaults to) all database positioning is lost and tuple locks released
• This is the COMMIT point, or synchpoint
Transaction Recovery
• ROLLBACK will return the database to the previous COMMIT point
• In large multiprocessing environments, transactions can “steal” buffer space from their predecessors, which can cause early disk writing
• Similarly, the DBMS can use a “no force” policy, meaning that writing to disk is held until additional transactions complete
The ACID Properties
• Atomicity – Transactions are atomic• Correctness (f/k/a “Consistency”) –
Transactions transform a correct state of the database into another correct state
• Isolation – Transactions are isolated from one another
• Durability – Once a transaction commits, its updates persist
Local Failures
begin programbegin transaction
. .commit
endbegin transaction
. .rollback
endbegin transaction
. .commit
endetc.
end program
first transaction OK
second transaction “cancelled” (local failure)
third transaction OK
user works from log of cancelled transactions to fix and/or reprocess
Global Failures
System failure
Power failure
Memory failure
Communication failure
(soft crash)
Media failure
(hard crash)
Global Failures
Suppose a memory failure--buffers lost, transactions in process lost
transaction i i + 1 . . i + k
i + k + 1 . . i + m
i + m + 1
committed, written to disk
in process, not committed
committed, in disk buffers
System Recovery
• The system takes checkpoints automatically• Upon system restart after a crash, transactions
that finished successfully prior to the crash are redone, and those that were not complete prior to the crash are undone
• REDO and UNDO logs• ARIES: Algorithms for Recovery and Isolation
Exploiting Semantics – recovery by repeating history – REDO first, then UNDO
Fig 15.3 Five transaction categories
Fig 15.3
Five transaction categories
At intervals (e.g., after n log entries)
1) Write all buffers
2) Write “checkpoint record” of all transactions in process
3) Continue to log all activity
Fig 15.3
Five transaction categories
T1: transactions completed and written to disk before last checkpoint
T2, T4: transactions completed but not written to disk at time of last check point
T3, T5: transactions in process at time of failure
Categories
Fig 15.3
Five transaction categories
“OK” must be repeated--committed but not written to disk
rollback (never completed)
Recovery
System processes the checkpoint record to find all transactions appearing in last checkpoint and makes an UNDO listSystem searches (forward) through the log starting from the checkpoint and
if a begin transaction is found add the transaction to UNDO listif a commit log entry is found for a transaction, move it from UNDO to REDO
Then, when finished UNDO is a list of types 3 and 5REDO is a list of types 2 and 4
Media Recovery
• Disk failure can corrupt the persistent database
• The database must be restored from backup
• The transaction logs can be used to roll forward from the backup point, to recover as much of the recent transaction history as possible
Two-Phase Commit
• Required for distributed or heterogeneous environments, so that correctness is maintained in case of failure during a multi-part COMMIT
• Prepare phase has all local resource managers force logs to a persistent log, local managers reply ok or not
• Commit phase – if all replies are ok, the coordinator commits, and orders the local managers to complete the process; otherwise all are ordered to ROLLBACK
Two-Phase Commit
Database X: DB2
Database Y: Oracle
transaction
fragment at node B
fragment at node C
transaction at
node A
or
each DBMS maintains its own recovery log
Two-Phase Commit
Transaction completes, issues COMMIT (system wide)
Phase I:System coordinator process tells each participant to “get ready” i.e., each log is written to disk, therefore each participant can go “either way”If coordinator gets OK from all participants, it writes a physical record to its log saying COMMITOthewise, coordinator writes physical record saying ROLLBACK
Two-Phase Commit
Phase II:
Notifies participants to do whichever it decided (they must)
If there is a failure during Phase II, system can find the decision record
If failure during Phase I, or it can’t find the decision record, it becomes a ROLLBACK
SQL Facilities
• START TRANSACTION < option commalist > ;
• The option commalist specifies an access mode, an isolation level, or both
• Access mode can be READ ONLY or READ WRITE
• Isolation level sets isolation from other transactions
• SAVEPOINT establishes a point within a transaction to which you can ROLLBACK