Unit 5

Database Recovery System

Database Recovery Concepts

Database Systems like any other computer system, are subject to failures but the data stored in
them must be available as and when required. When a database fails it must possess the facilities
for fast recovery. It must also have atomicity i.e. either transactions are completed successfully
and committed (the effect is recorded permanently in the database) or the transaction should have
no effect on the database.

Types of Recovery Techniques in DBMS

Database recovery techniques are used in database management systems (DBMS) to restore a
database to a consistent state after a failure or error has occurred. The main goal of recovery
techniques is to ensure data integrity and consistency and prevent data loss.
There are mainly two types of recovery techniques used in DBMS
 Rollback/Undo Recovery Technique
 Commit/Redo Recovery Technique

Rollback/Undo Recovery Technique

The rollback/undo recovery technique is based on the principle of backing out or undoing the
effects of a transaction that has not been completed successfully due to a system failure or error.
This technique is accomplished by undoing the changes made by the transaction using the log
records stored in the transaction log. The transaction log contains a record of all the transactions
that have been performed on the database. The system uses the log records to undo the changes
made by the failed transaction and restore the database to its previous state.

Commit/Redo Recovery Technique

The commit/redo recovery technique is based on the principle of reapplying the changes made by
a transaction that has been completed successfully to the database. This technique is accomplished
by using the log records stored in the transaction log to redo the changes made by the transaction
that was in progress at the time of the failure or error. The system uses the log records to reapply
the changes made by the transaction and restore the database to its most recent consistent state.
In addition to these two techniques, there is also a third technique called checkpoint recovery.
Checkpoint Recovery is a technique used to reduce the recovery time by periodically saving the
state of the database in a checkpoint file. In the event of a failure, the system can use the
checkpoint file to restore the database to the most recent consistent state before the failure
occurred, rather than going through the entire log to recover the database.
Overall, recovery techniques are essential to ensure data consistency and availability in Database
Management System, and each technique has its own advantages and limitations that must be
considered in the design of a recovery system.

1
Type of Database Backup – Physical and Logical
A database backup is a copy of storage that is stored on a server. Backup is used to prevent
unexpected data loss. If original data gets lost, then with the help of a backup, it is easy to gain
access to the data again.
There are two types of database backup.
 Physical backup
 Logical backup

Physical Backup:

Physical database backups are backups of physical files that are used to store and recover
databases. These include different data files, control files, archived redo logs, and many more.
Typically, physical backup data is kept in the cloud, offline storage, magnetic tape, or on a disc.
There are two methods to perform a physical backup :
1. Operating system utilities
2. Recovery manager

This type of backup is useful when the user needs to restore the complete database in a short
period. It is beneficial to provide details of transactions and changes made in databases. It is
considered the foundation of the recovery mechanism. This form of backup has the drawback of
slowing down database operations.
Advantages:
 It is useful when the user needs to restore the complete database in a short period.
 They provide details of transactions and changes made in databases.
Disadvantage:
 This slows down database operations.

Logical Backup:

It contains logical data which is retrieved from the database. It contains a view, procedure,
function, and table. This is useful When users want to restore or transfer a copy of the database to
a different location. Logical backups are not as secure as physical backups in preventing data loss.
It only provides structural details. Every week, complete logical backups should be performed.
Logical backups are used as a supplement to a physical backup.
Advantages:
 This is useful when the user needs to restore the complete database to the last time.
 It was more complex and provides granular recovery capabilities.
Disadvantages:
 Critical for recovery of special components.
 less secure compared to physical backup.
 It only provides structural details.

2
Physical Backup Vs Logical Backup:

Physical Backup Logical Backup

Physical database backups are backups of Logical database backups are backups of
physical files that are used to store and recover logical files that are retrieved from the
databases. database.

It contains data files, control files, and archived It contains a view, a procedure, a function, and
redo logs. a table.

It copies data files when data is running or Using the EXPORT keyword Logical backup
stopped. is done

This is useful when users want to restore or

A user needs to restore the complete database in
transfer a copy of the database to a different
a short period of time.
location.

More secure than logical backup. Less secure as compared to Physical backup.

Both backup strategies are beneficial. The user can select their technology based on their
requirements and organizational demands.

Failure Classification in DBMS

Failure in terms of a database can be defined as its inability to execute the specified transaction or
loss of data from the database. A DBMS is vulnerable to several kinds of failures and each of
these failures needs to be managed differently. There are many reasons that can cause database
failures such as network failure, system crash, natural disasters, carelessness, sabotage(corrupting
the data intentionally), software errors, etc.
A failure in DBMS can be classified as:

3
 Failure Classification in DBMS

Transaction Failure:

