There are several tools included within Oracle to
achieve all backup methodologies. These tools include:
-
User-created scripts
-
exp
and expdp
-
RMAN
Additionally, it is possible to implement
user-created scripts to perform a backup.
Using Scripts for
Backup
A cold backup can be taken on a RAC database
whether it is in ARCHIVELOG mode or not.
Cold backups require that the entire database environment be
shut down; this includes access by all instances in the cluster.
Once the database is completely shut down on all
nodes, a script can be used to copy all datafiles, redo logs, control
files, the SPFILE, and archive logs to a remote location.
Careful documentation should exist recording where these files
must be placed in order to restore the database in the event of a
failure.
Information about current file placement can be
found with the following queries:
select file_name from
dba_data_files;
select name from v$controlfile;
select member from v$logfile;
select value from v$parameter where name = 'spfile';
All files returned by these scripts must be backed up in order for a
cold backup to be complete consistent.
In the case of a hot backup or a cold backup from which the database
will be fully recovered, archive logs must also be backed up.
In order to become fully consistent, all archive logs during
which a hot backup took place and all archive logs up to the point of
recovery must be identified.
The
v$archived_log
view shows archive logs for all instances.
TIP:
Even though
gv$ views are usually used to display RAC information instead of
traditional v$ views, in the case of redo and archive logs the
information regarding all nodes is stored on each node.
Instead of specifically using
inst_id as most gv$
views do, the thread# keeps track of the instance to which each
redo or archive log belongs.
The biggest drawback to using script driven backups is management.
When using RMAN (Recovery Manager), Oracle's internal
dictionary will keep track of backups within the control file or an
external catalog. When
using user-made scripts, there is no record of backups taken or
locations within Oracle.
All backup information must be documented very carefully.
Cold backups present another major drawback. The database must be down
while the backup takes place.
Again, in a RAC environment this defeats the purpose of high
availability.
Hot backups, while better on uptime, do cause issues when run from
user-created scripts. In
order to prevent block fracturing, the DBA must place each datafile in
hot backup mode. This is
done either at the database level or the datafile level:
alter datafile '/path/to/datafile.dbf' begin
backup;
alter database begin backup;
Once the backup is complete, the files can be taken out of hot backup
mode:
alter datafile '/path/to/datafile.dbf' end backup;
alter database end backup;
When a datafile is in hot backup mode via these commands, Oracle must
record the entire contents of a data block to redo the first time that
block is modified since going into hot backup mode.
For instance, if file #5 is placed in hot backup mode and someone
writes data to block #50 via DDL or DML, the entire contents of the
data block will be written to redo logs.
After the initial change to block #50, writes to the block will
only require the deltas be recorded to redo.
If the database block size is the default of 8k, this will
result in a large amount of data being written to redo if the database
is in use during the hot backup.
While it may be tempting to try taking a backup without placing the
datafiles into hot backup mode, it is obviously not recommended.
The backup will likely not be usable and will not be supported
by Oracle. Even if third
party snapshot tools are used, it is necessary to place the datafiles
into hot backup mode before taking the snapshot.
Once the snapshot is complete, the files can be taken out of
hot backup mode.
If manual scripts are going to be used, it is a good idea to generate
these scripts using the views mentioned in this section to
automatically create the backup script required.
This ensures that when database changes are made, such as the
addition of a datafile, the changes will be present during the next
backup.
