DBMS lecture notes on 4 useful for stidents

Multiple Granularity:
Granularity: It is the size of data item allowed to lock.
o It can be defined as hierarchically breaking up the database into
blocks which can be locked.
o The Multiple Granularity protocol enhances concurrency and
reduces lock overhead.
o It maintains the track of what to lock and how to lock.
o It makes easy to decide either to lock a data item or to unlock a
data item. This type of hierarchy can be graphically represented as
a tree.
For example: Consider a tree which has four levels of nodes.
o The first level or higher level shows the entire database.
o The second level represents a node of type area. The higher level
database consists of exactly these areas.
o The area consists of children nodes which are known as files. No
file can be present in more than one area.
o Finally, each file contains child nodes known as records. The file
has exactly those records that are its child nodes. No records
represent in more than one file.
o Hence, the levels of the tree starting from the top level are as
follows:
1. Database
2. Area

3. File
4. Record
In this example, the highest level shows the entire database. The levels
below are file, record, and fields.
There are three additional lock modes with multiple granularity:
Intention Mode Lock
Intention-shared (IS): It contains explicit locking at a lower level of the
tree but only with shared locks.
Intention-Exclusive (IX): It contains explicit locking at a lower level
with exclusive or shared locks.
Shared & Intention-Exclusive (SIX): In this lock, the node is locked in
shared mode, and some node is locked in exclusive mode by the same
transaction.
Compatibility Matrix with Intention Lock Modes: The below table
describes the compatibility matrix for these lock modes:

It uses the intention lock modes to ensure serializability. It requires that
if a transaction attempts to lock a node, then that node must follow these
protocols:
o Transaction T1 should follow the lock-compatibility matrix.
o Transaction T1 firstly locks the root of the tree. It can lock it in any
mode.
o If T1 currently has the parent of the node locked in either IX or IS
mode, then the transaction T1 will lock a node in S or IS mode
only.
o If T1 currently has the parent of the node locked in either IX or
SIX modes, then the transaction T1 will lock a node in X, SIX, or
IX mode only.
o If T1 has not previously unlocked any node only, then the
Transaction T1 can lock a node.
o If T1 currently has none of the children of the node-locked only,
then Transaction T1 will unlock a node.
Observe that in multiple-granularity, the locks are acquired in top-down
order, and locks must be released in bottom-up order.

o If transaction T1 reads record Ra9 in file Fa, then transaction T1
needs to lock the database, area A1 and file Fa in IX mode. Finally,
it needs to lock Ra2 in S mode.
o If transaction T2 modifies record Ra9 in file Fa, then it can do so
after locking the database, area A1 and file Fa in IX mode. Finally,
it needs to lock the Ra9 in X mode.
o If transaction T3 reads all the records in file Fa, then transaction T3
needs to lock the database, and area A in IS mode. At last, it needs
to lock Fa in S mode.
o If transaction T4 reads the entire database, then T4 needs to lock
the database in S mode.
Recovery and Atomicity in DBMS
Introduction
Data may be monitored, stored, and changed rapidly and effectively
using a DBMS (Database Management System).A database possesses
atomicity, consistency, isolation, and durability qualities. The ability of a
system to preserve data and changes made to data defines its durability.
A database could fail for any of the following reasons:
o System breakdowns occur as a result of hardware or software
issues in the system.
o Transaction failures arise when a certain process dealing with data
updates cannot be completed.
o Disk crashes may occur as a result of the system's failure to read
the disc.

