You can
back up the database by using OS commands to make copies of the data files. The
course of action depends on whether the database is in ARCHIVELOG mode or not.
If it is, then you can keep the database open and available by putting each
tablespace into backup mode before copying its data files. Otherwise, you have
to shut down the database before copying the data files.
The Need
for Backup Mode
When a
block is being written to as part of the execution of a data manipulation
language (DML) statement, there could be several parts of the block affected.
Not all of the modifications to the block happen at the same time, so there is
the possibility of inconsistency in the block at certain times. Suppose time t2
represents the time between when different parts of the block are written to.
If, at time t2, the block is copied as part of the execution
of an OS copy command, then the block is considered fractured. Also, the OS
copy command does not necessarily copy the file header first, so it must be
frozen for the duration of the copy execution.
RMAN has
the means to deal with this problem. If a fractured block is read, it keeps
rereading it until it is consistent.
However, if
an OS command such as the Linux cp command is copying the data file, the
fractured block is not recognized as such, and the copy of the block is not
consistent. In order to remedy this, put the tablespace, or even the entire
database, into what is called backup mode. The effect of doing this is
that additional redo is generated. An image of each block, before it is
modified, is written to the redo log. Then, during recovery of blocks in that
data file, the before image of a fractured block can be used for the basis of
recovery, and the additional redo data is applied to it. In order to reduce the
overhead associated with maintaining extra redo data, Oracle recommends putting
one tablespace at a time into backup mode, while its data files are being
copied.
Identifying
Files to Manually Backup
User-managed
backups require you to know the data file names and locations on disk, so you
know what files need to be copied. Identify the data files to be backed up by
querying the V$DATAFILE view. Identify the control file location by querying
the V$CONTROLFILE view. Only one of the multiplexed control files needs to be
backed up, because they are identical.
Manually
Backing Up a NOARCHIVELOG Database
You can
make a consistent, whole database backup of a NOARCHIVELOG database by shutting
down the database and copying all of the data files to a backup directory.
Because the action of copying the files is done using OS commands (in this
case, the Linux cp command), the database must be shut down first. This puts it
in a consistent state. If your database is running in NOARCHIVELOG mode, this
is your only option. Otherwise, in ARCHIVELOG mode, you can make inconsistent
backups, which allows you to leave the database running while you take the
backup.
SQL> SHUTDOWN IMMEDIATE
$
cp $ORACLE_BASE/ORCL/datafile/*.dbf \ > /u02/backup/datafile
SQL> STARTUP
Manually
Backing Up an ARCHIVELOG Database
If the
database is in ARCHIVELOG mode, then you do not necessarily have to shut it
down before copying the files. You end up with an inconsistent backup, but the
application of redo data recovers it to a consistent state.
Starting
Backup Mode
You do have
to put each of the data files into backup mode before copying them, though. Do
this using the BEGIN BACKUP clause of the ALTER TABLESPACE and ALTER DATABASE
commands. Here is the syntax for each:
ALTER TABLESPACE <tablespace> BEGIN BACKUP;
ALTER DATABASE BEGIN
BACKUP;
The ALTER
TABLESPACE command affects only those data files that belong to that
tablespace. ALTER DATABASE affects all data files in the database.
Ending
Backup Mode
It is
important to bring the data files out of backup mode. You cannot have any data
files in backup mode at the time the database is shut down. If you attempt to
shut down the database in that state, you will receive an error. Also, because
backup mode causes additional redo to be generated, there is extra load on the
system. There is no reason to have any data files in backup mode if you are not
actively backing them up.
Repeat for every tablespace:
Put the
tablespace into backup mode:
SQL> ALTER TABLESPACE users BEGIN BACKUP
Copy the
data files for that tablespace to the backup location:
$
cp $ORACLE_HOME/oradata/orcl/users*.dbf /u02/backup/datafile
Bring the
tablespace out of backup mode:
SQL> ALTER TABLESPACE users END BACKUP;
Backing
Up the Control File
You should
back up the control file every time you make a structural change to the
database. The first command creates a binary copy of the file. You can
optionally supply the REUSE keyword, if the backup file already exists and you
want to overwrite it.
The second
command makes a plain text version of the control file, which is actually a
script that creates the control file when run. The resulting script is written
to the diagnostics trace directory, such as:
$ORACLE_BASE/diag/rdbms/orcl/orcl/trace
Back up the
control file:
ALTER DATABASE BACKUP
CONTROLFILE TO ‘/u01/backup/controlfile.bak’;
Or By
generating a script that re-creates it, in a trace file:
ALTER
DATABASE BACKUP CONTROLFILE TO TRACE;
