Transaction Management in DBMS
Transaction
management in a DBMS refers to the process of ensuring that database operations
are executed in a consistent and reliable way. Transactions are a sequence of
one or more database operations that are executed together as a single unit of
work. 
Transaction Management in DBMS
Transaction management in a DBMS refers to the process of ensuring that
database operations are executed in a consistent and reliable way. Transactions
are a sequence of one or more database operations that are executed together as
a single unit of work. The operations within a transaction must be atomic,
consistent, isolated, and durable (ACID).
Transaction management is an important feature of DBMS as it ensures
data integrity and consistency in the database and allows multiple users to
access and manipulate the data in a concurrent manner. The DBMS uses a variety
of techniques such as locks, timeouts, and rollbacks to manage concurrent
access to the database and ensure data consistency.
ACID Properties
ACID (Atomicity, Consistency, Isolation, Durability) is a set of
properties that ensure that database transactions are executed in a reliable
and consistent way.
Atomicity: This property ensures that all operations
within a transaction are executed together as a single unit of work. If one
operation fails, the entire transaction is rolled back and the database is
returned to its previous state.
Consistency: This property ensures that the database
remains in a consistent state before and after a transaction. The database must
be in a consistent state after a transaction, even if the transaction fails.
Isolation: This property ensures that transactions
are isolated from each other. Each transaction is executed as if it is the only
transaction taking place, even if other transactions are being executed
simultaneously.
Durability: This property ensures that once a
transaction is committed, its effects on the database are permanent and survive
any subsequent system failures.
In summary, ACID properties provide a way to ensure that the
database is always in a consistent state and that the integrity of data is
maintained, even when multiple users are accessing the same data
simultaneously.
DBMS Schedules
In a database management system (DBMS), a schedule is a sequence of
database operations that are executed concurrently by multiple transactions. A
schedule is a representation of the order in which operations are executed and
the locks held by transactions at different points in time.
There are two types of schedules in DBMS:
1.
Serial schedule: A schedule in which all operations are
executed one after the other in a specific order. In a serial schedule, there
is no concurrent execution of operations, and the order of execution is
determined by the order of the transactions in the schedule.
2.
Concurrent schedule: A schedule in which multiple
transactions are executed simultaneously and their operations are interleaved.
Concurrent schedules can be further divided
into two categories:
- Conflicting
schedule: A schedule in which the operations of two or more
transactions conflict with each other, for example, when two transactions
try to update the same data simultaneously.
- Non-conflicting
schedule: A schedule in which the operations of two or more
transactions do not conflict with each other and can be executed in any
order.
A DBMS uses different techniques to manage concurrency and ensure that
the schedule is conflict-free and preserves the consistency of the database.
These techniques include locks, timeouts, and rollbacks, which can be used to
manage concurrent access to the database and ensure data consistency.
Serializability
Serializability is a property of a schedule of database operations in a
concurrent database management system (DBMS) that ensures that the schedule is
equivalent to a serial schedule, in which all operations are executed one after
the other.
In a serializable schedule, the operations of multiple transactions are
executed concurrently, but they appear to have been executed one after the
other, as if they were in a serial schedule. This means that the order of the
operations in the concurrent schedule is such that it is equivalent to some
serial schedule, where the order of the operations of each transaction
preserves the consistency of the database.
There are several types of serializability, such as conflict
serializability, view serializability, and strict serializability.
The DBMS uses different techniques such as locks and timestamp ordering
to ensure serializability. Two-phase locking is the most common protocol used
to ensure the serializability of schedules in DBMS. This protocol ensures that
a transaction must acquire locks on all the data items it will access before it
can execute any operation on them, and it must release all the locks it holds
before it can commit.
Serializability is an important property of a DBMS as it ensures that
the concurrent execution of transactions does not compromise the consistency of
the database. A serializable schedule guarantees that the database remains in a
consistent state even when multiple transactions are executed simultaneously.
Log based recovery
Log-based recovery is a method used by database management systems
(DBMSs) to recover from system failures and ensure data consistency. It works
by maintaining a log, also known as a transaction log, of all the operations
performed on the database.
When a transaction is executed, the DBMS writes information about the
operation, such as the type of operation (e.g., insert, update, delete), the
data affected, and the time of the operation, to the log. This log is stored
separately from the actual data and is used to recover the database in case of
a failure.
In the event of a system failure, the DBMS uses the log to reconstruct
the state of the database before the failure. It does this by rolling back any
incomplete transactions and then replaying any committed transactions that were
not yet written to the data files. This process is called rollforward recovery.
Log-based recovery is considered a more efficient and reliable method of
recovery compared to other methods, such as checkpoint-based recovery. This is
because log-based recovery only requires the log and the database's last
checkpoint, whereas checkpoint-based recovery requires all the database's
checkpoint images.
Additionally, log-based recovery allows DBMS to perform incremental
backups and point-in-time recovery, which enables DBAs to restore the database
to a specific point in time, such as before a specific data corruption event.
In summary, Log-based recovery is a technique used by DBMS to recover
from system failures and ensure data consistency, by maintaining a log of all
the operations performed on the database. This log is used to reconstruct the
state of the database before the failure, and it allows for incremental backups
and point-in-time recovery.
DBMS checkpoint
A checkpoint in a database management system (DBMS) is a process that
periodically saves the state of the database, including the contents of memory
and disk, to a specific point in time. This allows the DBMS to recover quickly
and efficiently in the event of a system failure, such as a power outage or a
crash.
Checkpoints are typically performed at regular intervals, such as every
hour or every day, but can also be triggered by certain events, such as
reaching a certain amount of log data. When a checkpoint occurs, the DBMS first
writes the current state of memory (e.g. buffer pool) to disk, and then updates
the metadata on disk to indicate that a checkpoint has occurred.
There are different types of checkpoint, such as:
- Full
checkpoint: A full checkpoint is a complete copy of the entire
database, including data and metadata, stored on disk.
- Incremental
checkpoint: An incremental checkpoint is a copy of only the
changes made to the database since the last checkpoint.
- Partial
checkpoint: A partial checkpoint is a copy of only a subset of the
database, such as specific tables or indexes.
Checkpoint-based recovery is a method of recovery that uses the
checkpoint to restore the database to its last consistent state, by rolling
forward or backward the changes. This method of recovery is less efficient
and less flexible than the log-based recovery, because it requires all the
checkpoint images, and it doesn't allow incremental backups or point-in-time
recovery.
In summary, a checkpoint is a process that periodically
saves the state of the database to a specific point in time, allowing the DBMS
to recover quickly and efficiently in the event of a system failure.
Checkpoints can be performed at regular intervals or triggered by certain
events. Checkpoint-based recovery is a method of recovery that uses the
checkpoint, but it is less efficient and less flexible than log-based recovery.
DBMS Deadlock
A deadlock in a database management system (DBMS) occurs when two
or more transactions are unable to proceed because they are waiting for
resources that are held by the other transactions. This creates a situation
where none of the transactions can complete, resulting in a standstill or
"deadlock" state.
Deadlocks can occur in a variety of ways, but typically happen when
multiple transactions try to access the same resource (e.g. a record or a
table) simultaneously and in a conflicting order. For example, if one
transaction wants to update a record and another transaction wants to delete
it, they would be in a deadlock state because neither can proceed until the
other releases the resource.
To detect and resolve deadlocks, DBMSs use a technique called
"deadlock detection and resolution". This involves periodically
checking for deadlocks and, if one is found, choosing one of the transactions
to "abort" or "rollback" so that the other transactions can
proceed. The choice of which transaction to abort is typically determined by a
priority system or a "wait-die" algorithm.
There are several methods to avoid deadlocks:
- Timeout: Transactions
are given a finite amount of time to acquire resources before they are
rolled back.
- Resource
ordering: Resources are acquired in a specific order, such as
alphabetical order, to prevent conflicting resource requests.
- Deadlock
prevention: Transactions are required to request resources in a
specific order, such as always requesting resources in increasing order of
resource number.
In summary, a deadlock in a DBMS occurs when two or more
transactions are unable to proceed because they are waiting for resources held
by the other transactions. This creates a standstill state where none of the
transactions can complete. Deadlock detection and resolution is a technique
used by DBMSs to detect and resolve deadlocks by periodically checking for
deadlocks and choosing one of the transactions to abort. There are several
methods to avoid deadlocks like Timeout, Resource ordering and Deadlock
prevention.
Starvation in DBMS
Starvation in a database management system (DBMS)
occurs when a transaction is unable to acquire the resources it needs to
complete its task because they are being held by other transactions. This
results in the transaction being "starved" and unable to proceed,
causing it to wait indefinitely for the resources to become available.
Starvation can occur in a variety of ways, but typically happens when a
low-priority transaction is trying to access a resource that is being held by a
high-priority transaction. For example, if a low-priority transaction is trying
to read a record that is being updated by a high-priority transaction, the
low-priority transaction may be starved and unable to proceed until the high-priority
transaction releases the resource.
To prevent starvation, DBMSs use a technique called "resource
allocation" or "resource scheduling". This involves allocating
resources to transactions based on a priority system, such that high-priority
transactions are given priority over low-priority transactions. The priority
system can be based on a number of different factors, such as the type of
transaction, the user, or the time of day.
Another method to avoid starvation is using "Fair scheduling"
where every transaction has equal chance of getting the resources, this can be
done by using a round-robin scheduling technique.
In summary, starvation in a DBMS occurs when a transaction
is unable to acquire the resources it needs to complete its task because they
are being held by other transactions, causing it to wait indefinitely for the
resources to become available. To prevent starvation, DBMSs use a technique
called resource allocation or resource scheduling, where resources are
allocated to transactions based on a priority system. Fair scheduling can also
be used where every transaction has equal chance of getting the resources.
0 Comments
If You Have Any Doubts, Please tell me know