DATABASE PRESENTATION

GROUP ONE
 Pessimistic Algorithms

• Is where you assume that all the users are trying to access the same record and it
literally locks the record exclusively for the first started transaction until it is
completed successfully or failed. Then the lock is released and the next transaction
on the record is handled in the same way.
• For example, an account is locked as soon as it is accessed in a transaction
therefore attempts to use other accounts in other transaction while it is locked will
either result in other processes being delayed until the account locked is released or
that process transaction will roll back.
•Example of Locking Mechanism
 Optimistic Algorithms

• Is a scenario whereby multiple transactions can frequently complete

without interfering with each other and these transactions use data
resources without acquiring locks on those resources. It is when you check if
the record was updated by someone else before you commit the
transaction.
• In cases of a conflict, changes made by one of the users are updated in this
case since they are time stamped the earlier transaction is given priority; the
other user’s transaction is aborted or rolled back
 For example, in a banking application the amount of an account is saved when
the account is first accessed in a transaction if the transaction changes the
account amount, the amount is read from the store again just before the
amount is about to be updated if the amount has changed since the
transaction has begun the transaction will fail itself otherwise the new amount
is written to persistent storage.
 
 Database Recovery

• It is the process of restoring the data base to a correct state in the event of a failure
that is the process of restoring database to the most recent consistent state that
existed shortly before the time of system failure. The failure may be the result of a
system crush due to hardware or software errors in the application such as a logical
error in the programming that is accessing the database.
For example, if the system crushes before a fund transfer transaction completes its
execution, then either one or both accounts may have incorrect value thus, the
database must be restored to the state before transaction modified any of the accounts.
 Database recovery techniques
Log based technique

• The log is an order of sequence of records, which sustains the operations record
accomplished by a transaction in the database
• In this, all events that have occurred in the database, like a record of every
single statement executed is backed up. It is the backup of transaction log
entries and contains all transaction that had happened to the database.
Through this, the database can be recovered to a specific point in time. For
example, it is even possible to perform a backup from a transaction log if the
data files are destroyed and not even a single committed transaction is lost.
• <TRX, Start>

• In the above syntax, we use TRX and start in which TRX means transaction and when a
transaction in the initial state that means we write start a log.
• <TRX, Name, 'First Name', 'Last Name' >
In this syntax where TRX means transaction and name is used to First Name and Last Name.
When we modify the name First Name to the Last Name then it writes a separate log file for
that.

<TRX, Commits>
• In the above syntax, we use two-variable transactions as TRX and commits,
when transaction execution is finished then it is written into another log file
that means the end of the transaction we called commits.
 Shadow paging
• It is a recovery technique that is used to recover database. In this recovery
technique, database is considered as made up of fixed size of logical units of
storage which are referred as pages. pages are mapped into physical blocks
of storage, with help of the page table which allow one entry for each
logical page of database. This method uses two page tables named current
page table and shadow page table.
• The entries which are present in current page table are used to point to
most recent database pages on disk. Another table i.e., Shadow page table
is used when the transaction starts which is copying current page table.
After this, shadow page table gets saved on disk and current page table is
going to be used for transaction. Entries present in current page table may
be changed during execution but in shadow page table it never gets
changed. After transaction, both tables become identical.
 Checkpoint
• The checkpoint is an established process where all the logs which are
previously used are clear out from the system and stored perpetually in a
storage disk. Checkpoint mention a point before which the DBMS was in a
compatible state, and all the transactions were perpetrated (carried out).  
 What is Data Recovery?

• It is the method of restoring the database to its correct state in the event of a
failure at the time of the transaction or after the end of a process.
 What is the Need for Recovery of data?

• The storage of data usually includes four types of media with an increasing
amount of reliability: the main memory, the magnetic disk, the magnetic tape,
and the optical disk. Many different forms of failure can affect database
processing and/or transaction, and each of them has to be dealt with differently.
Some data failures can affect the main memory only, while others involve non-
volatile or secondary storage also. Among the sources of failure are:
• Due to hardware or software errors, the system crashes, which ultimately
resulting in loss of main memory.
• Failures of media, such as head crashes or unreadable media that results in the
loss of portions of secondary storage.
• There can be application software errors, such as logical errors that are
accessing the database that can cause one or more transactions to abort or fail.
• Natural physical disasters can also occur, such as fires, floods, earthquakes, or power
failures.
• Carelessness or unintentional destruction of data or directories by operators or users.
• Damage or intentional corruption or hampering of data (using malicious software or
files) hardware or software facilities.
Whatever the grounds of the failure are, there are two principal things that you have to
consider:
1.Failure of main memory, including that database buffers.

