Data is non-recoverable in case of media failure, intentional attack on the database and transactions logging data, or physical media destruction. In computing, data recovery is a process of salvaging (retrieving) inaccessible, lost, corrupted, damaged or formatted data from secondary storage, removable media or files, when the data stored in them cannot be accessed in a normal way.

1. DATA
RECOVERY

2. INTRODUCTION
• Data is non-recoverable in case of media failure, intentional attack on the database
and transactions logging data, or physical media destruction.
• In computing, data recovery is a process of salvaging (retrieving) inaccessible, lost,
corrupted, damaged or formatted data from secondary storage, removable media or
files, when the data stored in them cannot be accessed in a normal way.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

3. RECOVERY MANAGEMENT
ARCHITECTURE
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

4. Update Operation
Database Buffer
Database Manager
Recovery Manager
Secondary Memory
Log fileTransaction command
Starting stable and final
stable database
Commands for
flush and fetch
Recovery Management Architecture (RMA)
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

5. MAJOR COMPONENTS OF RMA
• Recovery Manager
• Secondary Memory
• Transaction Commands
• Database buffer Manager
• Database buffer
• Log file for Secondary Memory
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

6. Atomicity
• Uncommitted but data started transaction aborts
on failure and aborted transactions are logged in
log file.
Durability
• Committed transactions are not affected by failure
and can be recovered easily.
Recover
y
Manage
r
Ensures
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

7. SECONDARY MEMORY
• It is also known as Hard Disk or the auxiliary memory.
• Stable state of the databases at the start and at the end of transactions reside in
secondary storage.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

8. TRANSACTION COMMANDS TO
RECOVERY MANAGER
• All the transaction commands
are sent to the recovery
manager.
• Major transaction commands
are given in the chart.
• The recovery manager then
sends fetch commands to the
database manager.
Commit
• This command is used to permanently save any transaction into the
database.
Rollback
• This command restores the database to last commited state. It is also used
with command to jump to a savepoint in an ongoing transaction.
Savepoint
• This command is used to temporarily save a transaction so that you can
rollback to that point whenever required.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

9. DATABASE & RECOVERY MANAGER
• The database manager processes the queries during the transaction and uses a
database buffer.
• The recovery manager also sends the flush commands to transfer the committed
transactions and database buffer data to the secondary storage.
• The recovery manager detects the results of operations.
• It recovers lost operations from the secondary storage.
• Recovery is by detecting the data lost during the transaction.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

10. LOG FILE USED BY RECOVERY
MANAGER
• The recovery manager uses a log file, which logs actions in the following manner:
– Each instruction for a transaction for update (insertion, deletion, replacement, and addition)
must be logged.
– Database read instructions are not logged.
– Log files are stored at a different storage mediums.
– Log entries are flushed out after the final stable state database is stored.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

11. • Each logged entry contains the following fields:
– transaction type (begin, commit, or rollback transaction)
– transaction ID
– operation-type
– object on which the operation is performed
– pre-operation and post-operation values of the object.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

12. ARIES ALGORITHM
• A procedure called the ARIES algorithm is also used for recovering lost data.
• Here 2 two data structures have to be maintained:
– the dirty page table (DPT)
– the transaction table (TT).
• The dirty page table keeps record of all the pages that have been modified and not yet
written back to disc and the first Sequence Number that caused that page to become
dirty.
• The transaction table contains all transactions that are currently running and the
Sequence Number of the last log entry they caused.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

13. • The basic steps of the algorithm are as follows:
– Analyse from last checkpoint and identify all dirty records (written again after operation
restarted) in the buffer.
– Redo all buffered operations logged in the update log to finish and make final page.
– Undo all write operations and restore pre-transaction values.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

14. DATA RECOVERY MODELS
• The recovery models used in data recovery processes are as follows:
– The full recovery model creates back up of the database and incremental backup of the
changes. All transactions are logged from the last backup taken for the database.
– The bulk logged recovery model entails logging and taking backup of bulk data record
operations but not the full logging and backup. Size of bulk logging is kept to the minimum
required. This improves performance. We can recover the database to the point of failure by
restoring the database with the bulk transaction log file backup. This is unlike the full
recovery model in which all operations are logged.
– The simple recovery model prepares full backups but the incremental changes are not
logged. We can recover the database to the most recent backup of the given database.
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat

15. THANK YOU
S H U B H A M I N D R AWAT
shubhamindrawat@gmail.com
www.linkedin.com/in/shubhamindrawat