1 . Define phaton Dead lock?

In

distributed deadlock detection, the delay in propagating local information

might cause the deadlock detection algorithms to identify deadlocks that do
not really exist. Such situations are called phantom deadlocks
2. Difference between serial access and concurrent access ?
3. Explain about serializable schedules?
4. Discuss about main memory ?
5. Describe the crash recovery process?
6. Write various dead lock avoidance techniques ?
1 . Define phaton Dead lock?
In

distributed deadlock detection, the delay in propagating local information might cause
the deadlock detection algorithms to identify deadlocks that do not really exist. Such
situations are called phantom deadlocks

2. Difference between serial access and concurrent access ?

Accessing data one after another tansaction is serial access
Accessing data all transactions at a time is called concurrent access.
3. Explain about serializable schedules?
Serializability of a schedule means equivalence (in the outcome, the database
state, data values) to a serial schedule (i.e., sequential with no transaction overlap in
time) with the same transactions. It is the major criterion for the correctness of
concurrent transactions' schedule, and thus supported in all general purpose
database systems.

4. Discuss about main memory ?

its simplest form, main memory databases store data on volatile memory devices. These
devices lose all stored information when the device loses power or is reset.
5.

Describe the crash recovery process?

DBMS is a highly complex system with hundreds of transactions being executed every second. The
durability and robustness of a DBMS depends on its complex architecture and its underlying
hardware and system software. If it fails or crashes amid transactions, it is expected that the system
would follow some sort of algorithm or techniques to recover lost data.
6.Write various dead lock avoidance techniques ?

we can try to avoid deadlocks by making use prior knowledge about the usage of resources by
processes including resources available, resources allocated, future requests and future releases by
processes. Most deadlock avoidance algorithms need every process to tell in advance the maximum
number of resources of each type that it may need. Based on all these info we may decide if a
process should wait for a resource or not, and thus avoid chances for circular wait.

1. ACID Properties
A transaction is a very small unit of a program and it may contain several lowlevel tasks. A transaction in a
database system must maintain Atomicity, Consistency, Isolation, andDurability commonly known as
ACID properties in order to ensure accuracy, completeness, and data integrity.
Atomicity This property states that a transaction must be treated as an
atomic unit, that is, either all of its operations are executed or none. There
must be no state in a database where a transaction is left partially completed.
States should be defined either before the execution of the transaction or
after the execution/abortion/failure of the transaction.
Consistency The database must remain in a consistent state after any
transaction. No transaction should have any adverse effect on the data
residing in the database. If the database was in a consistent state before the
execution of a transaction, it must remain consistent after the execution of
the transaction as well.
Durability The database should be durable enough to hold all its latest
updates even if the system fails or restarts. If a transaction updates a chunk
of data in a database and commits, then the database will hold the modified
data. If a transaction commits but the system fails before the data could be
written on to the disk, then that data will be updated once the system springs
back into action.

2. Illustrate transaction state diagram?

Active In this state, the transaction is being executed. This is the initial state of
every transaction.
Partially Committed When a transaction executes its final operation, it is
said to be in a partially committed state.

Failed A transaction is said to be in a failed state if any of the checks

made by the database recovery system fails. A failed transaction can no
longer proceed further.
Aborted If any of the checks fails and the transaction has reached a failed
state, then the recovery manager rolls back all its write operations on the
database to bring the database back to its original state where it was prior to
the execution of the transaction. Transactions in this state are called aborted.
The database recovery module can select one of the two operations after a
transaction aborts
Re-start the transaction
Kill the transaction

Committed If a transaction executes all its operations successfully, it is

said to be committed. All its effects are now permanently established on the
database system.

3. Discuss in detail about concurrency control techniques?

In a multiprogramming environment where multiple transactions can be executed
simultaneously, it is highly important to control the concurrency of transactions. We
have concurrency control protocols to ensure atomicity, isolation, and serializability
of concurrent transactions. Concurrency control protocols can be broadly divided
into two categories
Lock based protocols
Time stamp based protocols

