Académique Documents
Professionnel Documents
Culture Documents
PART A
1 Answer all the questions
A
the transaction. The log file is written sequentially, and so the cost of syncing the log is much less than
the cost of flushing the data pages. This is especially true for servers handling many small transactions
touching different parts of the data store. Furthermore, when the server is processing many small
concurrent transactions, one fsync of the log file may suffice to commit many transactions.
WAL also makes it possible to support on-line backup and point-in-time recovery. By archiving the
WAL data we can support reverting to any time instant covered by the available WAL data: we simply
install a prior physical backup of the database, and replay the WAL log just as far as the desired time.
The physical backup doesn't have to be an instantaneous snapshot of the database state if it is made
over some period of time, then replaying the WAL log for that period will fix any internal
inconsistencies.
Dense Index
Sparse Index
Dense Index
In dense index, there is an index record for every search key value in the database. This makes searching faster
but requires more space to store index records itself. Index records contain search key value and a pointer to the
actual record on the disk.
Sparse Index
In sparse index, index records are not created for every search key. An index record here contains a search key
and an actual pointer to the data on the disk. To search a record, we first proceed by index record and reach at
the actual location of the data. If the data we are looking for is not where we directly reach by following the
index, then the system starts sequential search until the desired data is found.
Multilevel Index
Index records comprise search-key values and data pointers. Multilevel index is stored on the disk along with
the actual database files. As the size of the database grows, so does the size of the indices. There is an immense
need to keep the index records in the main memory so as to speed up the search operations. If single-level index
is used, then a large size index cannot be kept in memory which leads to multiple disk accesses.
Multi-level Index helps in breaking down the index into several smaller indices in order to make the outermost level so small
that it can be saved in a single disk block, which can easily be accommodated anywhere in the main memory.
A
PART B
2) a) Describe about testing of Serializability.
A simple and efficient method for determining conflict serializability of a schedule. Consider a schedule
S. We construct a directed graph, called a precedence graph, from S. This graph consists of a pair G =
(V, E), where V is a set of vertices and E is a set of edges. The set of vertices consists of all the
transactions participating in the schedule. The set of edges consists of all edges Ti Tj for which one
of three conditions holds:
1. Ti executes write(Q) before Tj executes read(Q).
2. Ti executes read(Q) before Tj executes write(Q).
3. Ti executes write(Q) before Tj executes write(Q).
If an edge Ti Tj exists in the precedence graph, then, in any serial schedule S1equivalent to S, Ti must
appear before Tj .
If the precedence graph for S has a cycle, then schedule S is not conflict serializable. If the graph contains
no cycles, then the schedule S is conflict serializable. A serializability order of the transactions can be
obtained through topological sorting, which determines a linear order consistent with the partial order
of the precedence graph. There are, in general, several possible linear orders that can be obtained through
a topological sorting. Thus, to test for conflict serializability, we need to construct the precedence graph
and to invoke a cycle-detection algorithm. Cycle-detection algorithms, such as those based on depthfirst search, require on the order of n2 operations, where n is the number of vertices in the graph (that is,
the number of transactions).
Testing for view serializability is complicated. The problem of testing for view serializability is itself
NP-complete. Thus, almost certainly there exists no efficient algorithm to test for view serializability.
However, concurrency-control schemes can still use sufficient conditions for view serializability. That
is, if the sufficient conditions are satisfied, the schedule is view serializable, but there may be viewserializable schedules that do not satisfy the sufficient conditions.
b) Explain the deferred and immediate modification versions of the log based
recovery scheme.
Deferred Update vs Immediate Update
Deferred Update and Immediate Update are two techniques used to maintain transaction log files of Database
Management Systems (DBMS). Transaction log (also referred to as the journal log or the redo log) is a physical
file that stores the Transaction ID, the time stamp of the transaction, the old value and the new values of the data.
This allows the DBMS to keep track of the data before and after each transaction. When the transactions are
committed and the database is returned to a consistent state, the log might be truncated to remove the committed
transactions.
The difference between Deferred Update and Immediate Update:
Even though Deferred Update and Immediate Update are two methods for recovering after a system failure, the
process that each method uses is different. In differed update method, any changes made to the data by a
transaction are first recorded in a log file and applied to the database on commit. In immediate update method,
changes made by a transaction are directly applied to the database and old values and new values are recorded in
the log file. These records are used to restore old values on rollback. In differed update method, records in the log
file are discarded on roll back and are never applied to the database. One disadvantage of deferred update method
is the increased time taken to recover in case of a system failure. On the other hand, frequent I/O operations while
the transaction is active, is a disadvantage in immediate update method.
(OR)
3) Write short note on
a) Types of schedules.
A Schedule represents the order in which instructions of transactions are executed. Various types of schedules
are as follows:
Complete Schedule:
A schedule that contains either an abort or a commit for each transaction whose actions are listed in it is called a
complete schedule. A complete schedule must contain all the actions of every transaction that appears in it.
A
Eg.
Serial Schedule:
If the actions of different transactions are not interleaved that is, transactions are executed
from start to finish, one by one then that schedule is called a serial schedule.
Recoverable Schedule:
A schedule in which for each pair of transactions Ti and Tj such that Tj reads a data item that was previously
written by Ti then the commit operation of Ti should appear before the commit operation of Tj.
Cascadeless Schedules:
A
A schedule in which for each pair of transactions Ti and Tj such that Tj reads a data item that was previously
written by Ti then the commit operation of Ti should appear before theread operation of Tj.
Strict Schedule:
A schedule is said to be strict if a value written by a transaction cannot be read or overwritten by other transactions
until the transaction is either committed or aborted.
Every strict schedule is recoverable and cascadeless.
A
chosen Validation(Ti), rather than Start(Ti), as the timestamp of transaction Ti is that we can expect faster
response time provided that conflict rates among transactions are indeed low.
The validation test for transaction Tj requires that, for all transactions Ti with TS(Ti) < TS(Tj ), one of the
following two conditions must hold:
1. Finish(Ti) < Start(Tj ). Since Ti completes its execution before Tj started, the
serializability order is indeed maintained.
2. The set of data items written by Ti does not intersect with the set of data items read by Tj, and Ti completes its
write phase before Tj starts its validation phase (Start(Tj ) < Finish(Ti) < Validation(Tj )). This condition ensures
that the writes of Ti and Tj do not overlap. Since the writes of Ti do not affect the read of Tj , and since Tj cannot
affect the read of Ti, the serializability order is indeed maintained.
The validation scheme automatically guards against cascading rollbacks, since the actual writes take place only
after the transaction issuing the write has committed. However, there is a possibility of starvation of long
transactions, due to a sequence of conflicting short transactions that cause repeated restarts of the long transaction.
To avoid starvation, conflicting transactions must be temporarily blocked, to enable the long transaction to finish.
This validation scheme is called the optimistic concurrency control scheme since transactions execute
optimistically, assuming they will be able to finish execution and validate at the end. In contrast, locking and
timestamp ordering are pessimistic in that they force a wait or a rollback whenever a conflict is detected, even
though there is a chance that the schedule may be conflict serializable.
c) ARIES.
ARIES is a recovery algorithm that is designed to work with a steal, no-force approach. When the recovery
manager is invoked after a crash, restart proceeds in three phases:
1.Analysis: Identifies dirty pages in the buffer pool and active transactions at the time of the crash.
2.Redo: Repeats all actions, starting from an appropriate point in the log, and restores the database state to what
it was at the time of the crash.
3.Undo: Undoes the actions of transactions that did not commit, so that the database reflects only the actions of
committed transactions.
There are three main principles behind the ARIES recovery algorithm:
Write-ahead logging: Any change to a database object is first recorded in the log; the record in the log must be
written to stable storage before the change to the database object is written to disk.
Repeating history during Redo: Upon restart following a crash, ARIES retraces all actions of the DBMS before
the crash and brings the system back to the exact state that it was in at the time of the crash. Then, it undoes the
actions of transactions that were still active at the time of the crash.
Logging changes during Undo: Changes made to the database while undoing a transaction are logged in order to
ensure that such an action is not repeated in the event of repeated restarts.
d) Fuzzy Checkpointing
The checkpointing technique requires that all updates to the database be temporarily suspended while
the checkpoint is in progress. If the number of pages in the buffer is large, a checkpoint may take a long
time to finish, which can result in an unacceptable interruption in processing of transactions.
To avoid such interruptions, the checkpointing technique can be modified to permit updates to start once
the checkpoint record has been written, but before the modified buffer blocks arewritten to disk. The
checkpoint thus generated is a fuzzy checkpoint. Since pages are output to disk only after the checkpoint
record has been written, it is possible that the system could crash before all pages are written. Thus, a
checkpoint on disk may be incomplete. One way to deal with incomplete checkpoints is this: The
location in the log of the checkpoint record of the last completed checkpoint is stored in a fixed position,
last-checkpoint, on disk. The system does not update this information when it writes the checkpoint
record. Instead, before it writes the checkpoint record, it creates a list of all modified buffer blocks. The
last-checkpoint information is updated only after all buffer blocks in the list of modified buffer blocks
have been output to disk.
Even with fuzzy checkpointing, a buffer block must not be updated while it is being output to disk,
although other buffer blocks may be updated concurrently. The write-ahead log protocol must be
followed so that (undo) log records pertaining to a block are on stable storage before the block is output.
Note that, in our scheme, logical logging is used only for undo purposes, whereas
Physical logging is used for redo and undo purposes. There are recovery schemes that use logical logging
for redo purposes. To perform logical redo, the database state on disk must be operation consistent, that
is, it should not have partial effects of any operation. It is difficult to guarantee operation consistency of
the database on disk if an operation can affect more than one page, since it is not possible to write two
or more pages atomically. Therefore, logical redo logging is usually restricted only to operations that
A
affect a single page; In contrast, logical undos are performed on an operation-consistent database state
achieved by repeating history, and then performing physical undo of partially completed operations.
A DBMS must be able to ensure that only serializable, recoverable schedules are allowed, and that no
actions of committed transactions are lost while undoing aborted transactions. A DBMS typically uses
a locking protocol to achieve this. A locking protocol is a set of rules to be followed by each transaction,
in order to ensure that even though actions of several transactions might be interleaved, the net effect is
identical to executing all transactions in some serial order.
Strict Two-Phase Locking(Strict2PL):
The most widely used locking protocol, called Strict Two-Phase Locking, or Strict2PL,
has two rules. The first rule is
1.If a transaction T wants to read an object, it first requests a shared lock on the object.A transaction that
requests a lock is suspended until the DBMS is able to grant it the requested lock. The DBMS keeps
track of the locks it has granted and ensures that if a transaction holds an exclusive lock on an object no
other transaction holds a shared or exclusive lock on the same object.
(2)All locks held by a transaction are released when the transaction is completed.
Multiple-Granularity Locking
Another specialized locking strategy is called multiple-granularity locking, and it allows us to efficiently
set locks on objects that contain other objects. For instance, a database contains several files , a file is a
collection of pages , and a page is a collection of records . A transaction that expects to access most of
the pages in a file should probably set a lock on the entire file, rather than locking individual pages as
and when it needs them. Doing so reduces the locking overhead considerably. On the other hand, other
transactions that require access to parts of the file even parts that are not needed by this transaction
are blocked. If a transaction accesses relatively few pages of the file, it is better to lock only those pages.
Similarly, if a transaction accesses ever all records on a page, it should lock the entire page, and if it
accesses just a few records, it should lock just those records.
The recovery manager of a DBMS is responsible for ensuring two important properties of transactions:
atomicity and durability. It ensures atomicity by undoing the actions of transactions that do not commit
and durability by making sure that all actions of committed transactions survive system crashes, (e.g., a
core dump caused by a bus error) and media failures (e.g., a disk is corrupted).
Timestamp Ordering Protocol
A
The timestamp-ordering protocol ensures serializability among transactions in their conflicting read and write
operations. This is the responsibility of the protocol system that the conflicting pair of tasks should be executed
according to the timestamp values of the transactions.
Detection of failure: Backup site must detect when primary site has failed
To distinguish primary site failure from link failure maintain several communication
links between the primary and the remote backup.
Heart-beat messages
Transfer of control:
o To take over control backup site first perform recovery using its copy of the database and all the
long records it has received from the primary.
o Thus, completed transactions are redone and incomplete transactions are rolled back.
o When the backup site takes over processing it becomes the new primary
o To transfer control back to old primary when it recovers, old primary must receive redo logs from
the old backup and apply all updates locally.
A
Time to recover: To reduce delay in takeover, backup site periodically proceses the redo log records (in
effect, performing recovery from previous database state), performs a checkpoint, and can then delete
earlier parts of the log.
Hot-Spare configuration permits very fast takeover:
o Backup continually processes redo log record as they arrive, applying the updates locally.
o When failure of the primary is detected the backup rolls back incomplete transactions, and is
ready to process new transactions.
Alternative to remote backup: distributed database with replicated data
o Remote backup is faster and cheaper, but less tolerant to failure
Ensure durability of updates by delaying transaction commit until update is logged at backup; avoid this
delay by permitting lower degrees of durability.
One-safe: commit as soon as transactions commit log record is written at primary
o Problem: updates may not arrive at backup before it takes over.
Two-very-safe: commit when transactions commit log record is written at primary and backup
o Reduces availability since transactions cannot commit if either site fails.
Two-safe: proceed as in two-very-safe if both primary and backup are active. If only the primary is active,
the transaction commits as soon as is commit log record is written at the primary.
o Better availability than two-very-safe; avoids problem of lost transactions in one-safe.
(OR)
B+ tree
A static structure such as the ISAM index suffers from the problem that long overflow chains can develop as
the file grows, leading to poor performance. This problem motivated the development of more flexible, dynamic
structures that adjust gracefully to inserts and deletes. The B+ tree search structure, which is widely used, is a
balanced tree in which the internal nodes direct the search and the leaf nodes contain the data entries. Since the
tree structure grows and shrinks dynamically, it is not feasible to allocate the leaf pages sequentially as in ISAM,
where the set of primary leaf pages was static. In order to retrieve all leaf pages efficiently, we have to link them
using page pointers. By organizing them into a doubly linked list, we can easily traverse the sequence of leaf
pages in either direction. This structure is illustrated in Figure.
Heap files : Files of randomly ordered are called Heap files. When a file is created using Heap File
Organization, the Operating System allocates memory area to that file without any further accounting
details. File records can be placed anywhere in that memory area. It is the responsibility of the software
to manage the records. Heap File does not support any ordering, sequencing, or indexing on its own.
Sorted files : these are the files sorted on some field. Every file record contains a data field (attribute)
to uniquely identify that record. In sequential file organization, records are placed in the file in some
sequential order based on the unique key field or search key. Practically, it is not possible to store all the
records sequentially in physical form.
Hashed files : Files that are hashed on some fields are called hashed files. Hash File Organization
uses Hash function computation on some fields of the records. The output of the hash function
determines the location of disk block where the records are to be placed.
Clustered Files: Clustered file organization is not considered good for large databases. In this
mechanism, related records from one or more relations are kept in the same disk block, that is, the
ordering of records is not based on primary key or search key.
The choice of file organization can have a significant on performance. The choice of an appropriate file
organization depends on the operations like Scan, Insert, Delete
Roll No:
__________________________________________________________________________________
I Answer all the questions each question carries 1 Mark
5*1=5
1) What are MVD and Join Dependencies?
Let R be the relational schema, X,Y be the attribute sets over R. A MVD (XY) exists on a relation R : If
two tuples t1 and t2 exists in R, such that t1[X] = t2[Y] then two tuples t3 and t4 should also exist in R with the
following properties where Z = R {X Y}:
t3[X] = t4[X] = t1[X] = t2[X]
t3[Y] = t1[Y] and t4[Y] = t2[Y]
t3[Z] = t2[Z] and t4[Z] = t1[Z]
The tuples t1, t2, t3, t4 are not necessarily distinct.
Join Dependency
Let R be a relation. Let A, B, , Z be arbitrary subsets of Rs attributes. R satisfies the JD
*(A,B,,Z) if and only if R is equal to the join of its projections on A, B, , Z. A join dependency
JD(R1, R2, , Rn) specified on relation schema R, is a trivial JD, if one of the relation schemas Ri in
JD(R1, R2, .,Rn) is equal to R.
Join dependency is used in the following case : When
Shared Lock - This type is placed on a record when the record is being viewed.
Exclusive lock - This is placed when Insert, Update or Delete command is performed. There can be only one
exclusive lock on a record at a time.
4) What is Multi version Time stamp Ordering Protocol.
Suppose that transaction Ti issues a read(Q) or write(Q) operation. Let Qk denote the version of Q whose write
timestamp is the largest write timestamp less than or equal to TS(Ti).
A
1. If transaction Ti issues a read(Q), then the value returned is the content of version Qk.
2. If transaction Ti issues write(Q), and if TS(Ti)<R-timestamp(Qk), then the system rolls back transaction Ti.
On the other hand, if TS(Ti) = W-timestamp(Qk), the system overwrites the contents of Qk; otherwise it creates
a new version of Q.
5) What is a checkpoint.
Keeping and maintaining logs in real time and in real environment may fill out all the memory space
available in the system. As time passes, the log file may grow too big to be handled at all. Checkpoint
is a mechanism where all the previous logs are removed from the system and stored permanently in a
storage disk. Checkpoint declares a point before which the DBMS was in consistent state, and all the
transactions were committed.
5*1/2=2 12
5*1/2=2 12
11.Deadlocks are possible only when one of the transactions wants to obtain a(n) ____ lock on a data
item.
[ C]
a. Binary
b. Exclusive c. Shared
d. Complete
12. A DBMS uses a transaction _ to keep track of all transactions that update the database [ A ]
a. log
b. table
c. block
d. statement
13. Reading uncommitted data is addressed as
[ A ]
a. Dirty Read
b. Log Read
c. W-W conflict
d. Tree
14. Example of non dense index is
[ D ]
a. Ternary
b. Secondary
c. Primary
d. Clustered
15. Transitive Dependency is removed in
[ C ]
a. 2NF
b. Denormalization
c. 3NF
d. 5NF