Oracle RMAN 11g Backup and Recovery (90 page)

254
Part II: Setup Principles and Practices

channel ORA DISK 2: starting datafile copy

input datafile fno 00003

name C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSAUX01.DBF

output Filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ROB10R2

\DATAFILE\O1_MF_SYSAUX_1QFBPPON_.DBF tag=TAG20051112T205403 recid=

2stamp=574203351

channel ORA DISK 2: datafile copy complete, elapsed time: 00:01:55

channel ORA DISK 2: starting datafile copy

Image copies of tablespaces work pretty much the same way; just use the
backup as copy
command and the
tablespace
keyword:

backup as copy tablespace users;

Finally, you can create image copies of datafiles:

backup as copy datafile 1;

backup as copy datafile

'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2\SYSTEM01.DBF';

NOTE

An image copy can be made with the database mounted or, if the

database is in ARCHIVELOG mode, with the database open.

Control File Copies

Control file copies can also be made with the
backup controlfile
command. These backups can occur with the database either mounted or open. Generally, it is a best practice to enable control file autobackups and allow RMAN to back up the control file automatically after a backup.

If you need to manually create an RMAN backup set that contains a control file, here is an example of such a backup:

backup current controlfile;

Note that this is not the same as a control file autobackup, and an attempt to restore from a control file autobackup will not result in the recovery of a control file backed up using this method.

You can also create control file copies. These copies are just like backup control files created with the
alter database backup controlfile to trace
command; thus, they are usable for recovery purposes. Here is an example of the creation of a control file copy from RMAN: backup as copy current controlfile

format 'c:\controlback\control01.ctl' reuse;

Note that the
backup as copy
command will not overwrite an existing backup control file unless you use the
reuse
keyword as we did in our example. Also note that the
backup as copy
command does not create an RMAN backup set, only a physical file that is a backup control file.

If you wish to create a control file for use with a standby database that you are creating, then you use the
for standby
clause. Again this will create an RMAN backup set: backup as copy standby controlfile;

As you did with regular backup control files, you can indicate a specific filename/location when you create a control file backup, which would result in the physical file being created in that location and not in the creation of an RMAN backup set:

Chapter 11: RMAN Backups
255

backup as copy current controlfile format 'c:\oracle\controlfilecopy.ctl';
ARCHIVELOG Image Copies

Having copies of archived redo logs can be helpful. It’s certainly easier to mine a copy of an archived redo log with Oracle’s LogMiner product than to have to first extract that archived redo log from a backup set. The
copy
command allows you to create copies of archived redo logs by using the
archivelog
parameter of the
copy
command. Unfortunately, as we mentioned earlier, the use of
copy archivelog
requires us to list each archived redo log by name, rather than to specify some temporal range when we make copies of the archived redo logs. Here is an example of making an ARCHIVELOG file copy:

backup as copy archivelog all;

Incremental RMAN Backups

We hope you have made it this far through the book without much difficulty and have been able to get at least one good backup of your database done. Now, we are going to move on to incremental backups in RMAN. Through incremental backups, RMAN allows you to back up just the data blocks that have changed since the last incremental backup. The following are the benefits of incremental backups:

■ Less overall tape or disk usage

■ Less network bandwidth required

■ Quicker backup times

You can do incremental backups either online or offline and in either ARCHIVELOG mode or NOARCHIVELOG mode, which is pretty handy. Keep in mind that if you choose an incremental backup strategy, a give and take exists in terms of the benefits. While you are deriving a benefit in the reduction of overall backup times (and this may be significant), the cost comes on the recovery side. Because Oracle will need to use several backup sets to recover the database if an incremental strategy is used, the time required to recover your database can significantly increase.

NOTE

If you choose to do incremental backups on a NOARCHIVELOG

mode database, make sure you shut down the database in a consistent

manner each time you back up the database.

The Block Change Tracking File

By default, when doing an incremental backup, any datafile that has changed in any way will be backed up. This can make incremental backups take longer and will make them larger. RMAN

offers the ability to just back up changed database blocks. This can make your incremental database backups much smaller and shorter. To enable block change tracking, issue the command
alter database enable block change tracking
. The result of this command will be the creation of a file called the block change tracking file (BCTF).

When enabling block change tracking, you can choose to allow Oracle to name the related block change tracking file for you. Oracle will use the Oracle Managed Files (OMF) naming

256
Part II: Setup Principles and Practices

standard when naming the BCTF. You can also choose to define the location and name of the block change tracking file yourself, as shown in this example:

alter database enable block change tracking using file

'/u01/app/oracle/block change/rob10gr2 block change.fil';

If a previous block change tracking file already exists, you need to use the
reuse
parameter: alter database enable block change tracking using file

'/u01/app/oracle/block change/rob10gr2 block change.fil' reuse;

You disable block change tracking by using the
alter database disable block change tracking
command. The block change tracking file size is pre-allocated and is related to the size of the database and the number of redo log threads. The typical size of the block change tracking file is quite small and is proportional to the size of the database. Its size is roughly 1/250,000 the size of the database.

If you are running an Oracle Real Application Clusters (RAC) database configuration, each node will need to have access to the BCTF. In these configurations, you may want to consider storing the BCTF in ASM for ease of file sharing.

The BCTF size also depends on the number of incremental backups that occur between each level 0 backup. The more incremental backups, the more changed block-related metadata has to be stored in the BCTF.

The BCTF can hold a maximum of eight backups’ worth of information (for example, one base and seven level-1 incremental backups). After this, the next backup will remove the information of a previous backup, making the BCTF useless. The BCTF file will grow automatically in 10MB