Kszlt a HEFOP3.3.1P.20040600181.0 projekt keretben

1
Készült a HEFOP-3.3.1-P.-2004-06-0018/1.0 projekt
keretében
A szakirány neve

• DATABASE MANAGEMENT SYSTEMS

Modul 4 4 meeting Recovery systems 2 lectures
Az Európai Szociális Alap támogatásával
2
OUTLINE

• Why recovery is needed defense against failures
• ACID -which units?
• Recovery system A and D
• Backgrounds for logging
• shadowing
• Logging techniques
• - Deferred (REDO)
• - Immediate (UNDO, REDO)
• Shadow paging
• Real systems

3
WHY recovery is needed

• There is a long way to read and write data.
  During that time several error may occur.

4
WHY recovery is needed

• Error types
• Machine
• - software
• - hardware
• - power
• Transaction or system errors
• - Logical (deviding by 0, users concillation)
• - Data not found
• - Transaction manager
• .....
• Disk crash
• Other hardware problems
• - catasrophy... (fire, ...)

Recovery manager
Transaction manager
Backup
5
Why recovery is needed?

• ? System may fail due to several reasons
  such as errors or system crashes.
• ? Then a process, called recovery process is
  used to correct the possible inconsistency of
  the database.

6
Transactions ACID porperties - DBMS UNITS

• Atomicity
• Consistency
• Isolation
• Durability

Recovery manager
Transaction manager
7
Recovery Systems

• Concurrency-control
• Consistency
• Isolation
• Recovery
• Durability
• Atomicity

8
Recovery systems

• Main ideas
• ? Logging based
• - actions are administered in a log-file
• - after a crash data are recovered and put in
  
• to the DB
• ? Shadow
• A work copy is created-after commit a pointer
  points to the new version

9
Recovery systems background of a logging

• START

Temporary storage in memory
BEGIN WRITE INTO LOG
WRITES COMPLETED IN LOG FILE
10
Recovery systems background of shadowing

• POINTER

POINTER
OLD COPY OF DATABASE
NEW COPY OF DBASE modifications
OLD COPY OF DATABASE
CRASH-POINTER POINTS TO THE OLD SHADOW
COMMIT-RESET POINTER- IT POINTS TO NEW DB
11
Recovery systems background of shadowing

• The idea of shadowing is simple. You probably
  have already used it, even though you were not
  aware of it. Consider the case of text editors.
  When you close the document, you usually get a
  message asking if you would like to save. When
  you answer yes, you are resetting a pointer.
• Shadowing a recovery technique. A simple shadow
  method is to keep the original file untouched by
  the application and let the application work on a
  copy. The original file is referred to as the
  shadow. After commit, the copy becomes the new
  instance.

12
Recovery systems

• DB should be always consistent

DB concurrent access
A T OM I C I T Y DU RAB I L I TY
Transaction manager
CON SI S T E NCY I SO LAT I ON
No failor Schedules Serializable
schedules Concurrency control Locking
protocol, Timestamping
Failors Recoverable schedules Avoiding
cascading rollback Log files Shadow
tables Recovery
13
Ensuring recoverability

• Actions during normal execution time