Lock-based Protocols
Database systems equipped with lock-based protocols use a mechanism by which
any transaction cannot read or write data until it acquires an appropriate lock on it.
Locks are of two kinds
Binary Locks A lock on a data item can be in two states; it is either locked
or unlocked.
Shared/exclusive This type of locking mechanism differentiates the locks
based on their uses. If a lock is acquired on a data item to perform a write
operation, it is an exclusive lock. Allowing more than one transaction to write
on the same data item would lead the database into an inconsistent state.
Read locks are shared because no data value is being changed.
There are four types of lock protocols available

Simplistic Lock Protocol

Simplistic lock-based protocols allow transactions to obtain a lock on every object
before a 'write' operation is performed. Transactions may unlock the data item after
completing the write operation.

Pre-claiming Lock Protocol

Pre-claiming protocols evaluate their operations and create a list of data items on
which they need locks. Before initiating an execution, the transaction requests the
system for all the locks it needs beforehand. If all the locks are granted, the
transaction executes and releases all the locks when all its operations are over. If all
the locks are not granted, the transaction rolls back and waits until all the locks are
granted.

Two-Phase Locking 2PL

This locking protocol divides the execution phase of a transaction into three parts. In
the first part, when the transaction starts executing, it seeks permission for the
locks it requires. The second part is where the transaction acquires all the locks. As
soon as the transaction releases its first lock, the third phase starts. In this phase,
the transaction cannot demand any new locks; it only releases the acquired locks.

Two-phase locking has two phases, one is growing, where all the locks are being
acquired by the transaction; and the second phase is shrinking, where the locks held
by the transaction are being released.
To claim an exclusive (write) lock, a transaction must first acquire a shared (read)

lock and then upgrade it to an exclusive lock.

Strict Two-Phase Locking

The first phase of Strict-2PL is same as 2PL. After acquiring all the locks in the first
phase, the transaction continues to execute normally. But in contrast to 2PL, Strict2PL does not release a lock after using it. Strict-2PL holds all the locks until the
commit point and releases all the locks at a time.

Strict-2PL does not have cascading abort as 2PL does.

Timestamp-based Protocols
The most commonly used concurrency protocol is the timestamp based protocol.
This protocol uses either system time or logical counter as a timestamp.
Lock-based protocols manage the order between the conflicting pairs among
transactions at the time of execution, whereas timestamp-based protocols start
working as soon as a transaction is created.
Every transaction has a timestamp associated with it, and the ordering is
determined by the age of the transaction. A transaction created at 0002 clock time
would be older than all other transactions that come after it. For example, any
transaction 'y' entering the system at 0004 is two seconds younger and the priority
would be given to the older one.
In addition, every data item is given the latest read and write-timestamp. This lets
the system know when the last read and write operation was performed on the
data item.

mestamp Ordering Protocol

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.
The timestamp of transaction Ti is denoted as TS(Ti).
Read time-stamp of data-item X is denoted by R-timestamp(X).
Write time-stamp of data-item X is denoted by W-timestamp(X).

Timestamp ordering protocol works as follows

If a transaction Ti issues a read(X) operation
If TS(Ti) < W-timestamp(X)
Operation rejected.
If TS(Ti) >= W-timestamp(X)
Operation executed.
All data-item timestamps updated.

If a transaction Ti issues a write(X) operation

If TS(Ti) < R-timestamp(X)
Operation rejected.
If TS(Ti) < W-timestamp(X)
Operation rejected and Ti rolled back.
Otherwise, operation executed.

Thomas' Write Rule

This rule states if TS(Ti) < W-timestamp(X), then the operation is rejected and T i is
rolled back.
Time-stamp ordering rules can be modified to make the schedule view serializable.
Instead of making Ti rolled back, the 'write' operation itself is ignored.

4.Explain in detail about Dead Lock problem?