o Physical damages include issues such as power outages or natural
disasters.
o The data in the database must be recoverable to the state they were
in prior to the system failure, even if the database system fails. In
such situations, database recovery procedures in DBMS are
employed to retrieve the data.
The recovery procedures in DBMS ensure the database's atomicity and
durability. If a system crashes in the middle of a transaction and all of its
data is lost, it is not regarded as durable. If just a portion of the data is
updated during the transaction, it is not considered atomic. Data
recovery procedures in DBMS make sure that the data is always
recoverable to protect the durability property and that its state is retained
to protect the atomic property. The procedures listed below are used to
recover data from a DBMS,
o Recovery based on logs.
o Recovery through Deferred Update
o Immediate Recovery via Immediate Update
The atomicity attribute of DBMS safeguards the data state. If a data
modification is performed, the operation must be completed entirely, or
the data's state must be maintained as if the manipulation never
occurred. This characteristic may be impacted by DBMS failure brought
on by transactions, but DBMS recovery methods will protect it.
What exactly is a Log-Based Recovery?
Every DBMS has its own system logs, which record every system
activity and include timestamps for the event's timing. Databases
manage several log files for operations such as errors, queries, and other
database updates. The log is saved in the following file formats:

o The structure [start transaction, T] represents the start of
transaction T execution.
o [write the item, T, X, old value, new value] indicates that the
transaction T changes the value of the variable X from the old
value to the new value.
o [read item, T, X] indicates that the transaction T reads the value of
X.
o [commit, T] signifies that the modifications to the data have been
committed to the database and cannot be updated further by the
transaction. There will be no errors after the database has been
committed.
o [abort, T] indicates that the transaction, T, has been cancelled.
We may utilize these logs to see how the state of the data changes during
a transaction and recover it to the prior or new state.
An undo operation can be used to inspect the [write item, T, X, old
value, new value] operation and restore the data state to old data. The
only way to restore the previous state of data to the new state that was
lost due to a system failure is to do the [commit, T] action.
Consider the following series of transactions: t1, t2, t3, and t4. The
system crashes after the fourth transaction; however, the data can still be
retrieved to the state it was in before the checkpoint was established
during transaction t1.
After all of the records of a transaction are written to logs, a checkpoint
is created to transfer all of the logs from local storage to permanent
storage for future usage.
What is the Conceded Update Method?
Until the transaction enters its final stage or during the commit
operation, the data is not changed using the conceded update

mechanism. Following this procedure, the data is updated and
permanently placed in the main memory.
In the event of a failure, the logs, which are preserved throughout the
process, are utilized to identify the fault's precise moment. We benefit
from this because even if the system crashes before the commit step, the
database's data is not altered, and the status is managed. If the system
fails after the commit stage, we may quickly redo the changes to the new
stage, as opposed to the undo procedure.
Many databases configure logging automatically, but we can also
configure them manually. To configure logging into a MySQL database,
perform the following steps in the MySQL terminal.
o Create a variable to hold the path to the log file (.log) where the
logs must be saved,
1. SET GLOBAL general_log_file='/var/log/mysql/general.log';
o Configure the log file format,
1. SET GLOBAL log_output = 'FILE';
o The database's general logging function should be enabled,
1. SET GLOBAL general_log = 'ON';
o The system now monitors all database activities and logs them in
the general.log file. The settings for this are kept in the general log
file variable and may be viewed using the command,
1. SHOW VARIABLES LIKE "general_log%";

Recovery With Concurrent Transactions


Concurrency control means that multiple transactions can be executed at
the same time and then the interleaved logs occur. But there may be
changes in transaction results so maintain the order of execution of those
transactions.
During recovery, it would be very difficult for the recovery system to
backtrack all the logs and then start recovering.
Recovery with concurrent transactions can be done in the following four
ways.
1. Interaction with concurrency control
2. Transaction rollback
3. Checkpoints
4. Restart recovery
Interaction with concurrency control :
In this scheme, the recovery scheme depends greatly on the concurrency
control scheme that is used. So, to rollback a failed transaction, we must
undo the updates performed by the transaction.
Transaction rollback :
 In this scheme, we rollback a failed transaction by using the log.
 The system scans the log backward a failed transaction, for every log
record found in the log the system restores the data item.
Checkpoints :
 Checkpoints is a process of saving a snapshot of the applications state
so that it can restart from that point in case of failure.

 Checkpoint is a point of time at which a record is written onto the