If a transaction is not able to execute or it comes to a point from where the transaction becomes
incapable of executing further then it is termed as a failure in a transaction.
Reason for a transaction failure in DBMS:
 Logical error: A logical error occurs if a transaction is unable to execute because of some
mistakes in the code or due to the presence of some internal faults.
 System error: Where the termination of an active transaction is done by the database
system itself due to some system issue or because the database management system is unable
to proceed with the transaction. For example– The system ends an operating transaction if it
reaches a deadlock condition or if there is an unavailability of resources.

System Crash:

A system crash usually occurs when there is some sort of hardware or software breakdown. Some
other problems which are external to the system and cause the system to abruptly stop or
eventually crash include failure of the transaction, operating system errors, power cuts, main
memory crash, etc.
These types of failures are often termed soft failures and are responsible for the data losses in the
volatile memory. It is assumed that a system crash does not have any effect on the data stored in
the non-volatile storage and this is known as the fail-stop assumption.

Data-transfer Failure:

When a disk failure occurs amid data-transfer operation resulting in loss of content from disk
storage then such failures are categorized as data-transfer failures. Some other reason for disk
failures includes disk head crash, disk unreachability, formation of bad sectors, read-write errors
on the disk, etc.
In order to quickly recover from a disk failure caused amid a data-transfer operation, the backup
copy of the data stored on other tapes or disks can be used. Thus it’s a good practice to backup
your data frequently.

Database Security
Security of databases refers to the array of controls, tools, and procedures designed to ensure and
safeguard confidentiality, integrity, and accessibility. This tutorial will concentrate on confidentiality
because it's a component that is most at risk in data security breaches.

Security for databases must cover and safeguard the following aspects:

o The database containing data.

o Database management systems (DBMS)
o Any applications that are associated with it.
o Physical database servers or the database server virtual, and the hardware that runs it.

4
 o The infrastructure for computing or network that is used to connect to the database.

Security of databases is a complicated and challenging task that requires all aspects of security practices
and technologies. This is inherently at odds with the accessibility of databases. The more usable and
accessible the database is, the more susceptible we are to threats from security. The more vulnerable it is
to attacks and threats, the more difficult it is to access and utilize.

Why Database Security is Important?

According to the definition, a data breach refers to a breach of data integrity in databases. The amount of
damage an incident like a data breach can cause our business is contingent on various consequences or
elements

o Intellectual property that is compromised: Our intellectual property--trade secrets, inventions,

or proprietary methods -- could be vital for our ability to maintain an advantage in our industry.
If our intellectual property has been stolen or disclosed and our competitive advantage is lost, it
could be difficult to keep or recover.
o The damage to our brand's reputation: Customers or partners may not want to purchase goods
or services from us (or deal with our business) If they do not feel they can trust our company to
protect their data or their own.
o The concept of business continuity (or lack of it): Some businesses cannot continue to
function until a breach has been resolved.
o Penalties or fines to be paid for not complying: The cost of not complying with international
regulations like the Sarbanes-Oxley Act (SAO) or Payment Card Industry Data Security Standard
(PCI DSS) specific to industry regulations on data privacy, like HIPAA or regional privacy laws
like the European Union's General Data Protection Regulation (GDPR) could be a major
problem with fines in worst cases in excess of many million dollars for each violation.
o Costs for repairing breaches and notifying consumers about them: Alongside notifying
customers of a breach, the company that has been breached is required to cover the investigation
and forensic services such as crisis management, triage repairs to the affected systems, and much
more.

Common Threats and Challenges

Numerous software configurations that are not correct, weaknesses, or patterns of carelessness or abuse
can lead to a breach of security. Here are some of the most prevalent kinds of reasons for security
attacks and the reasons.

Insider Dangers
An insider threat can be an attack on security from any three sources having an access privilege to the
database.

o A malicious insider who wants to cause harm

5
 o An insider who is negligent and makes mistakes that expose the database to attack. vulnerable to
attacks
o An infiltrator is an outsider who acquires credentials by using a method like phishing or
accessing the database of credential information in the database itself.

Insider dangers are among the most frequent sources of security breaches to databases. They often occur
as a consequence of the inability of employees to have access to privileged user credentials.

Human Error
The unintentional mistakes, weak passwords or sharing passwords, and other negligent or uninformed
behaviours of users remain the root causes of almost half (49 percent) of all data security breaches.

Database Software Vulnerabilities can be Exploited

Hackers earn their money by identifying and exploiting vulnerabilities in software such as databases
management software. The major database software companies and open-source databases management
platforms release regular security patches to fix these weaknesses. However, failing to implement the
patches on time could increase the risk of being hacked.

SQL/NoSQL Injection Attacks

