Backup and Recovery

Backup is a copy of original data which protects the data from data loss and recovering data after a
data loss. Backup refer to physical backup of database files, control files and archived redo log files.

Recovery is to recover the database back to the state they were before any failure/Error situation.

DBA has to set the below goals:

1. Protect the database from failures

2. Increase the mean time between failures
3. Decrease the mean time to recover
4. Minimize the loss of data when there is a database failure

Database can fail either entirely or partially because of various reasons. Oracle can recover some of
the failures automatically and some of the critical failures you need to go in and “recover” the database
using your backups.

Types of database failures:

1. Statement failure

Statement failure is when a program attempts to enter invalid data into an oracle table. The
statement will fail because of the checks built into the data insertion. We can validate the
statements and correct it.

2. User Process Failure

User process may be terminated abruptly losing the session connection, performing and
abnormal disconnect

3. Network Failure

Network failure can occur due to oracle Net Listener, The network interface card(NIC) or
network connection has failed.
4. Instance Failure

Instance failure can occur due to hardware failure, power failure or an emergency shutdown
procedure.it may also happen when the key oracle background process such as pmon shuts
down because of an error condition.

Crash Recovery :- Instance recovery of a single database instance

Instance Recovery :- Instance recovery of one or more instances of a RAC database.

1
 Steps that can be checked after instance failure:
 Check the alert log and trace files to get the cause of instance failure.
 You can restart the database instance by using the oracle command startup from
SQL*plus command line
 Oracle will perform automatic instance or crash recovery and performs the rollback
of uncommitted transactions by using the data from undo segments and will roll
forward the committed changes from online redo log files
 Once the uncommitted changes are backed out and committed changes are rolled
forward,the datafiles are in sync again and will contain only the committed data.
 At this stage the database is considered to be in consistent state.

5. User Error

User error means accidentally dropping a table, users can also wrongly modify or delete data
from a table.we can use flashback table feature to restore a table to previous point in time.

6. Media Failure

Media failure occurs when we lose a disk or a disk controller fails, delaying access to your
database.A head crash, file corruption and the overwriting or deletion of a data file is the
examples of a media failure.

Backup and recovery Instance Architecture:

The oracle instance consist of the system global area(SGA),which is the memory allocated to the oracle
instance, and a set of mandatory background processes.Oracle process starts when you start the
instance.

Each background process is in charge of specific activity such as writing changed data into data
files,cleaning up after disconnected user sessions and so on.

Let us review the key oracle background processes that perform critical backup and recovery-related
tasks.

 The checkpoint process

Updates the latest SCN to control file and datafile headers by taking the information from redolog
files.This will happen at every checkpoint event

 The Log Writer process (LGWR)

2
 It is responsible for writing redo entries from log buffer cache to redolog files.It will perform
this in following situations.

1.Before DBWRn writes

2.Whenever commit occurs
3. When log buffer cache is 1/3rd full
4. When 1MB of redo is generated
5.Every 3 Seconds

Note: Log writer process writes before the database writer does,because of the write-ahead
protocol.Data changes aren’t necessarily written to datafiles when you commit a
transaction,but they are always written to the redo log.
 The Archiver process

It will generate archives which are backup of redolog files in the specified location. This will be done
only if database is in archive log mode.

Archive log and NoArchivelog mode of operation:

ARCHIVELOG mode is a mode that you can put the database in for creating a backup of all
transactions that have occurred in the database so that you can recover to any point in time. The
process of turning redo log files into archived redo log files is called archiving. This process is only
possible if the database is running in ARCHIVELOG mode.

NOARCHIVELOG mode is basically the absence of ARCHIVELOG mode and has the
disadvantage of not being able to recover to any point in time.

Steps to enable Archive log mode in database:

 Open a putty terminal and set the environmental variables

 Log in to SQL*Plus as SYSDBA:
o $ sqlplus / as sysdba
 Shut down the database:
o SQL> shutdown immediate
 Start the database in mount mode:
o SQL> startup mount
 Issue the command to enable archive mode:
o SQL > alter database archive log;
 Then issue the command
o SQL> alter database open;

3
 Now your database is in archive log mode, and archive log files should show up in your Fast
Recovery Area.

Steps to disable Archive log mode in database:

 Open a putty terminal and set the environmental variables

 Log in to SQL*Plus as SYSDBA
o $ sqlplus / as sysdba
 Shut down the database:
o SQL> shutdown immediate;
 Start the database in mount mode:
o SQL> startup mount;
 Issue the command to disable archive mode:
o SQL > alter database noarchivelog;
 Then open the database
o SQL> :alter database open;

To view the changes we can use below command in SQL Plus

Archive Log No Archive log

It can recover database from both instances It cannot perform a media recovery
and media failures
Can take backup without shutting down the can take database backup only after shutting
database down the database