CREATE THE DIFFERENCE

Back ups and Recovery

CREATE THE DIFFERENCE

Aims• This lecture aims to cover

– Back ups– Transaction logging– Security threats

CREATE THE DIFFERENCE

How can Data be Protected?• Dual recording of data (mirrored systems)

– Considerations• Requires a second hardware/software system.• Provides the best but for a large system, the most expensive

system• Periodic Back ups

– Considerations• time interval between dumps• time taken to perform the dump• time taken to perform the recovery• database integrity units• on-line back-up capability

• Transaction Logging– Considerations

• fault tolerance• ease of recovery• additional storage

• Database Security– 10 major threats and prevention.

CREATE THE DIFFERENCE

• How best to safeguard the system– Use transaction logging alone?

• a crash after a significant period of time will result in an extended time for recovery

– Use high frequency back ups?• Time consuming

– A combination of logging and back ups?• most systems use this approach because the recovery time

is kept short and time spent on backing up is reduced.

Safeguards

CREATE THE DIFFERENCE

Back ups• A back up will usually comprise

– A back up of the entire system (database, reports, forms programs etc.

– A back up of the data log file.– Provision of offsite storage for back ups– Provision for resilience in the event of system

hardware failure.

CREATE THE DIFFERENCE

Example of a back up system

Tuesday FridayThursdayMonday Wednesday

daily back up of database

changes to data

PROBLEM OCCURS

no log file present

CREATE THE DIFFERENCE

Recovery• Insert back up of database from Wednesday

evening– As the problem occurred halfway through Thursday, the

last back up of the database was on Wednesday evening so the transactions on Thursday will be lost.

• Issues– If the database is large, the time taken to back up could make this option unfeasible. – Transactions are lost.

CREATE THE DIFFERENCE

Example of a back up system

Tuesday FridayThursdayMonday Wednesday

weekly back up of database

Transaction loggingactivated

growth of log

PROBLEM OCCURS

CREATE THE DIFFERENCE

Recovery• Insert weekly back up of database

– Rollforward log• In theory, this would work well with no loss of data.

• Problems– The log file is not backed up so if it is corrupted all the

data since the weekly back up would be lost.

CREATE THE DIFFERENCE

Example of a back up system

Tuesday FridayThursdayMonday Wednesday

weekly back up of database

daily back up of log file

growth of log

PROBLEM OCCURS

CREATE THE DIFFERENCE

Recovery• Insert weekly back up of database

– Rollforward log using the backup from Monday evening

– Rollforward log using the backup from Tuesday evening

– Rollforward log using the backup from Wednesday evening

– Rollforward log on Thursday.• Problems

– As the problem occurred halfway through Thursday, the last back up of the log file was on Wednesday evening. As long as all the log back ups are intact, the only possible risk is with the log on Thursday which may or may not have been corrupted.

CREATE THE DIFFERENCE

The Rollback command• If a database log is used, the database can be

rolled back to when the log was started. • It is possible to start a log to cover a series of

commands eg. at a month or year end. If one command fails, the whole series can be rolled back to maintain data integrity.

CREATE THE DIFFERENCE

Transaction Properties Revision• The ACID test:

– Atomicity: a transaction must be an atomic unit of processing – either all parts are performed or it is not performed at all.

– Consistency: execution must take the database from one correct state to another

– Isolation: the updates of a transaction must visible to or useable by other transactions until it is committed (solves the temporary update problem)

– Durability or Permanency: if a transaction changes the database and is committed, the changes must never be lost because of subsequent failure

CREATE THE DIFFERENCE

Transaction manager• The transaction manager provides atomicity• COMMIT TRANSACTION (Commit)

– signals successful end of transaction– the database should be (or is) in a consistent state– all the updates can be made permanent

• ROLLBACK TRANSACTION (Rollback)– signals unsuccessful end of transaction– all updates made by the logical unit of work must be

undone

CREATE THE DIFFERENCE

Transaction logging• Transactions are tracked by using logs• Transaction records

– transaction ID– type of log (start of transaction, insert, update..)– identifier of the data item affected– before image (value before change)– after image (value after change)– log management information (pointers)

• Logs can also be used for performance monitoring and auditing

CREATE THE DIFFERENCE

Transaction logging

Tid Time Operation Object Before Image After Image PPtr NPtrT1 10:12 START 0 2T1 10:13 UPDATE STAFF SL21 (old value) (new value) 1 8T2 10:14 START 0 4T2 10:16 INSERT STAFF SG37 (new value) 3 5T2 10:17 DELETE STAFF SA9 (old value) 4 6T2 10:17 UPDATE PROPERTY PG16 (old value) (new value) 5 9T3 10:18 START 0 11T1 10:18 COMMIT 2 0

10:19 CHECKPOINT T2, T3T2 10:19 COMMIT 6 0T3 10:20 INSERT PROPERTY PG4 (new value) 7 12T3 10:21 COMMIT 11 0

CREATE THE DIFFERENCE

System Recovery• System failure

– the contents of main memory are lost– the precise status of transactions in progress is unknown– these transactions have to be UNDONE (rolled back) on system start

up• The log records are used to write the before-image of the affected fields, and restore

the database to its state prior to the transaction’s start. • Applied in the reverse order to which they were written to the log

– transactions that do complete but do not manage to have the updates transferred to disk must be REDONE (rolled forward)

• Use the after-image log records for the transaction, • In the order in which they were written to the log

• Check points determine whether a rollback or roll forward is required

• Checkpoint– the point of synchronisation between the database & transaction log

file. All buffers are force written to secondary storage

CREATE THE DIFFERENCE

Recovery - transaction categories

Time tc tf

T1

T2

T3

T4

T5Checkpoint

(time tc)System failure(time tf)

Transaction recovery• Start with 2 lists of transactions, the UNDO list and the

REDO list– set the UNDO list equal to the list of all transactions in the

most recent checkpoint– set the REDO list to empty

• Search forward through the log, starting from the checkpoint record– If a BEGIN TRANSACTION entry is found for T, add T to the

UNDO list– If a COMMIT log entry is found for transaction T, move T

from the UNDO list to the REDO list• When the end of the log is reached, the 2 lists contain

relevant transactions

CREATE THE DIFFERENCE

Recovery - atomicity• Transactions have atomicity

– A transaction must succeed in its entirety or must be rolled back resulting in a nil effect

– Transactions can suffer cascading rollback due to interdependencies of data usage in transactions

• Cascades may be stopped by using only committed values – but this reduces concurrency– We avoid cascading rollback at the expense of parallelism