Transcript Multi-user DB lecture

COIS20026 Database
Development & Management
Week 11 Multi-user databases
Backup & recovery
Objectives


List and describe four basic backup &
recovery facilities in a DBMS
Discuss common recovery procedures:
Disk mirroring
 Restore/rerun
 Maintaining transaction integrity




Describe ACID properties
Describe common database failures
Describe pessimistic vs optimistic
locking
2
Objectives




Describe lost update and inconsistent
read problems.
List and briefly describe various locking
levels (granularity)
Be able to discuss the problem of
deadlock
Discuss deadlock resolution and
deadlock prevention.
3
Database Recovery


At some point every database will
become lost or damaged; quick and
accurate restoration is essential
Basic recovery facilities:




backup - ie backup copies
journalising - maintain an audit trail of
transactions & database changes
checkpoint - periodic synchronisation of
all files & journals
recovery manager to handle recovery
4
Backup Facilities

DBMS should provide a backup facility
that produces a full copy of the
database



produced daily if database is not too
large
stored at secured location
used to restore database in case of
failure
5
Backup Facilities (cont’d)

Where database is very large an
incremental backup might be produced
daily (ie only changes made since last
full backup) or backups of only dynamic
data allowing for longer time periods
between full backups
6
Journalising Facilities

Provides an audit trail of transactions
and database changes


bear in mind that a transaction can
consist of a number of
changes/activities against database
files
transaction is considered a discrete unit
of work that must be completely
processed or not processed at all
7
Journalising Facilities (cont’d)


information in the journals can be used
in recovery to bring database back to a
consistent state (together with backup)
transaction log - records the essential
data for each processed transaction (eg
transaction ID, time, user ID, input data
values, records accessed & modified)
8
Journalising Facilities (cont’d)


Database change log - contains beforeand after-images of records that have
been changed
Security log - sometimes maintained to
alert the database administrator of
security violations (attempted or
successful)

should be mandatory in situations where
database can be accessed on-line or
from many different locations
9
Figure 12-9: Database audit trail
From the backup and
logs, databases can be
restored in case of
damage or loss
10
Checkpoint Facility




New transactions are refused and all
current transactions completed
journal files brought up-to-date
database & transaction logs
synchronized
checkpoint recorded in log file 

contains information necessary to
restart system
should be taken frequently since often
it is possible to resume processing from
the checkpoint
11
Recovery Manager

DBMS module that restores database to
correct condition when a failure has
occurred:


type of restart depends on failure type
manager uses logs & backup copy (if
necessary) to restore database
12
Recovery & Restart Procedures


Switch - processing is switched to a
mirrored copy of the database (ie a
duplicate, up-to-date copy)
Restore/Rerun - reprocessing day’s
transactions against a backup copy of the
database





simple technique
doesn’t require change journal
time to reprocess may be a problem
new transactions must be deferred
transactions might not be posted in same
sequence
13
Recovery & Restart Procedures
(cont’d)

Transaction integrity - a transaction
should not be committed to the
database unless all changes/operations
for a given transaction have been
successful completed, otherwise
transaction must be aborted

transaction boundaries are used by
applications to identify the beginning &
end of a transaction (most DBMS have
commands that can be used for this)
14
Recovery & Restart Procedures
(cont’d)

Backward Recovery (rollback) - DBMS
undoes unwanted changes to database


before-images of changed records are
applied to database, effectively
restoring it to the previous state
Forward Recovery (rollforward) - given
an earlier copy of the database, DBMS
applies after-images taking database to
later state 
faster & more accurate than
restore/rerun
15
Figure 12-10: Basic recovery techniques
(a) Rollback
16
Figure 12-10(b) Rollforward
17
Database Failure Types

Aborted transactions - one that
terminates abnormally (eg human
error, invalid data, deadlock)


database manager uses backward
recovery to ‘back out’ of the transaction
Incorrect data - data which is valid, but
incorrect:

difficult to detect and alter since many
users & applications may have since
used the incorrect data
18
Database Failure Types (cont’d)

Incorrect data cont’d

recovery may be undertaken through:
 backward recovery - early detection
 compensating transactions - if only a
few errors have occurred
 restart from most recent checkpoint if
above 2 measures not possible
19
Database Failure Types (cont’d)

System failure - system component fails
but database is not damaged



use backward recovery to abort
transactions that were in progress
then use mirrored copy if possible,
otherwise
use forward recovery from last
checkpoint (safest overall approach)
20
Database Failure Types (cont’d)

Database destruction - database is lost
or destroyed


use mirrored copy if available,
otherwise,
use backup copy and forward recovery;
transactions in progress will be lost
21
Concurrent Access

Where multiple users have access to
the database, simultaneous operations
must be managed so operations do not
interfere with each other - concurrency
control


problem can arise when data updated
concurrency control actions ensure that
data integrity is maintained
22
Concurrent Access Problems

Lost Updates (no concurrency
controls)- see figure 12-11



two people (John & Marsha) access a
bank account at slightly different times
both see the same account balance
because the withdrawal by the John is
registered after Marsha’s withdrawal
result is incorrect balance
23
Figure 12-11: LOST UPDATE
Simultaneous access causes updates to cancel each other
A similar problem is the inconsistent read problem
24
Concurrent Access Problems
(cont’d)

Inconsistent read (without concurrency
controls) - a user reads data that has
been only partially updated

also referred to as a dirty or
unrepeatable read
25
Serialisability

Refers to the scheduling of transactions
so that transactions against the same
data cannot interfere with one another



effect is that transactions are processed
as though they occurred one after the
other
transactions that are requesting data
from different tables are not affected
locking is most common concurrency
control method (see figure 12-12)
26
Locking Level (Granularity)

Locking level is the extent of database
resource being locked to provide
concurrency control



database - entire database is locked &
unavailable to other users
table - entire table containing requested
record is locked
block or page - physical storage block
containing requested record is locked
27
Figure 12-12: Updates with locking for concurrency control
This prevents the lost update problem
28
Locking Level (Granularity)
(cont’d)



Record level - only requested record is
locked
field level - only field within requested
record is locked
Activity - what locking levels does MS
Access provide?
29
Lock Types

Shared locks (read locks) - other
transactions can read a record but not
perform any updating;


prevents another user from placing an
exclusive lock on the record
Exclusive locks (write locks) - other
transactions cannot read (or update)
the record until the lock is released;

other users can’t place any locks
30
Deadlock

Occurs when


two or more transactions have locked a
common resource and must wait for the
other to unlock that resource
user 1 has a locked record and needs a
lock on another record; user 2 has lock
on record user 1 wants and needs lock
on user 1’s record
see figures 12-13, 12-14
31
Deadlock

An impasse that results when two or more
transactions have locked common resources, and
each waits for the other to unlock their resources
Figure 12-14
A deadlock situation
UserA and UserB will wait
forever for each other to
release their locked resources!
32
Managing Deadlock

Deadlock prevention - all records user
needs are locked at beginning of
transaction and achieved through twophase locking:


additional locks can be obtained as
needed during transaction duration or
until a lock is released
once any lock obtained for the
transaction is released no new locks
may be obtained
33
Managing Deadlock (cont’d)

Deadlock resolution - the DBMS
responsible for detecting and breaking
any deadlocks


DBMS maintains matrix of resource
usage that identifies what users are
using what resources - deadlocks can
thus be detected
deadlocks resolved by ‘backing out’ one
of the transactions; any changes made
up to that time are reversed;
transaction restarted later
34