In a multi-process system, deadlock is an unwanted situation that arises in a shared

resource environment, where a process indefinitely waits for a resource that is held
by another process.
For example, assume a set of transactions {T 0, T1, T2, ...,Tn}. T0 needs a resource
X to complete its task. Resource X is held by T1, and T1 is waiting for a resource Y,
which is held by T2. T2 is waiting for resource Z, which is held by T0. Thus, all the
processes wait for each other to release resources. In this situation, none of the
processes can finish their task. This situation is known as a deadlock.
Deadlocks are not healthy for a system. In case a system is stuck in a deadlock, the
transactions involved in the deadlock are either rolled back or restarted.

Deadlock Prevention
To prevent any deadlock situation in the system, the DBMS aggressively inspects all
the operations, where transactions are about to execute. The DBMS inspects the
operations and analyzes if they can create a deadlock situation. If it finds that a
deadlock situation might occur, then that transaction is never allowed to be
executed.
There are deadlock prevention schemes that use timestamp ordering mechanism of
transactions in order to predetermine a deadlock situation.

Wait-Die Scheme
In this scheme, if a transaction requests to lock a resource (data item), which is
already held with a conflicting lock by another transaction, then one of the two
possibilities may occur
If TS(Ti) < TS(Tj) that is Ti, which is requesting a conflicting lock, is older
than Tj then Ti is allowed to wait until the data-item is available.
If TS(Ti) > TS(tj) that is Ti is younger than Tj then Ti dies. Ti is restarted
later with a random delay but with the same timestamp.
This scheme allows the older transaction to wait but kills the younger one.

Wound-Wait Scheme
In this scheme, if a transaction requests to lock a resource (data item), which is
already held with conflicting lock by some another transaction, one of the two
possibilities may occur

If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back that is Ti wounds Tj.
Tj is restarted later with a random delay but with the same timestamp.
If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource is available.
This scheme, allows the younger transaction to wait; but when an older transaction
requests an item held by a younger one, the older transaction forces the younger
one to abort and release the item.
In both the cases, the transaction that enters the system at a later stage is aborted.

Deadlock Avoidance
Aborting a transaction is not always a practical approach. Instead, deadlock
avoidance mechanisms can be used to detect any deadlock situation in advance.
Methods like "wait-for graph" are available but they are suitable for only those
systems where transactions are lightweight having fewer instances of resource. In a
bulky system, deadlock prevention techniques may work well.

Wait-for Graph
This is a simple method available to track if any deadlock situation may arise. For
each transaction entering into the system, a node is created. When a transaction
Ti requests for a lock on an item, say X, which is held by some other transaction T j,
a directed edge is created from Ti to Tj. If Tj releases item X, the edge between
them is dropped and Ti locks the data item.
The system maintains this wait-for graph for every transaction waiting for some
data items held by others. The system keeps checking if there's any cycle in the
graph.

Here, we can use any of the two following approaches

First, do not allow any request for an item, which is already locked by
another transaction. This is not always feasible and may cause starvation,
where a transaction indefinitely waits for a data item and can never acquire it.
The second option is to roll back one of the transactions. It is not always
feasible to roll back the younger transaction, as it may be important than the
older one. With the help of some relative algorithm, a transaction is chosen,
which is to be aborted. This transaction is known as the victim and the
process is known asvictim selection.

5. Discuss

about various kinds of crash recovery mechanisams?

Crash Recovery
DBMS is a highly complex system with hundreds of transactions being executed
every second. The durability and robustness of a DBMS depends on its complex
architecture and its underlying hardware and system software. If it fails or crashes
amid transactions, it is expected that the system would follow some sort of
algorithm or techniques to recover lost data.

Failure Classification
To see where the problem has occurred, we generalize a failure into various
categories, as follows

