Backup and Recovery Concepts

Copyright © 2009, Oracle. All rights reserved.

 Objectives

After completing this lesson, you should be able to:

• Identify the types of failure that can occur in an Oracle
database
• Describe ways to tune instance recovery
• Identify the importance of checkpoints, redo log files, and
archive log files
• Configure the fast recovery area
• Configure ARCHIVELOG mode
 Categories of Failure

Failures can generally be divided into the following categories:

• Statement failure
• User process failure
• Network failure
• User error
• Instance failure
• Media failure
 Statement Failure

Typical Problems Possible Solutions

Attempts to enter invalid data into a Work with users to validate and
table correct data.
Attempts to perform operations with Provide appropriate object or system
insufficient privileges privileges.

Attempts to allocate space that fail • Enable resumable space

allocation.
• Increase owner quota.
• Add space to tablespace.

Logic errors in applications Work with developers to correct

program errors.
 User Process Failure

Typical Problems Possible Solutions

A user performs an abnormal A DBA’s action is not usually needed
disconnect. to resolve user process failures.
Instance background processes roll
A user’s session is abnormally back uncommitted changes and
terminated. release locks.

A user experiences a program error

that terminates the session. Watch for trends.
 Network Failure

Typical Problems Possible Solutions

Listener fails. Configure a backup listener and
connect-time failover.
Network Interface Card (NIC) fails. Configure multiple network cards.

Network connection fails. Configure a backup network

connection.
 User Error

Typical Causes Possible Solutions

User inadvertently deletes or Roll back transaction and dependent
modifies data. transactions or rewind table.
User drops a table. Recover table from recycle bin.

Oracle LogMiner
 Flashback Technology

Using Flashback technology:

• Viewing past states of data
• Winding data back and forth in time
• Assisting users in error analysis and recovery

For error analysis: For error recovery:

Oracle Flashback Query Oracle Flashback Transaction Backout
Oracle Flashback Versions Query Oracle Flashback Table
Oracle Flashback Transaction Query Oracle Flashback Drop
Oracle Flashback Database
 Instance Failure

Typical Causes Possible Solutions

Power outage Restart the instance by using the
STARTUP command. Recovering
from instance failure is automatic,
Hardware failure including rolling forward changes in
the redo logs and then rolling back
any uncommitted transactions.
Failure of one of the critical
background processes Investigate the causes of failure by
using the alert log, trace files, and
Emergency shutdown procedures Enterprise Manager.
 Understanding Instance Recovery:
Checkpoint (CKPT) Process
CKPT is responsible for:
SGA
• Updating data file headers with
checkpoint information
Database
• Updating control files with buffer cache
checkpoint information
• Signaling DBWn at
full checkpoints DBWn
Database Writer
process

Control
files
CKPT

Checkpoint process Data files

 Understanding Instance Recovery:
Redo Log Files and Log Writer

Redo log files:

SGA
• Record changes to the
database
Redo log buffer
• Should be multiplexed to
protect against loss
LGWR Log Writer writes:
Log Writer • At commit
• When one-third full
• Every three seconds
Redo log
group 1
Redo log
group 2
Redo log
group 3
• Before DBWn writes
• Before clean shutdowns
 Understanding Instance Recovery

Automatic instance or crash recovery:

• Is caused by attempts to open a database whose files are
not synchronized on shutdown
• Uses information stored in redo log groups to synchronize
files
• Involves two distinct operations:
– Rolling forward: Redo log changes (both committed and
uncommited) are applied to data files.
– Rolling back: Changes that are made but not committed are
returned to their original state.
 Phases of Instance Recovery

Instance
1. Startup instance (data files
are out of sync) SGA
2. Roll forward (redo)
3. Committed and uncommitted Background
processes
data in files
4. Database opened
Database
5. Roll back (undo)
6. Committed data in files SCN:
SCN:140 SCN:143 74-101

SCN:
SCN:129 SCN:143 102-143
Undo
SCN: 99
Control Redo log
Data files files group
 Media Failure

Typical Causes Possible Solutions

Failure of disk drive 1. Restore the affected file from
backup.
2. Inform the database about a new
Failure of disk controller file location (if necessary).
3. Recover the file by applying redo
information (if necessary).
Deletion or corruption of a file
needed for database operation
 Configuring for Recoverability

To configure your database for maximum recoverability, you

must:
• Schedule regular backups
• Multiplex control files
• Multiplex redo log groups
• Retain archived copies of redo logs
 Configuring the Fast Recovery Area

• Fast recovery area:

– Strongly recommended for simplified backup storage
management
– Storage space (separate from working database files)
– Location specified by the DB_RECOVERY_FILE_DEST
parameter
– Size specified by the DB_RECOVERY_FILE_DEST_SIZE
parameter
– Large enough for backups, archived logs, flashback logs,
multiplexed control files, and multiplexed redo logs
– Automatically managed according to your backup retention
and archived redo log file deletion policies
• Determine location, size, backup retention, and archived
redo log deletion policies to configure.
 Multiplexing Control Files

To protect against database failure, your database should have

multiple copies of the control file.

ASM Storage File System Storage

Best One copy on each disk group At least two copies, each on separate disk
Practice (such as +DATA and +FRA) (at least one on separate disk controller)

Steps to No additional control file 1. Alter the SPFILE with the ALTER
create copies required. SYSTEM SET control_files
additional command.
control 2. Shut down the database.
files 3. Copy control file to a new location.
4. Open the database and verify the
addition of the new control file.
 Redo Log Files

Multiplex redo log groups to protect against media failure and

loss of data. This increases database I/O. It is suggested that
redo log groups have:
• At least two members (files) per group
• Each member:
– On a separate disk or
+DATA Member Member Member
controller if using a a a
file system storage
– In a separate disk group +FRA Member Member Member
(such as +DATA and +FRA) b b b
Group 1 Group 2 Group 3
if using ASM

Note: Multiplexing redo logs may impact overall database performance.

 Multiplexing the Redo Log

If Storage Type is File

System, then you are
prompted to enter a
File Name and File
Directory.
 Archive Log Files

To preserve redo information, create archived copies of redo

log files by performing the following steps.
1. Specify archive log file-naming convention.
2. Specify one or more archive log file locations.
3. Switch the database to ARCHIVELOG mode.

Online redo log files Archive log files

 Archiver (ARCn) Process

Archiver (ARCn):
• Is an optional background SGA
process
• Automatically archives online
Redo log buffer
redo log files when
ARCHIVELOG mode is set for
the database LGWR
• Preserves the record of all Log Writer

changes made to the

Copies of
database Redo log Redo log
files files

ARCn
Archiver process
 Archive Log File: Naming and Destinations

Specify naming and archive destination information on the

Recovery Settings page. If using file system storage then it is
recommended that you add multiple locations across different
disks.
 Enabling ARCHIVELOG Mode

To place the database in ARCHIVELOG mode, perform the

following steps in Enterprise Manager:
1. Select the ARCHIVELOG Mode check box and click Apply.
The database can be set to ARCHIVELOG mode only from
the MOUNT state.
2. Restart the database (with SYSDBA privileges).
3. (Optional) View the archive status.
4. Back up your database.
Note: Databases in ARCHIVELOG
sqlplus / as sysdba
mode have access to the full
range of backup and recovery shutdown immediate
startup mount
options. alter database archivelog;
alter database open;
archive log list