BST

Topic 4

3101:

DATABASE

SYSTEMS

II

Introduction
A key responsibility of the database administrator is to prepare for the possibility of
hardware, software, network, process, or system failure. If such a failure affects the
operation of a database system, one must usually recover the database and return
to normal operation as quickly as possible.

Note:
All database reads/writes are within a transaction. Transactions must comply with
the ACID rules. A data recovery subsystem guarantees Atomicity and Durability,
while concurrency control guarantees Isolation. The application programme on the
other hand ensures Consistency.

Database Recovery
Data recovery is the process of restoring data that has been lost, accidentally
deleted, corrupted or made inaccessible for any reason. The term typically refers to
the restoration of data to a desktop, laptop, server, or external storage system from
a backup. Recovery may be required due to physical damage to the storage device
or logical damage to the file system that prevents it from being mounted by the
host operating system.

Database Data Loss can be caused by hardware damage (at the storage device
level such as hard disk); file system damage (controlled by the operating system),
the database file system stores and organizes system and user files, and individual
file damage (file may be needed as data loss can occur within the file itself if the
internal structure is corrupt).

Recovery should protect the database and associated users from unnecessary
problems and avoid or reduce the possibility of having to duplicate work manually.
The recovery system ensures the database contains exactly those updates
produced by committed transactions.
1

Causes of Database Errors and Failures

Several problems can compromise the normal operation of database. The following
are the most common:
User Error
There are various possible user errors, including accidentally dropping a table. User
error can be minimised by increased training on database and application
principles.

Statement Failure
Statement failure occurs when there is a logical failure in the handling of a
statement in the application program. For example, assume all extents of a
database are allocated, and completely filled with data so that the table is
absolutely full. A valid INSERT statement cannot insert a row because there is no
space available. Therefore, if issued, the statement fails.

Process Failure
A process failure is a failure in a user, server, or background process of a database
instance such as an abnormal disconnect or process termination. When a process
failure occurs, the failed subordinate process cannot continue work, although the
other processes of the database instance can continue.

Network Failure
When the system uses networks such as local area networks and phone lines to
connect client workstations to database servers, or to connect several database
servers to form a distributed database system, network failures such as aborted
phone connections or network communication software failures can interrupt the
normal operation of a database system.

Database Instance Failure

Database instance failure occurs when a problem arises that prevents the database
instance from continuing to work. An instance failure can result from a hardware
problem, such as a power outage, or a software problem, such as an operating
2

system crash. Instance failure also results when the user issues a SHUTDOWN
ABORT or STARTUP FORCE statement is issued.

Media (Disk) Failure

An error can arise when trying to write or read a file that is required to operate a
database. This occurrence is called media failure because there is a physical
problem reading or writing to files on the storage medium. A common example of
media failure is a disk head crash, which causes the loss of all files on a disk drive.

Structures Used for Database Recovery

Database Backups
A database backup consists of backups of the physical files (all datafiles and a
control file) that constitute the database. To begin media recovery after a media
failure, a database uses file backups to restore damaged datafiles or control files.
Replacing a current, possibly damaged, copy of a datafile, tablespace, or database
with a backup copy is called restoring that portion of the database.
There are several options in performing database backups, including:

(ii)
(iii)
(iv)

(i) Recovery Manager

Operating system utilities
Export utility
Enterprise Backup Utility

The Redo Log

