Database Systems Quiz

The process of restoring a database to a correct state after encountering an error or failure.

Changes made to the data are written to disk immediately, ensuring that crashes do not result in data loss.

A technique that uses a separate area (shadow space) to store changes to data. This approach reduces the impact of crashes on the main database.

A robust recovery algorithm used in many database systems. It ensures consistency by understanding the order of operations and using logs to undo or redo changes as needed.

A failure where a transaction cannot proceed to completion and is aborted, potentially restarting later.

An event where the entire database system stops functioning, leaving a trail of transactions in limbo.

A failure that involves parts of the storage system, such as a broken disk.

A crash that involves losing data stored in the main memory due to sudden power loss or system malfunction.

A basic unit of work in a database system that represents a sequence of operations that are performed atomically, meaning either all of them succeed or none of them do.

The property of a transaction that ensures that all changes made by the transaction are either committed to the database or rolled back, ensuring that the database remains in a consistent state.

The property of a transaction that ensures that once a transaction is committed, its changes are permanently stored in the database and will not be lost due to system failures.

The process of applying the changes made by a transaction to the database after the transaction has been committed.

The process of undoing the changes made by a transaction that has not been committed.

A point in time during the operation of a database where the data is considered consistent and safe.

A mechanism used to periodically create copies of the database, allowing for recovery in case of data loss.

Ensures that log records are written before changes are made to the database, guaranteeing that if a failure occurs, the transaction can be undone.

A process that reverses any changes made by an incomplete transaction during recovery. This brings the database back to a consistent state.

A recovery algorithm that supports a strategy where changes are made to the database before a transaction commits, but can be undone if necessary.

A recovery algorithm that handles database updates in reverse order, ensuring consistency.

A database recovery approach that relies on using log records to reverse any uncommitted transactions.

A recovery technique that postpones writing updates to the database until the transaction commits.

If a transaction is performed using Deferred Update, and crashes before committing, there is no need to undo changes as the database was not updated.

If a transaction is performed using Deferred Update, and crashes after committing, redo operations are required to ensure updates reach the database.

In Immediate Update, undoing changes is essential if the transaction fails before completing because updates were written to the database directly.

In Immediate Update, redoing committed transactions is necessary to ensure all changes reach the database after a failure.

Shadow Paging creates a copy of the database that is updated during the transaction. Recovering is as simple as replacing the main database with the shadow copy.

A technique where the DBMS replaces a buffer frame that contains an updated page from a non-committed transaction with a new page.

A technique where all changes made by a transaction are written to disk immediately upon commit.

A technique where changes made by a transaction are not immediately written to disk; they are written later, if necessary.

The first phase of database recovery, where the log is analyzed to determine active transactions and dirty pages at the time of the crash.

The second phase of database recovery, where the database state is restored to the point before the crash using the log.

The third phase of database recovery, where transactions that did not commit are rolled back, ensuring that the database reflects only committed actions.

A principle of the ARIES recovery algorithm, stating that any change to the database must be logged before being written to disk.

A principle of the ARIES recovery algorithm where the recovery process retraces the actions of the DBMS before the crash to recreate the exact state.

A single transaction that accesses data in multiple databases managed by different DBMSs. This might involve different database types like relational, object-oriented, or hierarchical.

A recovery mechanism used in multidatabase transactions to ensure atomicity. The coordinator communicates with participating databases in two phases, preparing them for commitment and then committing or aborting the transaction.

The first stage of the Two-Phase Commit protocol where the coordinator asks each participant to confirm their readiness for committing the multidatabase transaction.

The second stage in the Two-Phase Commit protocol where the coordinator instructs each participant to either commit the transaction if all are ready, or abort the transaction if any participant encountered an error.

In the Two-Phase Commit protocol, the coordinator sends a message to each participant database, requesting confirmation if they can commit or abort the transaction.

If a participant database cannot commit the transaction during the Two-Phase Commit protocol's Prepare phase, it sends a Not OK signal to the coordinator, prompting a global abort.

A centralized component in multidatabase systems that manages the recovery process and coordinates the Two-Phase Commit protocol between different participating databases.

The role of a local database manager within the Two-Phase Commit protocol. Each participating database has its own recovery mechanism and manages its local log information.