A specific threat to databases is the infusing of untrue SQL as well as other non-SQL string attacks in
queries for databases delivered by web-based apps and HTTP headers. Companies that do not follow the
safe coding practices for web applications and conduct regular vulnerability tests are susceptible to
attacks using these.

Buffer Overflow is a way to Exploit Buffers

Buffer overflow happens when a program seeks to copy more data into the memory block with a certain
length than it can accommodate. The attackers may make use of the extra data, which is stored in
adjacent memory addresses, to establish a basis for they can begin attacks.

DDoS (DoS/DDoS) Attacks

In a denial-of-service (DoS) attack in which the attacker overwhelms the targeted server -- in this case,
the database server with such a large volume of requests that the server is unable to meet no longer
legitimate requests made by actual users. In most cases, the server is unstable or even fails to function.

Malware
Malware is software designed to exploit vulnerabilities or cause harm to databases. Malware can be
accessed via any device that connects to the databases network.

Attacks on Backups
Companies that do not protect backup data using the same rigorous controls employed to protect
databases themselves are at risk of cyberattacks on backups.

The following factors amplify the threats:

6
 o Data volumes are growing: Data capture, storage, and processing continue to increase
exponentially in almost all organizations. Any tools or methods must be highly flexible to meet
current as well as far-off needs.
o The infrastructure is sprawling: Network environments are becoming more complicated,
especially as companies shift their workloads into multiple clouds and hybrid cloud architectures
and make the selection of deployment, management, and administration of security solutions
more difficult.
o More stringent requirements for regulatory compliance: The worldwide regulatory
compliance landscape continues to increase by complexity. This makes the compliance of every
mandate more challenging.

Best use of Database Security

As databases are almost always accessible via the network, any security risk to any component or part of
the infrastructure can threaten the database. Likewise, any security attack that impacts a device or
workstation could endanger the database. Therefore, security for databases must go beyond the limits of
the database.

In evaluating the security of databases in our workplace to determine our organization's top priorities,
look at each of these areas.

Discretionary Access Control Based on Granting and Revoking

Privileges

The typical method of enforcing discretionary access control in a database system is

based on the granting and revoking of privileges. Let us consider privileges in the
context of a relational DBMS. In particular, we will discuss a system of privileges
somewhat similar to the one originally developed for the SQL language (see Chapters 4
and 5). Many current relational DBMSs use some variation of this tech-nique. The main
idea is to include statements in the query language that allow the DBA and selected users
to grant and revoke privileges.
1. Types of Discretionary Privileges
In SQL2 and later versions, the concept of an authorization identifier is used to refer,
roughly speaking, to a user account (or group of user accounts). For simplicity, we will
use the words user or account interchangeably in place of authorization identifier. The
DBMS must provide selective access to each relation in the database based on specific
accounts. Operations may also be controlled; thus, having an account does not necessarily
entitle the account holder to all the functionality provided by the DBMS. Informally,
there are two levels for assigning privileges to use the database system:
The account level. At this level, the DBA specifies the particular privileges that each
account holds independently of the relations in the database.

7
The relation (or table) level. At this level, the DBA can control the privilege to access
each individual relation or view in the database.
References privilege on R. This gives the account the capability to reference (or refer
to) a relation R when specifying integrity constraints. This privilege can also be restricted
to specific attributes of R.

Notice that to create a view, the account must have the SELECT privilege on all
relations involved in the view definition in order to specify the query that corresponds to
the view.
2. Specifying Privileges through the Use of Views
The mechanism of views is an important discretionary authorization mechanism in its
own right. For example, if the owner A of a relation R wants another account B to be able
to retrieve only some fields of R, then A can create a view V of R that includes only those
attributes and then grant SELECT on V to B. The same applies to limiting B to retrieving
only certain tuples of R; a view V can be created by defining the view by means of a
query that selects only those tuples from R that A wants to allow B to access. We will
illustrate this discussion with the example given in Section 24.2.5.

3. Revoking of Privileges
In some cases it is desirable to grant a privilege to a user temporarily. For example, the
owner of a relation may want to grant the SELECT privilege to a user for a specific task
and then revoke that privilege once the task is completed. Hence, a mechanism
for revoking privileges is needed. In SQL a REVOKE command is included for the
purpose of canceling privileges. We will see how the REVOKE command is used in the
example in Section 24.2.5.

4. Propagation of Privileges Using the GRANT OPTION

Whenever the owner A of a relation R grants a privilege on R to another account B, the
privilege can be given to B with or without the GRANT OPTION. If
the GRANT OPTION is given, this means that B can also grant that privilege on R to
other accounts. Suppose that B is given the GRANT OPTION by A and that B then grants
the privilege on R to a third account C, also with the GRANT OPTION. In this way,
privileges on R can propagate to other accounts without the knowledge of the owner
of R. If the owner account A now revokes the privilege granted to B, all the privileges
that B propagated based on that privilege should automatically be revoked by the system.

