It’s quite interesting that very many DBAs still use other methods than RMAN to backup their databases. I don’t mean the highend solutions like splitmirror but export / import or offline backups with OS-methods. But it’s so easy to backup databases using RMAN:
- The database is running in archivelog mode. And I assume that this is true for every production database.
- There is an area or a directory for the oracle backups. In Oracle 11g Databases you probably already use the Fast Recovery Area (FRA) as the server parameter db_recovery_file_dest and db_recovery_file_dest_size are both defined. In this case the archiving can be enabled without additional parameters as well:
- This is sufficient for RMAN to backup the database as show in the following example:
sqlplus / as sysdba SQL> shutdown immediate SQL> startup mount SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN; SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 35 Next log sequence to archive 37 Current log sequence 37
rman target / Recovery Manager: Release 11.2.0.2.0 - Production on Mon Dec 5 08:37:44 2011 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: VMLIN112 (DBID=2882738724) RMAN> backup database; Starting backup at 05-DEC-11 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=59 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=/u02/oradata/VMLIN112/system01.dbf input datafile file number=00002 name=/u02/oradata/VMLIN112/sysaux01.dbf input datafile file number=00003 name=/u02/oradata/VMLIN112/undotbs01.dbf input datafile file number=00004 name=/u02/oradata/VMLIN112/users01.dbf channel ORA_DISK_1: starting piece 1 at 05-DEC-11 channel ORA_DISK_1: finished piece 1 at 05-DEC-11 piece handle=/u03/orabackup/fast_recovery_area/VMLIN112/backupset/2011_12_05/o1_mf_nnndf_TAG20111205T083803_7frx6vfb_.bkp tag=TAG20111205T083803 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 05-DEC-11 channel ORA_DISK_1: finished piece 1 at 05-DEC-11 piece handle=/u03/orabackup/fast_recovery_area/VMLIN112/backupset/2011_12_05/o1_mf_ncsnf_TAG20111205T083803_7frx7olq_.bkp tag=TAG20111205T083803 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 05-DEC-11
As first task all database files are backed up (except the TEMP-Tablespace). As this is the first backup the controlfile and spfile are backed up into a separate backup piece. Since Oracle 11g a backup of the controlfile and spfile are made whenever there is a structural change to the database e.g. adding a tablespace or datafile. In the FRA a new directory structure is created automatically (in the example it’s backupset/2011_12_15). The files do have a system generated name and tag to identify individual backups. This area will be maintained by the RMAN and archiver process. So as soon as the FRA reaches his maximum size (defined with db_recovery_file_dest) redundant files and directories are removed. From my perspective this method is sufficient for smaller databases with some minor changes:
As the controlfile backup does not uses that much space but the controlfile backup is essential for a full restore of the database I would recommend to add a controlfile backup to every database backup. The configuration parameter “controlfile autobackup on” enables this feature.:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
This command changes the behavior of every backup because it’s stored as a parameter in the controlfile. You can see the actual values for several parameter with the command “show all“. Several DBA’s still use run-scripts with the complete configuration as those were common in earlier versions of RMAN. With Oracle 10g and 11g it’s no longer necessary to use those scripts in most cases instead it can be a bit tricky for restore and recovery as you need similar scripts. Storing the configuration in the controlfiles allows to use very simple commands to restore or recovery the database or parts of it – and I guess that’s more important than high sophisticated backup scripts.
You can use on simple command to backup the database including the archivelogs but I would recommend two different commands like this:
RMAN> backup database; RMAN> backup archivelog all not backed up 2 times;
First the database is backed up and next all archivelogs are backed up as long as they are not backed up more than twice. This prevents archived redologs to be backed up too often but on the other hand they are available in the FRA as long as possible. Is already said RMAN and the archiver are maintaining the FRA in case the db_recovery_file_dest_size is reached. You hopefully see how easy it is to use RMAN and that there is no reason why not to use it. Some more advantages of using RMAN are:
- RMAN does not simply copy the entire database but back up only blocks which are used or were in use earlier. So in most cases the size of the backup files is less than the size of the database.
- RMAN automatically verifies blocks so corruptions can be idenfied easier.
- Some basic information as well as statistics are available in several v$-views and can be viewed using enterprise manager or a nice little tool from Quest Software named Backup Reporter.
RMAN can also be used to make offline backups. But in this case the instance has to be mounted because RMAN needs to read the controlfile and has access to the database files. But in this case it’s not necessary to switch the database into archivelog mode which might be a good solution for development and test databases as well as for some data warehouses. So give it a trial and tell me your experience – or simply chat with me if you need more information.