database form the buffers.
 Checkpoint shortens the recovery process.
 When it reaches the checkpoint, then the transaction will be updated
into the database, and till that point, the entire log file will be
removed from the file. Then the log file is updated with the new step
of transaction till the next checkpoint and so on.
 The checkpoint is used to declare the point before which the DBMS
was in the consistent state, and all the transactions were committed.
To ease this situation, ‘Checkpoints‘ Concept is used by the most
DBMS.
 In this scheme, we used checkpoints to reduce the number of log
records that the system must scan when it recovers from a crash.
 In a concurrent transaction processing system, we require that the
checkpoint log record be of the form <checkpoint L>, where ‘L’ is a
list of transactions active at the time of the checkpoint.
 A fuzzy checkpoint is a checkpoint where transactions are allowed to
perform updates even while buffer blocks are being written out.
Restart recovery :
 When the system recovers from a crash, it constructs two lists.
 The undo-list consists of transactions to be undone, and the redo-list
consists of transaction to be redone.
 The system constructs the two lists as follows: Initially, they are both
empty. The system scans the log backward, examining each record,
until it finds the first <checkpoint> record.
Log based Recovery in DBMS


The atomicity property of DBMS states that either all the operations of
transactions must be performed or none. The modifications done by an
aborted transaction should not be visible to the database and the
modifications done by the committed transaction should be visible. To
achieve our goal of atomicity, the user must first output stable storage
information describing the modifications, without modifying the

database itself. This information can help us ensure that all
modifications performed by committed transactions are reflected in the
database. This information can also help us ensure that no modifications
made by an aborted transaction persist in the database.
Log and log records
The log is a sequence of log records, recording all the updated
activities in the database. In stable storage, logs for each transaction
are maintained. Any operation which is performed on the database is
recorded on the log. Prior to performing any modification to the
database, an updated log record is created to reflect that modification.
An update log record represented as: <Ti, Xj, V1, V2> has these fields:
1. Transaction identifier: Unique Identifier of the transaction that
performed the write operation.
2. Data item: Unique identifier of the data item written.
3. Old value: Value of data item prior to write.
4. New value: Value of data item after write operation.
Other types of log records are:
1. <Ti start>: It contains information about when a transaction Ti
starts.
2. <Ti commit>: It contains information about when a transaction Ti
commits.
3. <Ti abort>: It contains information about when a transaction Ti
aborts.
Undo and Redo Operations
Because all database modifications must be preceded by the creation of
a log record, the system has available both the old value prior to the
modification of the data item and new value that is to be written for

data item. This allows system to perform redo and undo operations as
appropriate:
1. Undo: using a log record sets the data item specified in log record
to old value.
2. Redo: using a log record sets the data item specified in log record
to new value.
The database can be modified using two approaches –
1. Deferred Modification Technique: If the transaction does not
modify the database until it has partially committed, it is said to use
deferred modification technique.
2. Immediate Modification Technique: If database modification
occur while the transaction is still active, it is said to use immediate
modification technique.
Recovery using Log records
After a system crash has occurred, the system consults the log to
determine which transactions need to be redone and which need to be
undone.
1. Transaction Ti needs to be undone if the log contains the record <Ti
start> but does not contain either the record <Ti commit> or the
record <Ti abort>.
2. Transaction Ti needs to be redone if log contains record <Ti start>
and either the record <Ti commit> or the record <Ti abort>.
Use of Checkpoints – When a system crash occurs, user must consult
the log. In principle, that need to search the entire log to determine this
information. There are two major difficulties with this approach:
1. The search process is time-consuming.
2. Most of the transactions that, according to our algorithm, need to be
redone have already written their updates into the database.
Although redoing them will cause no harm, it will cause recovery to
take longer.
To reduce these types of overhead, user introduce checkpoints. A log
record of the form <checkpoint L> is used to represent a checkpoint in
log where L is a list of transactions active at the time of the
checkpoint. When a checkpoint log record is added to log all the
transactions that have committed before this checkpoint have <Ti