Journal file Logging Log-file
Shadow technique Shadow-paging
Actions after failor/crash
UNDO (effect the transaction would have never
run) REDO (effect the transactions would have
start again
?
14
What does it mean? I.

• Journal another name for a log file.
• Loggingdocumenting the history of transactions,
  using so called log-files
• Non-volatile storage storage devices such as
  disks and tapes, whose content survives system
  crashes.
• Page data are organized in pages in blocks. One
  trnasferable unit is a block
• Pointer a data structure, consisting the
  physical address of a data and the location where
  they are found in the physical database.

15
What does it mean?
II.

• Actions after failor/crash
• REDO transaction
• an operation during which all data in the
  physical database are overwritten by the value
  given by the transaction.
• UNDO transaction
• an operation during which all data in the
  physical database are overwritten by the previous
  value of the data, the value that data had,
  before it has been overwritten by the
  transaction.

16
Ensuring recoverability

• Storage

MEMORY In case of crash content will be lost
DISK, TAPE Survive, but...
SAFE STORING
WHERE -Remote -Local
WHEN DB- daily Log-file-/minute
COPIES
17
Recovery-Stable storage-a dream ?

• An abstraction of non-volatile storage which
  survives catastrophes.
• This can be approached by storing data in
  separate and isolated non-volatile storage.

18
Recovery-Logging technique

• Logging techniques
• Deferred modifications are supposed to
  carry out in the memory, and put the
  database after commit
• Immediate -Modifications can be made in
  the database at any time (not agressive NA)
• - Modifications FORCED to be written
  in the database IMMEDIATELY (agressive
  A)
• Consequence different types of log files
  needed

19
Recovery-Logging technique

• ltSTART, TRgt recording that a transaction with
  identifier TR enters into the system. (This
  briefly referred to as a, briefly a start
  record.)
• ltTR, DID, NEW-VALUE gt, or
• ltTR, DID, OLD-VALUE, NEW-VALUE gt recording that
  transaction TR writes data item with identifier
  DID, and the previous value of that data is
  OLD-VALUE, and the new value of data identified
  by DID is NEW-VALUE.
• ltCOMMIT, TRgt recording that transaction
  identified by TR is committed.

20
Recovery-Logging technique-Deferred

• What type of files are needed in the log file?
• Old values are not stored
• ltTi, STARTgt
• ltTi, X, NEW-VALUEgt
• ltTi, COMMITgt
• ltCHECKPOINTgt

21
Recovery Deferred modification (model)

• What is happening?
• TR starts
• 3. write(X)
• 5. write(Y)
• .
• .
• .
• k. Partially committed
• ( operations are carried out in the memory)
• k2. Log-file is saved onto non volaitle
  storage
• k3. Modifications in DB
• ..
• kn. Transaction commits
• COMMIT POINT

22
Recovery Deferred modification

• PROTOCOL (outline)
• REDO(Ti) from ltTi, X, NEW-VALUEgt, blindly
  rewrites the values of X in the database by the
  NEW-VALUE
• REDO(Ti) ONLY for Ti having both
• ltTi, STARTgt, ltTi, COMMITgt
• in the log record
• No UNDO actions are needed
• Order with regard to the start records

23
Differed modification with checkpoint

• Algorithm
• 1. AnalysisDuring this, if a ltCOMMIT, Tkgt record
  is found, then Tk is put on the REDO list.
• 1.1 If a ltSTART, Tkgt record is found with a
  transaction which is not in the REDO list, then
  it is skipped.
• 1.2a If a ltCHECKPOINT, ACTIVE-LISTgt record is
  found, then continue backward browsing and find
  all ltSTART, Tkgt record such that Tk is in ACTIVE
• 1.2b If a ltCHECKPOINTgt record is found, then
  continue backward browsing and find all ltSTART,
  Tkgt record such that Tk is in the REDO list

24
Differed modification with checkpoint

• Algorithm cont.
• Step 2
• REDO actions are applied to data affected by
  transactions being on the REDO list all data is
  set to NEW-VALUE in the same order it happened.
• the deferred modification technique, checkpoints
  allows the log file to be shortened at
  appropriate times.

25
Recovery Deferred modification

• Example
• T5
• T1
• T3
• T2
• T4
• time
• CHECKPOINT FAILOR

26
SOLUTION

• REDO(T3), REDO(T2)
• Transactions T4, T5 might be restarted

27
Recovery NA Immediate modification

• What type of files are needed in the log file?
• Old values are also stored
• ltTi, STARTgt
• ltTi, X, OLD-VALUE, NEW-VALUEgt
• ltTi, COMMITgt
• ltCHECKPOINT, active-listgt

28
Recovery NA Immediate modification
29
Recovery NA Immediate modification

• PROTOCOL outline
• 1. ltCHECKPOINT, list gt
• Helps to identify, up to what point the log
  must be checked
• 2.
• UNDO(Ti) actions are needed first
• from ltTi, X, OLD-VALUE, NEW-VALUEgt, blindly
  rewrites the values of X in the database by the
  OLD-VALUE
• UNDO(Ti) for those transactions having only
  ltSTART, Tigt record wothout ltCommit, Tigt record in
  the log
• Order opposite with regard to the start records
• 3.
• REDO(Ti) actions are carried out second from
  ltTi, X, NEW-VALUEgt, blindly rewrites the values
  of X in the database by the NEW-VALUE
• REDO(Ti) ONLY for Ti having both
• ltTi, STARTgt, ltTi, COMMITgt
• in the log record
• Order with regard to the commit records

30
Recovery NA Immediate modification with
checkpoint

• Algorithm
• Step 1 Analysis The log file is browsed
  backwards
• 1.1 If ltCOMMIT, Tk gt record is found, then Tk is
  appended to the REDO list. If ltSTART, Tk gt is
  found, and Tk is not in the REDO list, then it
  is appended to the UNDO list. Otherwise Tk is
  appended to the WAIT list.
• 1.2 If ltCHECKPOINT, ACTIVE gt is found then each
  element of ACTIVE has to be checked, the
  browsing has to be continued to the start point
  of each. If ltSTART, Tk gt is found for a
  Tk?ACTIVE, and Tk is not in the REDO list then
  it is appended to the UNDO list. If all the start
  records have been found, then browsing is ready.

31
Recovery NA Immediate modification with
checkpoint

• Step 2 (recovery)
• UNDO actions are applied to data affected by
  transactions being on the UNDO list, in the
  reverse order with respect to the real time all
  data are reset to the OLD -VALUE written by
  transactions being in the UNDO list.
• REDO actions are applied to data affected by
  transactions being on the REDO list
• As with the deferred modification technique,
  checkpoints allows the log file to be shortened
  at appropriate times.

32
Recovery NA Immediate modification

• Example
• T5
• T1
• T3
• T2
• T4
• time
• CHECKPOINT FAILOR

33
Recovery Deferred - Immediate modification

• A part of a log-file is
• given as follows
• ltT6, STARTgt
• ltT6, A, 500, 370gt
• ltCHECKPOINT, T6gt
• ltT7, STARTgt
• ltT7, C, 410, 85gt
• ltT6, B, 400, 90gt
• ltT6, COMMITgt
• ltT7, A, 370, 250gt
• ltT8, STARTgt
• ltT7, COMMITgt
• ltT8, B, 90, 800gt
• ltT8, COMMITgt

? Give the initial values of A, B, C. ? Give
the values of A, B, C after step 11. ? Describe
how the system can be reover if a crash occur
between 1-2, 2-3, 3-4, etc. ? Which logging
technique is applied? ? Rewrite that file to
the other modification technique and answer
questions a.) through d.) using this new file.
34
Recovery

