-
Database transaction
A transaction is a logical unit of work that begins with a BEGIN TRANSACTION operation, contains a sequence of application-specific operations, and ending with either a COMMIT or ROLLBACK operation
-
Properties of a transaction
Atomicity, Consistency, Isolation, Durability
-
Atomicity
transactions cannot be decomposed into components and cannot be nested
-
Consistency
transactions transform a database from one consistent state to another
-
Isolation
transactions execute independently of one another
-
Durability
the effects of a successful transaction are permanently recorded in a database and must not be lost because of a failure
-
Basic principles of database recovery and protection
- Copying the entire database periodically to archive storage
- Recording the old and new values of a changed data item in a special file (log), every time a change is made to the database
- In case of a failure if the database is damaged, restoring the database by loading it from the most recent archive copy and then using the log to redo all changes since the archive was created
- In case the database is not damaged but its contents are unreliable, restoring the database to its current state by using the log to undo all unreliable changes
-
Why is data redundancy important from the point of view of database recovery and protection?
If a database fails, having access to data redundancy allows the database to be reconstructed
-
What are the types of failures in transaction processing?
- Failures detected by the application program
- Failures which are not handled by the application program (transaction failures)
- System failures - effect the current transactions but do not damage the database
- Media Failures - damage the database and affect all current transactions
-
How do we cope with transaction failures?
The system forces rollback by undoing changes made and canceling the output messages produced by the transaction
-
What is system failure in a database system?
Causes the system to stop and hence require subsequent restart. The main memory content is lost but the database is not damaged. All interrupted transaction at the time of failure must be rolled back.
-
Explain the brute-force strategy for recovering from system failures.
- The recovery manager searches the log to determine the entries with a BEGIN TRANSACTION but to termination and rolls back the matching transaction.
- Searching the entire log is time comsuming
-
Explain the checkpoint-based recovery strategy from system failures.
- The system takes, at pre-determined intervals, a checkpoint which consists of the following:
- Force-writing any log records from main storage to the log
- Writing a check point record to the log
- Force-writing any updates from main storage to the database
- Recording the address of the check point record from the log file to a restart file
-
In a checkpoint-based recovery strategy, what types of transactions are undone, and what types are redone by the recovery manager?
Any transaction with an END TRANSACTION record should be redone and all others should be undone
-
What is a media failure in a database system?
Media Failure results in damage to the database
-
How do we recover from a media failure?
The recovery process consists of restoring the database from an archive copy and using the log to redo the transactions since the copy was taken
|
|