Transaction failure
A transaction has to abort when it fails to execute or when it reaches a point from
where it cant go any further. This is called transaction failure where only a few
transactions or processes are hurt.
Reasons for a transaction failure could be
Logical errors Where a transaction cannot complete because it has some
code error or any internal error condition.
System errors Where the database system itself terminates an active
transaction because the DBMS is not able to execute it, or it has to stop
because of some system condition. For example, in case of deadlock or

resource unavailability, the system aborts an active transaction.

System Crash
There are problems external to the system that may cause the system to stop
abruptly and cause the system to crash. For example, interruptions in power supply
may cause the failure of underlying hardware or software failure.
Examples may include operating system errors.

Disk Failure
In early days of technology evolution, it was a common problem where hard-disk
drives or storage drives used to fail frequently.
Disk failures include formation of bad sectors, unreachability to the disk, disk head
crash or any other failure, which destroys all or a part of disk storage.

Storage Structure
We have already described the storage system. In brief, the storage structure can
be divided into two categories
Volatile storage As the name suggests, a volatile storage cannot survive
system crashes. Volatile storage devices are placed very close to the CPU;
normally they are embedded onto the chipset itself. For example, main
memory and cache memory are examples of volatile storage. They are fast
but can store only a small amount of information.
Non-volatile storage These memories are made to survive system
crashes. They are huge in data storage capacity, but slower in accessibility.
Examples may include hard-disks, magnetic tapes, flash memory, and nonvolatile (battery backed up) RAM.

Recovery and Atomicity

When a system crashes, it may have several transactions being executed and
various files opened for them to modify the data items. Transactions are made of
various operations, which are atomic in nature. But according to ACID properties of
DBMS, atomicity of transactions as a whole must be maintained, that is, either all
the operations are executed or none.
When a DBMS recovers from a crash, it should maintain the following
It should check the states of all the transactions, which were being executed.
A transaction may be in the middle of some operation; the DBMS must
ensure the atomicity of the transaction in this case.

It should check whether the transaction can be completed now or it needs to

be rolled back.
No transactions would be allowed to leave the DBMS in an inconsistent state.
There are two types of techniques, which can help a DBMS in recovering as well as
maintaining the atomicity of a transaction
Maintaining the logs of each transaction, and writing them onto some stable
storage before actually modifying the database.
Maintaining shadow paging, where the changes are done on a volatile
memory, and later, the actual database is updated.

Log-based Recovery
Log is a sequence of records, which maintains the records of actions performed by a
transaction. It is important that the logs are written prior to the actual modification
and stored on a stable storage media, which is failsafe.
Log-based recovery works as follows
The log file is kept on a stable storage media.
When a transaction enters the system and starts execution, it writes a log
about it.
<Tn, Start>

When the transaction modifies an item X, it write logs as follows

<Tn, X, V1, V2>

It reads Tn has changed the value of X, from V1 to V2.

When the transaction finishes, it logs
<Tn, commit>

The database can be modified using two approaches

Deferred database modification All logs are written on to the stable
storage and the database is updated when a transaction commits.
Immediate database modification Each log follows an actual database
modification. That is, the database is modified immediately after every
operation.

Recovery with Concurrent Transactions

When more than one transaction are being executed in parallel, the logs are
interleaved. At the time of recovery, it would become hard for the recovery system
to backtrack all logs, and then start recovering. To ease this situation, most modern

DBMS use the concept of 'checkpoints'.

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.

Recovery
When a system with concurrent transactions crashes and recovers, it behaves in the
following manner

The recovery system reads the logs backwards from the end to the last
checkpoint.
It maintains two lists, an undo-list and a redo-list.
If the recovery system sees a log with <T n, Start> and <Tn, Commit> or just
<Tn, Commit>, it puts the transaction in the redo-list.
If the recovery system sees a log with <T n, Start> but no commit or abort
log found, it puts the transaction in undo-list.
All the transactions in the undo-list are then undone and their logs are removed. All
the transactions in the redo-list and their previous logs are removed and then
redone before saving their logs.