Download DDOS Assignment H1

DDOS 4307
COMP4307 Assignment
Database logging and recovery
Due 27/6/2003
The Durability aspect of ACID transactions is implemented through logging and the
careful ordering of guaranteed writes to disk. In this assignment you have to
demonstrate how this mechanism works and guarantees the recovery of committed
data after failures.
You have to write a simple simulator of the logging and recovery part of a database
server and a report that uses the results of your simulation to show how logging
and recovery works.
The simulated database server should maintain a pool of database buffers, log changes
to a log buffer, write full log buffers to a log file, process commit requests, initiate
fuzzy checkpoints every few (say 10) transactions, recover from simulated failures
(both application failure and system failure) and do anything else you think is
necessary. The simulator should read a script file that specifies a sequence of actions
to be carried out. This script file should be capable of specifying the following actions
(and anything else you think is needed for your report):
Read record into a buffer
Update buffer
Create record
Delete record
Commit
FailApp
FailSystem
(tx#, db record#)
(tx#, db record#, new data value)
(tx#, db record#, new data value)
(tx#, db record#)
(tx#)
(tx#)
You only have to simulate failures so normal file writes will be adequate – you don’t
have to crash your computer and recover from real log files. You will need to simulate
multiple concurrent transactions, filling log buffers with changes from a number of
concurrent transactions. The after values for your log records will be the data values
passed in with the operation and you can use the db record number as the before value
for any record that you are fetching from the database on disk or deleting.
You do not have to simulate the database on disk at all, but you do have to simulate
the database buffer pool held in memory and its management. To simplify this task,
assume that database records are exactly the same size (say 20 bytes) and that each
record completely fills one database buffer. You should allocate a fixed number of
database buffers (say 20 to 100), perhaps in an array. You will have to do simple
memory management of this buffer pool, finding a suitable buffer when you need to
read a record in from ‘disk’ – normally one that is either unused or does not contain
data that cannot yet be written back to the database.
You should trace everything that happens – reads and writes to the physical database,
buffer pool actions, log buffer actions, commits and checkpoints – and anything else
that makes to easier to understand the algorithms involved.
The purpose of the simulation is to illustrate your discussion of the logging and
recovery mechanisms, so think about what you want to illustrate and then build the
appropriate scripts. You need, at a minimum, to discuss what happens on application
failure and after a system failure. You have to discuss recovery after a media failure
(disk crash) but you should not try to simulate it. Remember – the purpose of the
simulation is only to illustrate your discussion, so don’t get carried away with
concurrent threads, synchronised disk writes, deferred log writes and other real-world
optimisations – simplicity is good.
Hand in both your code and a report that discusses the algorithms involved in
implementing Durability, using your input scripts and trace outputs to show what is
happening. 30% of the mark will be for the code and 70% will be for the report
(including the output produced by your code). You will get better marks through
simple clear explanations of what your traces are illustrating.
You may find chapter 8 of Principles of Transaction Processing (Bernstein &
Newcomer) useful in understanding the algorithms used to implement Durability.