Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
A DBA can be forgiven almost anything except a failed recovery. If you are unable to restore
and recover a production database well lets not even go there!
This post will highlight some of the areas you need to configure to setup an effective backup
strategy using RMAN.
What needs to be backed up?
Datafiles
Controlfiles
Archivelogs
Parameter files
Network configuration Files
Wallets
Password files
Oracle Home
The first four items on this list can be backed up using RMAN, the remaining items will require
an alternative backup method such as an OS Copy or Netbackup Snapshot
Where should the backups be stored?
If you plan to use a Flash Recovery Area(FRA) or to backup to disk, ensure that the FRA is not
created on the same disks as the database. Otherwise, the disk becomes a single point of failure.
It is best practice to copy your backups off the server and preferably store a copy off site.
If your backups are going straight to tape, it is good practice to keep your archivelogs available
on disk for as long as possible as this will help reduce recovery time.
To set up the FRA:
alter system set db_recovery_file_dest=path to a separate disk
alter system set db_recovery_file_dest_size= (Ideally you would create this area big enough to
save all backups copies, as a minimum it should be large enough to hold the backups and archive
log files that are not copied to tapes yet)
How long should I keep the backup?
This will depend on the SLA agreements you have in place. If for instance you have committed
to providing Point in Time recovery to any time during the last month, you would need to keep
all archivelog backups for one month, plus the Level 0 backup taken at the start of the period, it
would also be wise to keep the subsequent Level 0s and Level 1s to reduce recovery time.
If on the other hand you only agree to restore to the start of the previous business day, then you
only need to keep the backups for two days.
A recommended backup strategy for an OLTP environment?
This strategy would be used to recover a database to any point in time during the last four weeks.
The data in the database is dynamic and changes frequently, there are no static tables.
An RMAN catalog is used and the backups are written to the FRA on disk.
Configuring RMAN
export ORACLE_SID=PROD1
[oracle@dbserver ~]$ rman
RMAN> connect target /
RMAN> connect catalog rman_owner/***@RMAN
Ensure that RMAN retains all backups needed to recover the database to any point in time in the
last 32 days:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 32 DAYS;
Backup optimization skips the backup of files in certain circumstances if the identical file or an
identical version of the file has already been backed up. For example if a particular backup fails
and is resubmitted.
A datafile backup needs to have the same dbid, checkpoint, and resetlogs data in order to be
ignored during the next backup.
For archive logs, the same file means the same dbid, thread, sequence, and resetlogs data.
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
As backup information is stored in the controlfile, as well as datafile info etc, it is recommened
that RMAN automatically backs up the control file and the current server parameter file (if used
to start up the database) whenever a successful backup completes.
This will enable you to recover even if you lose the current controlfile.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Set the location of the controlfile autobackup to a separate location to your database files and
controlfile.
The sting you enter must contain the substitution variable %F (and no other substitution
variables)
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE
DISK TO /data/PROD1/%F';
Depending on the number of IO devices available on the server, set up the number of channels
that will be used by default for all backups and restores.
This saves on creating channels at the beginning of every script.
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO
BACKUPSET;
When RMAN needs to resynchronize the recovery catalog with a read-consistent version of the
control file, it creates a temporary snapshot control file.
The default location for the snapshot control file is platform-specific and depends on the Oracle
This script will require an agent for media library is installed & Media management layer(MML)
is configured correctly.
An example of MML is Netbackup and the agent will warrant a license.
RUN
{
ALLOCATE CHANNEL ch00 TYPE SBT_TAPE;
ALLOCATE CHANNEL ch01 TYPE SBT_TAPE;
BACKUP RECOVERY AREA DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
}
As of 11g you can also backup the FRA via a NFS attached file system. We would use the
BACKUP RECOVERY AREA TO DESTINATION clause to accomplish this.
It could be useful to move the backup to cheaper storage, but mostly, it is much faster to restore
from disk, and it is not wise to leave the backups on the same server as the database.
Considerations for Data Warehouse
The strategy listed above would also work for DSS environments, but you might want to
consider moving data in historic tablespaces into READ ONLY mode to avoid backing them up.
As the backups will become obsolete after 31 days, you could move the READ ONLY
tablespaces into READ WRITE shortly before you perform your monthly backup.
The alternative is to do a separate backup of the historic data, vault it so that it never expires and
then move the tablespaces into READ ONLY mode permanently.
Backup using Image Copy Example
Alternative backup strategy using incremental image copies. This strategy needs the same
amount of storage as the database uses as it makes a physical copy of the database.
RUN
{
RECOVER COPY OF DATABASE
WITH TAG incr_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG incr_update
DATABASE;
}
The first time this script run it will create an image copy of the database, it will not recover any
incrementals or apply them as none exist.
The next time it runs it will create and incremental copy of the changed blocks and again will not
recover or apply the changes to the image copy.
The third time it runs it will apply the previous days incremental to the image copy and take
another incremental.
This strategy provides very fast recovery as you can use the RMAN SWITCH TO COPY
command to switch to the copy, then apply only the archives you want to get you back to where
you want to be.
The example only allows a 24 hour recovery window, this can be increased by adding the UNTIL
TIME SYSDATE x as in the following example.
RUN
{
RECOVER COPY OF DATABASE
WITH TAG incr_update
UNTIL TIME SYSDATE 31;
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG incr_update
DATABASE;
}