Implementation of Atomicity and Durability using Shadow Copy

The recovery-management component of a database system can support atomicity and durability by a variety of schemes.

Here we are going to learn about one of the simplest scheme called Shadow copy.

Shadow copy:

• In the shadow-copy scheme, a transaction that wants to update the database first creates a complete copy of the database. All updates are done on the new database copy, leaving the original copy, the shadow copy, untouched. If at any point the transaction has to be aborted, the system merely deletes the new copy. The old copy of the database has not been affected.
• This scheme is based on making copies of the database, called shadow copies, assumes that only one transaction is active at a time. The scheme also assumes that the database is simply a file on disk. A pointer called db-pointer is maintained on disk; it points to the current copy of the database.

If the transaction completes, it is committed as follows:

• First, the operating system is asked to make sure that all pages of the new copy of the database have been written out to disk. (Unix systems use the flush command for this purpose.)
• After the operating system has written all the pages to disk, the database system updates the pointer db-pointer to point to the new copy of the database; the new copy then becomes the current copy of the database. The old copy of the database is then deleted.

Figure below depicts the scheme, showing the database state before and after the update.

The transaction is said to have been committed at the point where the updated db pointer is written to disk.

How the technique handles transaction failures:

• If the transaction fails at any time before db-pointer is updated, the old contents of the database are not affected.
• We can abort the transaction by just deleting the new copy of the database.
• Once the transaction has been committed, all the updates that it performed are in the database pointed to by db pointer.
• Thus, either all updates of the transaction are reflected, or none of the effects are reflected, regardless of transaction failure.

How the technique handles system failures:

• Suppose that the system fails at any time before the updated db-pointer is written to disk. Then, when the system restarts, it will read db-pointer and will thus see the original contents of the database, and none of the effects of the transaction will be visible on the database.
• Next, suppose that the system fails after db-pointer has been updated on disk. Before the pointer is updated, all updated pages of the new copy of the database were written to disk.
• Again, we assume that, once a file is written to disk, its contents will not be damaged even if there is a system failure. Therefore, when the system restarts, it will read db-pointer and will thus see the contents of the database after all the updates performed by the transaction.

Extra Points:

The implementation actually depends on the write to db-pointer being atomic; that is, either all its bytes are written or none of its bytes are written.

If some of the bytes of the pointer were updated by the write, but others were not, the pointer is meaningless, and neither old nor new versions of the database may be found when the system restarts.

Luckily, disk systems provide atomic updates to entire blocks, or at least to a disk sector.

In other words, the disk system guarantees that it will update db-pointer atomically, as long as we make sure that db-pointer lies entirely in a single sector, which we can ensure by storing db-pointer at the beginning of a block.

Thus, the atomicity and durability properties of transactions are ensured by the shadow-copy implementation of the recovery-management component.

Note: Unfortunately, this implementation is extremely inefficient in the context of large
databases, since executing a single transaction requires copying the entire database.
Furthermore, the implementation does not allow transactions to execute concurrently
with one another. There are practical ways of implementing atomicity and durability
that are much less expensive and more powerful. These ways come under Recovery techniques which I will be writing in separate post.

Hope you enjoyed reading about shadow copy scheme in DBMS. you may share your thoughts/ideas on this post using comment section below.

you may also like reading about Machine Learning. I am listing below some of the good reads on Machine Learning:

• What is Linear Regression? Part: 1
• What is Linear Regression? Part: 2
• Co-variance and Correlation
• What is the Coefficient of Determination | R Square
• Feature Selection Techniques in Regression Model
• Important Use Cases of NLP