Chapter 11

Database Recovery

Why Database Recovery is

needed?
A Computer Failure (System Crash)
A Transaction or System Error
Local Errors or Exception Conditions
Concurrency Control Enforcement:
Disk Failure
Physical Problems and Catastrophes

Recovery Concept
Transaction Failure: Use Log for Recovery
Catastrophic Failure: Past data from backup and
recent from log.
There are two types of recovery techniques
Log Based Recovery: maintains log files in stable
storage update log file before updating database.
Use this file for recovery.
Shadow Paging: Maintains two versions of
database in disk . BFIM and AFIM.

Log Based recovery

There four types of log records in log file.
Start Record:
Syntax: <Ti, Start>
Update Record:
Syntax: <Ti, x,OV,NV>
Commit Record:
Syntax: <Ti, Commit>
Abort Record
Syntax: <Ti, Abort>

Data Buffering and

Updating
Each buffer block in memory in associated with two bits:
modified-bit (drty-bit) and pin-unpin bit.
Modified-bit: 1------> dirty, Otherwise, clean
Pin-unpin bit: 1-----> buffer block can not be written back to
disk as yet. Otherwise, buffer block can be written back to
disk.

There are two methods of flushing modified buffer

blocks into disk: In-place Updating and Shadow
Updating.
In-place Update: overwrites the original value of disk block
with modified value in the buffer.
Shadow Update: writes buffer block to disk location that is
different from original location. Thus there are two copies
called AFIM and BFIM.

Data Buffering and

Updating
When modified buffere blocks are written back to disk,
following policies are used: Steal/No-steal policy and
Force/No-force policy.
Steal/No-steal Policy: Steal policy ------ allows to write a
buffer block to disk before transaction commits.
Force/No-force Policy: Force policy update disk
immediately after commit.

Now policies used in writing back buffer block to disk block

gives rise to four different ways for handling recovery:

Steal/No-Force (Undo/Redo)
Steal/Force (Undo/No-redo)
No-Steal/No-Force (Redo/No-undo)
No-Steal/Force (No-undo/No-redo)

Check Pointing
Searching entire log file is time consuming and also may
perform unnecessary redo.
Checkpoint declares a point before which the DBMS was
in consistent state and all the transactions were
committed. Now recovery will be to only process log
records since the last checkpoint record.
The following steps define a checkpoint operation.
Suspend execution of transactions temporarily.
Force write modified buffer data to disk.
Write a [checkpoint] record to the log, save the log to
disk.
Resume normal transaction execution.

Write Ahead Logging

Write-ahead log (WAL) protocol guarantees that no
data modifications are written to disk before the
associated log record is written to disk.
WAL states that
For Undo: Before a data items AFIM is flushed to the
database disk (overwriting the BFIM) its BFIM must be
written to the log and the log must be saved on a stable
store (log disk).
For Redo: Before a transaction executes its commit
operation, all its AFIMs must be written to the log and
the log must be saved on a stable store.

Differed Update Recovery Policy

Update log file and then update disk. Database id updated
immediately after commit. Thus also called No-undo/Redo
policy
Recovery using Deferred Update in a Single-User
environment : maintains two lists: committed list and
active list. Redo transactions
in committed
list
Tid Operatio Data
Old
Newand restart
T1
T2
active
transactions
n
Item
Value
Value
Read(x)
Write(x)
Commit

Read(y
)
Read(z
)
Write(y
)
Write(z
)
Commi

T1

Start

T1

Write

T1

Commit

T2

Start

T2

Write

200

350

T2

Write

500

250

400

300

Crash

Differed Update
Recovery
Policy
as single user environment but

Same
concurrency control mechanism
Tid

Operation

DataItem

OldValue

NewValue

T1

Start

T1

Write

400

300

T1

Write

340

250

T1

Commit

requires

Checkpont
T4

Start

T4

Write

200

350

T4

Write

300

250

T4

Commit

T2

Start

T2

Write

T3

Start

T3
T2

crash
y

350

250

Write

250

100

Write

250

525

Immediate Update Recover

Policy

Database is updated immediately before reaching

commit point. update operation must still be recorded
in the log under WAL
if force writing policy is used Redo operation is not
needed for committed transactions but it is required
if no-force policy is used.
Thus Immediate update recovery policy can be
divided into two categories: Undo/No-redo Recovery
and Undo/Redo Recovey.

Immediate Update
Recover Policy
Undo/Redo Policy:
Immediate Update in Single User Environment :
committed list and active list. Undo active tractions
and redo committed transactions.
Immediate Update in Multi-user Environment use
strict 2PL so that none of the locks are released till
transaction is committed.

Shadow Paging

Storage Hierarchy
Volatile Storage
Nonvolatile Storage
Stable Storage

Database Security
Role of DBA in Database Security
Managing User Accounts
Performing Database Audits
Classification of Database Security
Physical security-Hardware Safety
Logical Security- Software Safeguards
Levels of Security
Physical
Human
Operating System
Network
Database

Authorization
Types of authorization

Read Authorization
Insert Authorization
Update Authorization
Delete Authorization
Index Authorization
Resource Authorization
Alteration Authorization

Granting Privileges
Syntax
GRANT <privilege list> | ALL PRIVILEGES
ON < relation name or view name >
TO <user-name list/role list> | PUBLIC [WITH GRANT
OPTION]

GRANT SELECT ON Employee TO Nirmala, Bhupesh

GRANT INSERT, DELETE, UPDATE, SELECT

ON Employees, Departments
TO Anil;

Granting Privileges
GRANT INSERT, DELETE, UPDATE, SELECT
ON Employees, Departments, Orders, Products
TO DBA
WITH GRANT OPTION ;
GRANT UPDATE ON products (price) TO Binaya ;

Authorization Graph

DBA

U1

U4

U2

U5

U3

Figure 9.1: Authorization Graph

Roles and Privileges

Why Roles?
Reducing the number of grants and thereby
making it easier to manage security.
Dynamically changing the privileges for many
users with a single grant or revoke.
CREATE ROLE testing
GRANT CREATE TABLE TO testing;
GRANT testing TO user1;

Revoking of Privileges
Syntax
REVOKE <privilege list> | ALL PRIVILEGES ON
<object_names>
FROM <user-name list> | PUBLIC [CASCADE | RESTRICT]
REVOKE ALL PRIVILEGES
ON
Employees, Departments, Orders, Products
FROM Anil ;

Revoking of Privileges
DBA
GRANT Select ON Employees TO Anil WITH GRANT
OPTION
Anil
GRANT Select ON Employees TO Bhupesh
DBA
REVOKE Select ON Employees FROM Anil RESTRICT;
DBA
REVOKE Select ON Employees FROM Anil CASCADE;

Authentication
Different techniques of authentication

Password Authentication
Biometric Authentication
Digital Signature
Smart Card Authentication

Creating User in SQL

Syntax:
CREATE USER <user-name> IDENTIFIED BY <password>
Example:
CREATE USER Bhupi IDENTIFIED BY abcd;

Encryption
Terminologies

Plain Text
Cipher Text
Encryption
Decryption
Key

Types of Encryption
Private Key Encryption-Ceaser Cipher, DES, AES
Public Key Encryption-RSA