2.Failure of the disk copy of that database.

 Failure Classification

• To see where the problem has occurred, failure is generalized into various
categories, as follows –
 Transaction failure:

• Logical errors: transaction cannot complete due to some internal error

condition
• System errors: the database system must terminate an active transaction
due to an error condition (e.g., deadlock)
• System crash: a power failure or other hardware or software failure that
causes the system to crash.
Fail-stop assumption: non-volatile storage contents are assumed to not be
corrupted by the system crash; database systems have numerous integrity checks
to prevent corruption of disk data which include:
• Mirroring- aka data replication; it maintains two or more copies of the same
data in the storage device, integrity checks can be made by comparing the
copies. An integrity violation in one of the copies can be easily detected
using this method. 
• RAID (Redundant Array of Independent Disks) parity- RAID is a disk
subsystem that increases performance or provides fault tolerance or both.
In computers, parity (from the Latin paritas, meaning equal or equivalent) is
a technique that checks whether data has been lost or written over when it
is moved from one place in storage to another or when it is transmitted
between computers.
• Check summing- a checksum is a single value that is computed for a block
of data (pretty simple idea); to determine if the data is corrupted (i.e. it has
changed) a checksum is computed on the data and a check is done to see
whether it matches the original stored checksum (assuming the original
stored checksum is correct); there are a number of check sum algorithms
used in this case.
• Disk failure: a head crash or similar disk failure destroys all or part of disk
storage
• Destruction is assumed to be detectable: disk drives use checksums to
detect failures
Recovery and Atomicity

• When a system crashes, it may have several transactions being executed

and various files opened for them to modify the data items. Transactions are
made of various operations, which are atomic in nature. But according to
ACID properties of the DBMS, atomicity of transactions as a whole must be
maintained, that is, either all the operations are executed or none.
• Modifying the database without ensuring that the transaction will commit
may leave the database in an inconsistent state. Consider transaction Ti that
transfers $50 from account
• A to account B; goal is either to perform all database modifications made by
Ti or none at all. Several output operations may be required for Ti (to output
A and B). A failure may occur after one of these modifications have been
made but before all of them are made.
 When a DBMS recovers from a crash, it should
maintain the following −
• It should check the states of all the transactions, which were being executed.
• A transaction may be in the middle of some operation; the DBMS must ensure
the atomicity of the transaction in this case.
• It should check whether the transaction can be completed now or it needs to be
rolled back.
• No transactions would be allowed to leave the DBMS in an inconsistent state.
Database Recovery Techniques

There are two types of techniques, which can help a DBMS in recovering as
well as maintaining the atomicity of a transaction −

Maintaining the logs of each transaction, and writing them onto some stable
storage before actually modifying the database.
 Log-based Recovery

• Log is a sequence of records, which maintains the records of actions

performed by a transaction. It is important that the logs are written prior to
the actual modification and stored on a stable storage media, which is
failsafe.
• Log-based recovery works as follows −
• The log file is kept on a stable storage media.
• When a transaction enters the system and starts execution, it writes a log
about it.
• <T , Start>
n

• When the transaction modifies an item X, it writes logs as follows −

• <T , X, V , V >
n 1 2

• It reads T has changed the value of X, from V to V .

n 1 2

• When the transaction finishes, it logs −

• <T , commit>
n
• The database can be modified using two approaches that is
a) Deferred database modification −
The deferred database modification scheme records all modifications to the
log, but defers all the writes to after partial commit.
Assume that transactions execute serially
Transaction starts by writing <Ti start> record to log.
A write(X) operation results in a log record <Ti, X, V> being written, where V is the new value for X

The write is not performed on X at this time, but is deferred.

