Which of the following is the recovery management technique in DDBMS?

Concept.

Recovery management is the DBMS component that returns a database to a consistent state after a failure, and every technique in it works by reading a stable log that survives a crash. A distributed DBMS carries one extra obligation on top of the centralised case: global atomicity, meaning a transaction must take effect at every participating site or at none of them. Distributed recovery management therefore spans three complementary layers — a local update-and-logging protocol that undoes or redoes work at one site, physical redundancy that survives destruction of the storage medium itself, and an atomic-commit protocol that makes a single commit-or-abort decision binding on all sites.

Application to this item.

Each mechanism named in this question occupies one of those three layers:

1. Atomic-commit layer — Two Phase Commit. In the voting phase the coordinator asks every participating site to prepare, and each site force-writes a prepare record to its stable log before voting yes. In the decision phase the coordinator force-writes commit or abort and broadcasts it. If a site crashes while prepared, on restart it finds the prepare record in its log, learns the global decision from the coordinator or its peers, and then finishes or rolls back. That restart procedure is distributed recovery, not merely commitment.

2. Media-redundancy layer — Backup. Log-based undo and redo can only replay work whose data pages still exist. A disk failure destroys those pages, so a periodic archival dump is taken to separate storage; restoration reloads the most recent dump and then rolls the log forward from the instant the dump was taken, rebuilding a lost site so it can rejoin the distributed system.

3. Local update-and-logging layer — Immediate update. Changes are written into the database before the transaction commits, with the write-ahead rule forcing each log record to stable storage first. On restart the recovery manager undoes the writes of transactions that carry no commit record and redoes the writes of those that do, using the before-images and after-images held in the log.

Cross-check.

The three layers are not substitutes for one another — each repairs a failure class the others cannot:

• A commit protocol alone cannot rebuild a destroyed disk.

• An archival copy alone cannot resolve an in-doubt transaction that is prepared but undecided.

• Update-in-place logging alone cannot make independent sites agree on one outcome.

Because all three named mechanisms sit inside distributed recovery management, the accepted answer is All of the above.

A note on the nuance. Two Phase Commit is usually introduced as a distributed commit protocol rather than as a recovery technique. It earns its place here through its termination and recovery protocols: the actions a participant or a replacement coordinator performs after a crash to resolve an in-doubt transaction are exactly recovery actions, and standard distributed-database texts present 2PC inside the distributed reliability and recovery chapter for that reason.