The redo log records all changes made in the database. The redo log of a database
consists of at least two redo log files that are separate from the datafiles (which
actually store a database's data). A database's redo log can consist of two parts, the
online redo log and the archived redo log.

Rollback Segments
Rollback segments of a database store the old values of data changed by ongoing
transactions for uncommitted transactions.

Among other things, the information in a rollback segment is used during database
recovery to undo any uncommitted changes applied from the redo log to the
datafiles. Therefore, if database recovery is necessary, then the data is in a
consistent state after the rollback segments are used to remove all uncommitted
data from the datafiles.

Recovery Catalog
The Recovery Manager maintains a repository called the recovery catalog, which
contains information about backup files and archived log files. Recovery Manager
uses the recovery catalog to automate both restore operations and media recovery.
The recovery catalog contains:
(i)
(ii)
(iii)
(iv)
(v)

Information about backups of datafiles and archive logs

Information about datafile copies
Information about archived redo logs and copies of them
Information about the physical schema of the target database
Named sequences of commands called stored scripts

Recovery Manager
The Recovery Manager is a utility that manages the processes of creating backups
of all database files (datafiles, control files, and archived redo log files), and
restoring or recovering files from backups. It propagates information about backup
datafile sets, archived redo logs, backup control files, and datafile copies into the
recovery catalog for long-term retention.

When doing a restore, the Recovery Manager extracts the appropriate information
from the recovery catalog and passes it to the database server. The server performs
various integrity checks on the input files specified for a restore.

Control Files
The control file of a database is a small binary file necessary for the database to
start and operate successfully. A control file is updated continuously by DBMS
during database use, so it must be available for writing whenever the database is
open. If for some reason the control file is not accessible, the database will not
function properly. Among other things, a control file contains information such as:

(ii)
(iii)
(iv)
(v)
(vi)
(vii)
(viii)
(ix)
(x)
(xi)
(xii)

(i) The database name

The timestamp of database creation
The names and locations of associated datafiles and online redo log files
Tablespace information
Datafile offline ranges
The log history
Archived log information
Backup set and backup piece information
Backup datafile and redo log information
Datafile copy information
The current log sequence number
Checkpoint information

DATABASE SECURITY
Database security is the range of methods used to protect information stored within
a database. The term refers to the processes and procedures undertaken to prevent
unauthorised access to the database. Hacking attempts are the most common
hazard to database information, but there are many other dangers.

The most common database security vulnerabilities are:

Deployment Failures
The most common cause of database vulnerabilities is a lack of due care at the
moment they are deployed. Although any given database is tested for functionality
and to make sure it is doing what the databases is designed to do, very few checks
are made to check the database is not doing things it should not be doing.
Broken Databases
The SQL Slammer worm of 2003 was able to infect more than 90 percent of
vulnerable computers within 10 minutes of deployment, taking down thousands of
databases in minutes. This worm took advantage of a bug that was discovered in
Microsoft's SQL Server database software the previous year, but few system
administrators installed a fix, leaving computers vulnerable.
Data Leaks
5

Databases may be considered a "back end" part of the office and secure from
Internet-based threats (and so data doesn't have to be encrypted), but this is not
the case. Databases also contain a networking interface, and so hackers are able to
capture this type of traffic to exploit it. To avoid such a pitfall, administrators should
use encrypted communication platforms.
Stolen Database Backups
Organisation insiders are also likely to steal archives including database backups
whether for money, profit or revenge. This is a common problem for the modern
enterprise, and businesses should consider encrypting archives to mitigate the
insider-risk.
The Abuse of Database Features
It has been established that every database exploit has been based on the misuse
of a standard database feature. For example, a hacker can gain access through
legitimate credentials before forcing the service to run arbitrary code.
Lack of Segregation
The separation of administrator and user powers, as well as the segregation of
duties, can make it more difficult for fraud or theft undertaken by internal staff. In
addition, limiting the power of user accounts may give a hacker a harder time in
taking complete control of a database.
Security Loopholes
Cybercriminals may opt to find a weakness within the infrastructure that can be
used as leverage for more serious attacks until they reach the back-end database
system.
SQL Injections
A popular method for hackers to take, SQL injections remain a critical problem in the
protection of enterprise databases. Applications are attacked by injections, and the
database administrator is left to clean up the mess caused by unclean variables and
malicious code which is inserted into strings, later passed to an instance of SQL
server for parsing and execution. The best ways to protect against these threats are
to protect web-facing databases with firewalls and to test input variables for SQL
injection during development.
Sub-Standard Key Management
Key management systems are meant to keep keys safe, but research has found
encryption keys stored on company disk drives. Database administrators sometimes
falsely believe these keys have to be left on the disk because of database failures,
but this isn't true and placing such keys in an unprotected state can leave
systems vulnerable to attack.
Database Inconsistencies
System administrators and database developers need to develop a consistent
practice in looking after their databases, staying aware of threats and making sure
that vulnerabilities are taken care of. This isn't an easy task, but documentation and
automation to track and make changes can ensure that the information contained in
enterprise networks is kept secure.
6

Control Measures
Installing a database firewall, a protective barrier that keeps all unknown
connections at bay, is the most basic form of database security. Firewalls are
installed on most computers and are made so hackers have a difficult time
connecting to a victims computer. Firewalls work by filtering through connections in
the network and only allowing trusted computers or users to access the database.

Encryption is another database security measure in which the data are encrypted
or made illegible for anyone who accesses the database. When encryption is used,
an algorithm scrambles the characters into nonsense, so it cannot be read. This
means that, unless the hacker has specific knowledge of the encryption key, the
information one needs to change the encrypted data from illegible characters back
to a legible format, there is no way he or she can read the database.

Auditing is when a supervisor, or database manager, scans the database to ensure

nothing has changed. This type of database security can either be performed
physically, by someone reading over the database, or by using a program for larger
databases to see if the coding is the same.

Performing a database backup is a database security measure that protects

against many different threats. When the database is backed up, this means the
data are stored in another area or medium. If the database loses any or all
information, it can be promptly restarted with minimal loss using the backup. By
doing a database backup, administrators are able to guard against physical damage
to the computer such as from a fire, database corruption or the database shutting
down from being overloaded.