• Problem

• In case of immediate modification technique
  cascading rolback can be avoided. So only
  values written by comitted transactions are
  suggested to read.
• Solution

35
Agressive , UNDO protocol

• What types of records would you use?
• WHat actions has to be taken during the recovery?
• IN what order?

36
Recovery systems background of shadowing

• POINTER

POINTER
OLD COPY OF DATABASE
NEW COPY OF DBASE modifications
OLD COPY OF DATABASE
CRASH-POINTER POINTS TO THE OLD SHADOW
COMMIT-RESET POINTER- IT POINTS TO NEW DB
37
Recovery systems Shadowing-Problem

• The pointer has to be reset AFTER COMMIT point.
  There is NO ACCESS to the original versionof the
  database (old copy). In case of a failor, the
  pointer points to the original version.
• Text editors (word etc.) Do you want to save..?
• Several copies can be used
• Drawback in this form it can not be applied to
  big databases

38
Recovery systems Shadowing

• Shadow page in case of a database shadowing can
  not be used directly.
• Shadow pages are pointer tables, pointing to the
  stored data. The original pointer tables are kept
  untouched by the application, which works on a
  copy. After the commit, the copy becomes the new
  instance.

39
Recovery systems Shadowing-Paging
40
Real world recovery systems

• More complicated than the models described
  here.The differences are because of two reasons
• ? From the point of view of data transfer
• - data reside on pages, and pages are packaged
  into a blocks of data that are transferred
  between the memory and the physical database.
• - another transfer, data are usually put from the
  memory to the separated workplace for each
  transaction and vice versa.
• -real write process rather complicated it is not
  easy to decide, which page has to be put back to
  the database
• - committed parts
• - dirty pages
• From the point of view of transactions
• - committed, not committed, aborted or
  rollbacked.

41
Real recovery systems - ARIES

• The most widely used log based recovery method is
  called ARIES. The ARIES recovery algorithm
  consists of three steps. These steps are very
  similar to the ones we discussed above analysis
  step, redo step and undo step. However, each step
  is more complicated and is also slightly
  different (due to the differences (i) and (ii)
  above ).
• Recovery systems using ARIES may also be
  different from the point of view of timing of the
  write actions as well.
• There is e.g. the so called Write-ahead Logging
  technique (referred by the abbreviation WAL),
  where pages are forced to be written to the
  database as soon as possible. In case of log
  based recovery systems, it may be modeled by the
  immediate modification technique.
• Systems using not so agressive writing policy
  than WAL, may modeled by the deferred
  modification technique.

42
Real recovery systems

• Systems using not so agressive writing policy
  than WAL, may modeled by the deferred
  modification technique.
• Recovery systems can depend also on the
  concurrency management.
• For example a variant of ARIES with WAL schemes
  are used by IBM DB2, Informix, Microsoft SQL
  Server, Oracle and Sybase (in alphabetical
  order). Some of these systems allow the use of
  mixed versions. From the point of view of
  concurrency management, for read only
  transactions they use 2-phase protocol, for
  read-write transactions they use rigorous 2 phase
  protocol (in this version of 2 Phase protocol,
  all locks are held until the transaction commits
  ), etc. The type of a transaction can be set
  through SQL statements.

43
Summary

• A computer system is subject to failure
• The defense system is an integral part of the
  databaserecovery unit/system.
• Recovery techniques.
• Logging technique In case of logging, a
  log-file is created in the memory during
  run-time.
• - deferred modification technique database is
  unchanged up to the time the commit record is
  written in the log, and the log is saved onto a
  nonvolatile storage. -gt REDO ONLY
• -immediate modification technique database
  could be changed right after the log file is
  written onto a non-volatile storage. That is, a
  transaction can modify the database even without
  reaching its commit point UNDO and REDO
• Shadow paging the active part of a database is
  copied, and the new version of this part will be
  validated only if no failure accurs.
• In spite of that fact, that real recovery systems
  are different and more complicated, the models
  presented in this chapter describe well the
  manner of real recovery systems at a conceptual
  level.