When Ti partially commits, <Ti commit> is written to the log
Finally, the log records are read and used to actually execute the previously deferred writes.
During recovery after a crash, a transaction needs to be redone if and only if
both <Ti start> and <Ti commit> are there in the log
Redoing a transaction Ti (redo Ti) sets the value of all data items updated by
the transaction to the new values.
Crashes can occur while the transaction is executing the original updates, or
while recovery action is being taken.
b) Immediate database modification
The immediate database modification scheme allows database updates of an uncommitted
transaction to be made as the writes are issued; since undoing may be needed, update logs
must have both old value and new value. Update log record must be written before database
item is written
Recovery procedure has two operations instead of one:

a) undo(Ti) restores the value of all data items updated by Ti to their old values,
going backwards from the last log record for Ti

b) redo(Ti ) sets the value of all data items updated by Ti to the new values, going
forward from the first log record for Ti
Both operations must be idempotent i.e. even if the operation is executed multiple times, the effect is
the same as if it is executed once; this is needed since operations may get re-executed during recovery

When recovering after failure:

Transaction Ti needs to be undone if the log contains the record <Ti start>, but does not contain the
record <Ti commit>.
Transaction Ti needs to be redone if the log contains both the record <Ti start> and the record <Ti
commit>.
Undo operations are performed first, then redo operations
 Maintaining shadow paging

• This is the method where all the transactions are executed in the primary
memory or the shadow copy of database. Once all the transactions
completely executed, it will be updated to the database
Whenever any page is about to be written for the first time:

• A copy of this page is made onto an unused page.

• The current page table is then made to point to the copy
• The update is performed on the copy
• Shadow paging is an alternative to log-based recovery techniques, which has both advantages and
disadvantages.
• . It may require fewer disk accesses, but it is hard to extend paging to allow multiple concurrent
transactions.
• The paging is very similar to paging schemes used by the operating system for memory management.
• The idea is to maintain two page tables during the life of a transaction: the current page table and the
shadow page table.
• . This guarantees that the shadow page table will point to the database pages corresponding to the
state of the database prior to any transaction that was active at the time of the crash, making aborts
automatic.  
• When the transaction starts, both tables are identical. The shadow page is never
changed during the life of the transaction.
• The current page is updated with each write operation.
• Each table entry points to a page on the disk. When the transaction is committed,
the shadow page entry becomes a copy of the current page table entry and the disk
block with the old data is released.
• . If the shadow is stored in non-volatile memory and a system crash occurs, then the
shadow page table is copied to the current page table
To commit a transaction :
• 1. Flush all modified pages in main memory to disk
• 2. Output current page table to disk
• 3. Make the current page table the new shadow page table, as follows:
 • keep a pointer to the shadow page table at a fixed (known) location on disk.
• to make the current page table the new shadow page table, simply update
the pointer to point to current page table on disk
• Once pointer to shadow page table has been written, transaction is committed.
• No recovery is needed after a crash — new transactions can start right away,
using the shadow page table.
• Pages not pointed to from current/shadow page table should be freed (garbage
collected).
drawbacks to the shadow-page technique:
Commit overhead. The commit of a single transaction using shadow paging requires
multiple blocks to be output -- the current page table, the actual data and the disk address
of the current page table. Log-based schemes need to output only the log records.
Data fragmentation. Shadow paging causes database pages to change locations (therefore,
no longer contiguous.
Garbage collection. Each time that a transaction commits, the database pages containing
the old version of data changed by the transactions must become inaccessible. Such pages
are considered to be garbage since they are not part of the free space and do not contain any
usable information
 Checkpoint

• Checkpoint is a mechanism where all the previous logs are removed from
the system and stored permanently in a storage disk.
• . Checkpoint declares a point before which the DBMS was in consistent
state, and all the transactions were committed
• The recovery system reads the logs backwards from the end to the last
checkpoint.
• It maintains two lists, an undo-list and a redo-list.
• If the recovery system sees a log with <T , Start> and <T , Commit> or just <T ,
n n n
Commit>, it puts the transaction in the redo-list.
• If the recovery system sees a log with <T , Start> but no commit or abort log
n
found, it puts the transaction in undo-list.
• All the transactions in the undo-list are then undone and their logs are
removed. All the transactions in the redo-list and their previous logs are
removed and then redone before saving their logs.