It is possible for a user to receive a certain privilege from two or more sources. For
example, A4 may receive a certain UPDATE R privilege from both A2 and A3. In such a
case, if A2 revokes this privilege from A4, A4 will still continue to have the privilege by
virtue of having been granted it from A3. If A3 later revokes the privilege
from A4, A4 totally loses the privilege. Hence, a DBMS that allows propagation of privi-

8
leges must keep track of how all the privileges were granted so that revoking of priv-
ileges can be done correctly and completely.

5. An Example to Illustrate Granting and Revoking of Privileges

Suppose that the DBA creates four accounts—A1, A2, A3, and A4—and wants
only A1 to be able to create base relations. To do this, the DBA must issue the
following GRANT command in SQL:

GRANT CREATETAB TO A1;

The CREATETAB (create table) privilege gives account A1 the capability to create new
database tables (base relations) and is hence an account privilege. This privilege was part
of earlier versions of SQL but is now left to each individual system imple-mentation to
define.

In SQL2 the same effect can be accomplished by having the DBA issue
a CREATE SCHEMA command, as follows:

CREATE SCHEMA EXAMPLE AUTHORIZATION A1;

User account A1 can now create tables under the schema called EXAMPLE. To con-
tinue our example, suppose that A1 creates the two base
relations EMPLOYEE and DEPARTMENT shown in Figure 24.1; A1 is then
the owner of these two relations and hence has all the relation privileges on each of them.

Next, suppose that account A1 wants to grant to account A2 the privilege to insert and
delete tuples in both of these relations. However, A1 does not want A2 to be able to
propagate these privileges to additional accounts. A1 can issue the following com-mand:

GRANT INSERT, DELETE ON EMPLOYEE, DEPARTMENT TO A2;

Notice that the owner account A1 of a relation automatically has the GRANT OPTION,
allowing it to grant privileges on the relation to other accounts.
However, account A2 cannot grant INSERT and DELETE privileges on
the EMPLOYEE and DEPARTMENT tables because A2 was not given the GRANT
OPTION in the preceding command.

9
Next, suppose that A1 wants to allow account A3 to retrieve information from either of
the two tables and also to be able to propagate the SELECT privilege to other
accounts. A1 can issue the following command:

GRANT SELECT ON EMPLOYEE, DEPARTMENT TO A3 WITH GRANT OPTION;

The clause WITH GRANT OPTION means that A3 can now propagate the privilege to
other accounts by using GRANT. For example, A3 can grant the SELECT privilege on
the EMPLOYEE relation to A4 by issuing the following command:

GRANT SELECT ON EMPLOYEE TO A4;

Notice that A4 cannot propagate the SELECT privilege to other accounts because
the GRANT OPTION was not given to A4.

Now suppose that A1 decides to revoke the SELECT privilege on

the EMPLOYEE relation from A3; A1 then can issue this command:

REVOKE SELECT ON EMPLOYEE FROM A3;

The DBMS must now revoke the SELECT privilege on EMPLOYEE from A3, and it
must also automatically revoke the SELECT privilege on EMPLOYEE from A4. This is
because A3 granted that privilege to A4, but A3 does not have the privilege any more.

Next, suppose that A1 wants to give back to A3 a limited capability to SELECT from
the EMPLOYEE relation and wants to allow A3 to be able to propagate the privilege.
The limitation is to retrieve only the Name, Bdate, and Address attributes and only for the
tuples with Dno = 5. A1 then can create the following view:

10
CREATE VIEW A3EMPLOYEE AS

SELECT Name, Bdate, Address

FROM EMPLOYEE

WHERE Dno = 5;

After the view is created, A1 can grant SELECT on the view A3EMPLOYEE to A3 as
follows:

GRANT SELECT ON A3EMPLOYEE TO A3 WITH GRANT OPTION;

Finally, suppose that A1 wants to allow A4 to update only the Salary attribute
of EMPLOYEE; A1 can then issue the following command:

GRANT UPDATE ON EMPLOYEE (Salary) TO A4;

The UPDATE and INSERT privileges can specify particular attributes that may be
updated or inserted in a relation. Other privileges (SELECT, DELETE) are not attrib-ute
specific, because this specificity can easily be controlled by creating the appro-priate
views that include only the desired attributes and granting the corresponding privileges
on the views. However, because updating views is not always possible (see Chapter 5),
the UPDATE and INSERT privileges are given the option to specify the particular
attributes of a base relation that may be updated.

11