commit> log record before the checkpoint record. Any database
modifications made by Ti is written to the database either prior to the
checkpoint or as part of the checkpoint itself. Thus, at recovery time,
there is no need to perform a redo operation on Ti. After a system
crash has occurred, the system examines the log to find the last
<checkpoint L> record. The redo or undo operations need to be applied
only to transactions in L, and to all transactions that started execution
after the record was written to the log. Let us denote this set of
transactions as T. Same rules of undo and redo are applicable on T as
mentioned in Recovery using Log records part. Note that user need to
only examine the part of the log starting with the last checkpoint log
record to find the set of transactions T, and to find out whether a
commit or abort record occurs in the log for each transaction in T. For
example, consider the set of transactions {T0, T1, . . ., T100}. Suppose
that the most recent checkpoint took place during the execution of
transaction T67 and T69, while T68 and all transactions with
subscripts lower than 67 completed before the checkpoint. Thus, only
transactions T67, T69, . . ., T100 need to be considered during the
recovery scheme. Each of them needs to be redone if it has completed
(that is, either committed or aborted); otherwise, it was incomplete,
and needs to be undone.
Log-based recovery is a technique used in database management
systems (DBMS) to recover a database to a consistent state in the event
of a failure or crash. It involves the use of transaction logs, which are
records of all the transactions performed on the database.
In log-based recovery, the DBMS uses the transaction log to
reconstruct the database to a consistent state. The transaction log
contains records of all the changes made to the database, including
updates, inserts, and deletes. It also records information about each
transaction, such as its start and end times.
When a failure occurs, the DBMS uses the transaction log to determine
which transactions were incomplete at the time of the failure. It then
performs a series of operations to undo the incomplete transactions and
redo the completed ones. This process is called the redo/undo recovery
algorithm.

The redo operation involves reapplying the changes made by
completed transactions that were not yet saved to the database at the
time of the failure. This ensures that all changes are applied to the
database.
The undo operation involves undoing the changes made by incomplete
transactions that were saved to the database at the time of the failure.
This restores the database to a consistent state by reversing the effects
of the incomplete transactions.
Once the redo and undo operations are completed, the DBMS can
bring the database back online and resume normal operations.
Log-based recovery is an essential feature of modern DBMSs and
provides a reliable mechanism for recovering from failures and
ensuring the consistency of the database.
Advantages of Log based Recovery
 Durability: In the event of a breakdown, the log file offers a
dependable and long-lasting method of recovering data. It
guarantees that in the event of a system crash, no committed
transaction is lost.
 Faster Recovery: Since log-based recovery recovers databases by
replaying committed transactions from the log file, it is typically
faster than alternative recovery methods.
 Incremental Backup: Backups can be made in increments using
log-based recovery. Just the changes made since the last backup are
kept in the log file, rather than creating a complete backup of the
database each time.
 Lowers the Risk of Data Corruption: By making sure that all
transactions are correctly committed or canceled before they are
written to the database, log-based recovery lowers the risk of data
corruption.
Disadvantages of Log based Recovery
 Additional overhead: Maintaining the log file incurs an additional
overhead on the database system, which can reduce the performance
of the system.

 Complexity: Log-based recovery is a complex process that requires
careful management and administration. If not managed properly, it
can lead to data inconsistencies or loss.
 Storage space: The log file can consume a significant amount of
storage space, especially in a database with a large number of
transactions.
 Time-Consuming: The process of replaying the transactions from
the log file can be time-consuming, especially if there are a large
number of transactions to recover.
Conclusion
In conclusion, data integrity and system reliability are maintained by
log-based recovery in database management systems. It minimizes data
loss and ensures reliability by assisting in the continuous restoration of
databases following failures.

DBMS lecture notes on 4 useful for stidents

More Related Content

Similar to DBMS lecture notes on 4 useful for stidents (20)

Recently uploaded (20)

DBMS lecture notes on 4 useful for stidents