Basics - A Historical Perspective
- File Systems v/s DBMS
- Data Models
- Levels of Abstraction
- Structure of DBMS
- Database Design
- Database Design
- ER Diagrams
- Attributes
- Entity
- Relationships
- Additional Features of the ER Model
- Relational Model
- Introduction to the Relational Model
- Integrity constraint over relations
- Enforcing Integrity Constraints
- Querying Relational Data
- Views
- Relational Algebra
- Tuple Relational Calculus
- SQL
- Form of basic SQL query
- UNION
- INTERSECT
- EXCEPT
- Aggregation Operators
- Complex Integrity Constraints in SQL
- Triggers and Active data bases
- Schema Refinement
- Problems caused by redundancy
- Decompositions and its problems
- Functional Dependencies and its reasoning
- Introduction to Normal Forms
- First Normal Form (1NF)
- Second Normal Form (2NF)
- Third Normal Form (3NF)
- Boyce-Codd Normal Form (BCNF)
- Fourth Normal Form (4NF)
- Fifth Normal Form (5NF or PJNF)
- Sixth Normal Form (6NF)
- Transaction
- Transaction Concept
- Transaction State
- Implementation of Atomicity and Durability
- Concurrent Executions
- Serializability
- Recoverability
- Implementation of Isolation
- Lock Based Protocols
- Timestamp Based Protocols
- Validation Based Protocols
- Multiple Granularity
- Recovery and Atomicity in dbms
- Recovery with Concurrent Transactions
- Indexing
- Data on External Storage
- File Organization and Indexing
- Cluster Indexes
- Primary Indexes
- Secondary Indexes
- Index data Structures
- Comparison of File Organizations, Indexes and Performance Tuning
- Indexed Sequential Access Methods
- Dynamic Index Structure - B+ Tree
Recovery with Concurrent Transactions in DBMS
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.
- Interaction with concurrency control
- Transaction rollback
- Checkpoints
- Restart recovery
Interaction with Concurrency Control:
This pertains to how the recovery system interacts with the concurrency control component of the DBMS.
Recovery must be aware of concurrency control mechanisms such as locks to ensure that, during recovery, operations are redone or undone in a manner consistent with the original schedule of transactions.
For example, if strict two-phase locking is used, it can simplify the recovery process. Under this protocol, once a transaction releases its first lock, it cannot acquire any new locks. This ensures that if a transaction commits, its effects are permanent and won't be overridden by any other transaction that was running concurrently.
Transaction Rollback
Sometimes, instead of recovering the whole system, it's more efficient to just rollback a particular transaction that has caused inconsistency or when a deadlock occurs.
When errors are detected during transaction execution (like constraint violations) or if a user issues a rollback command, the system uses the logs to undo the actions of that specific transaction, ensuring the database remains consistent.
The system keeps track of all the operations performed by a transaction. If a rollback is necessary, these operations are reversed using the log records.
Checkpoints
Checkpointing is a technique where the DBMS periodically takes a snapshot of the current state of the database and writes all changes to the disk. This reduces the amount of work during recovery.
By creating checkpoints, recovery operations don't need to start from the very beginning. Instead, they can begin from the most recent checkpoint, thereby considerably speeding up the recovery process.
During the checkpoint, ongoing transactions might be temporarily suspended, or their logs might be force-written to the stable storage, depending on the implementation.
Restart Recovery
In the case of a system crash, the recovery manager uses the logs to restore the database to the most recent consistent state. This process is called restart recovery.
Initially, an analysis phase determines the state of all transactions at the time of the crash. Committed transactions and those that had not started are ignored.
The redo phase then ensures that all logged updates of committed transactions are reflected in the database. Lastly, the undo phase rolls back the transactions that were active during the crash to ensure atomicity.
The presence of checkpoints can make the restart recovery process faster since the system can start the redo phase from the most recent checkpoint rather than from the beginning of the log.
Next Topic :Data on External Storage in DBMS