2. Transaction Failure
→ The transaction failure occurs when it fails to
execute or when it reaches a point from where
it cannot go any further. If a few transaction or
process is hurt, then this is called as
transaction failure.
Reasons for a transaction failure could be:
• Logical error: Transaction cannot complete due
to some internal error condition.
• System errors: The database system must
terminate an active transaction due to an error
condition (e.g., dead lock)
3. • System Crash
→ It can occur due to power failure or other
hardware/software failure.
Example: Operating system error.
• Disk Failure
→ It occur where hard disk drives or storage device
used to fail frequently. Disk failure occurs due to the
formation of bad sectors, disk crash and
unreachability to the disk or any other failure which
destroy all the part of disk storage.
4. Recovery
and
Atomicity
Recovery:
→ Recovery is the process of
retrieving data from damaged,
failed or corrupted storage.
Atomicity:
→ Transaction as a whole must be
maintained, that is, either all or
none.
Example: online shopping or ATM.
5. 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 need to be rolled back.
• No transactions would be allowed to leave the DBMS in an
inconsistent state.
6. Inconsistent
→ Data Inconsistent means that different files
contain different information of a particular
person or object.
Example:
Consider these two table student and address
table.
- Student table contains ID, Name, Class and
Mobile Number
- Address table contains Address of student, ID,
District and Mobile Number.
In these two tables mobile number column is
same. So, same data in the student table will be
present in address table. Now one student
wants to change his mobile number. The mobile
number in student table is updated. So, there is
inconsistent between these two data. This term
is called data inconsistency.
7. There are two types of techniques, which can
help a DBMS in recovering as well as
maintaining the atomicity of a transaction.
1) Log-based recovery
→ It assumes that transactions are executed
serially, that means only one transaction is
active at a time. It uses a structure called log to
store the database modification.
2) Shadow paging
→ This is the method where all the transactions
are executed in the primary memory or the
shadow copy of database. Once all the
transactions completely executed, it will be
updated to the database. Hence, if there is any
failure it will not be reflected in the database.
Data base will be updated after all transaction
8. Log-based Recovery
→ Log is a sequence of record, which maintains the
record 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.
The database can be modified using two approaches-
• Deferred database modification – All logs are
written on 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.
9. Recovery with
Concurrent
Transaction
• → If it is a case of execution of
two or more transactions, the
interleaving of logs will occur.
It will become very
inconvenient for the system of
recovery to backtrack every
record and start the process of
recovering.
• → Most database
management system make
use of the concept of
“checkpoint” to make the
situation more convenient and
more manageable.
10. CHECKPOINT
→ The checkpoint is a type of mechanism where all the
previous logs are removed from the system and permanently
stored in the storage disk.
→ The checkpoint is like a bookmark. The checkpoint is used
to declare a point before which the DBMS was in the
consistent state, and all transactions were committed.
During transaction executed, such checkpoints are marked,
and after execution, the log files will be created.
When it reaches to the checkpoint, then the transaction will be
updated into the database, and till the point, the entire log
file will be removed from the file. Then the log file is updated
with the new step of transaction till next checkpoint and so
on.
11. Why do we need checkpoint?
→ Whenever transaction logs are created in a real-
time environment, it eats up lots of storage space.
Also keeping track of every update and its
maintenance may increase the physical space of
the system. Eventually, the transaction log file may
not by handled as the size keeps growing. This can
be addressed with checkpoints.
Advantages of using checkpoints:
• Speeds up data recovery process.
• Prevents unnecessary redo operations.
• Since dirty pages are flushed out continuously in
the background, it has very low overhead and can
be done frequently.
12. Recovery
→ Recovery is the process of restoring the
database to a correct (consistent) state in the
event of a failure. The failure may be result of
system crash or system error. Recovery
system is used to return the database to the
checkpoint state. The behaviour when the
system crashes and recovers when concurrent
transaction are executed is shown by figure:
Checkpoint Failure
T1
T2
T3
T4
13. Recovery
• The recovery system reads log file from the end to start. It reads log files
from T4 to T1.
• It maintains two list, a redo-list, and an undo-list.
• The transaction is put into redo state if the recovery system sees a log
with <Tn, Start> and <Tn, Commit> or just <Tn, Commit>. In the redo-list
and their previous list, all the transaction are removed and then redone
before saving their logs.
For example: In the log file, transaction T2 and T3 will have <Tn, Start> and
<Tn, Commit>. The T1 transaction will have only <Tn, Commit> in the log
file. That’s why the transaction is committed after the checkpoint is
crossed. Hence it puts T1, T2 and T3 transaction into redo list.
• Te transaction is put into undo state if the recovery system sees a log
with <Tn, Start> but no commit or abort log found. In the undo-list, all the
transaction are undone, and their logs are removed.
For example: Transaction T4 will have <Tn, Start>. So T4 will be put into
undo list since this transaction is not yet completed and failed amid