Incrementally Updating Transportable Tablespaces using RMAN by Saravanan Shanmugam, Senior Architect, The Hartford

This paper discusses how RMAN can be used to update a transported tablespace with an incremental backup. Saravanan Shanmugam is an

Oracle Certified Master and was the lead DBA and primary database architect for the work on which this paper is based.

Before detailing the incrementally updated transportable tablespace procedure, standard transportable tablespaces will first be discussed. Complete details of the transportable tablespace procedure are documented in the Oracle Database Administrator’s Guide.

Overview of Transportable Tablespace Procedure The transportable tablespace procedure was introduced in Oracle8i to quickly move data from one database to another. Transportable tablespace is faster than other Oracle data copying methods (e.g. import/export) since the underlying datafiles are just copied to the destination database location and “plugged in” to the destination database using an export dump file of the tablespace metadata.

The steps in transporting a tablespace are as follows:

1. Place tablespace in read-only mode to get a consistent copy of data in the source database.

2. Generate metadata information about the contents of the tablespaces using export (or Data Pump in Oracle Database 10g).

3. Use any desired method to copy the datafiles to the destination database location.

4. If the destination database already contains a tablespace with the same name, then rename or drop it. Typically, for data publishing operations that occur at regular intervals, the old version of the tablespace is dropped from the destination database.

5. Plug in the copied files at the destination database by importing (or by using Data Pump to import) the metadata export dump created at the source database.

For regular publishing operations, step 3 usually consumes the most amount of time. However, with Oracle Database 10g, a combination of RMAN incremental backups and transportable tablespaces can be used to reduce the amount of time to copy the data to the destination database. The following procedure assumes an Oracle Database 10g Release 1 or higher environment.

Overview of Incrementally Updated Transportable Tablespace The incrementally updated transportable tablespace process is shown as follows:

Tablespace Tablespace copy

Target DatabaseSourceDatabase

First Time Copy

Plugged-intablespaceTablespace

ChangedBlocks

ChangedBlocks

SubsequentCopies

Incrementally Updating Transportable Tablespaces Page 1 of 4

The underlying technology to update transported tablespaces with only the changes since it was transported, is RMAN’s capability to merge incrementals into image copies.

One-time Setup of Block Change Tracking and Recovery Catalog

Block Change Tracking

Before starting the incrementally updated transportable tablespace process, it is recommended to perform a one-time setup of block change tracking on the source database.

Block change tracking speeds up incremental backups by only reading and backing up changed blocks versus reading the entire datafile for changed blocks. This is accomplished by indicating which blocks have changed in a small bitmap file (change tracking file), as data changes occur. Upon an incremental backup, the file is read to locate just the changed blocks, and only those blocks are backed up.

For example, the following SQL command will enable block change tracking: > alter database enable block change tracking using file '/prepsp_0006/appl/oracle/prepsp/block_change_file';

Recovery Catalog

RMAN backup metadata is always written to the controlfile on backup operations; however, these records can age out based on the control_file_record_keep_time init.ora parameter (defaults to 7 days). Therefore, a recovery catalog is recommended for keeping an extended history of all RMAN backups, past the control_file_record_keep_time. For example, this is needed if the transportable tablespace procedure is run on a quarterly or monthly basis, since incremental backups will be taken relative to the full image copy that was created last quarter or month. Refer to the Oracle Backup and Recovery Advanced User’s Guide for the steps on creating a recovery catalog.

Incrementally Updated Transportable Tablespace Procedure Note 1: This procedure assumes that the destination database filesystems are NFS mounted on the source database server with read-write option. This allows the RMAN client to run on the source database, with backups made to the destination database filesystem.

Consider a tablespace TEST1 with two datafiles (/prepsp_0003/appl/oracle/prepsp/test101.dbf and /prepsp_0003/appl/oracle/prepsp/test102.dbf). These datafiles will be copied to the destination database location /prepsp_0006 (which is NFS mounted on the source database server with read-write option) and regularly updated with changes from the source database using incremental backups.

1. A one-time image copy backup of the datafiles in the tablespace is performed. This establishes a starting point for upcoming incremental backups.

Place the tablespace TEST1 in read-only mode: SQL> alter tablespace test1 read only; Make an image copy backup of the datafiles to the NFS mounted filesystem /prepsp_0006, with the following RMAN script: run { allocate channel d1 device type disk format

'/prepsp_0006/appl/oracle/prepsp/db1.dbf';# See Note 2 allocate channel d2 device type disk format '/prepsp_0006/appl/oracle/prepsp/db2.dbf';

BACKUP INCREMENTAL LEVEL 1 TAG "TEST9_BACKUP" for recover of copy with tag "TEST9_BACKUP" tablespace test1; # See Note 3

}

Incrementally Updating Transportable Tablespaces Page 2 of 4

Note 2: Absolute, non-OMF format is used so that ‘drop tablespace <tbs name> including contents’ in step 3 only drops tablespace metadata, not physical datafile. Note that if OMF is used, ‘drop tablespace <tbs name> including contents’ will drop both metadata and physical datafiles.

Note 3: Even though this is an ‘incremental level 1’ command, since there is no existing incremental level 0 of the datafiles, an incremental level 0 of the datafiles will instead be created.

After the script finishes, tablespace TEST1 can be placed back into read-write mode.

Note 4: See Alternative Method for Image Copy Creation for an alternative method to create the initial image copies, which can minimize the time that the tablespace must be in read-only mode.

2. Plug in the tablespace at destination database, e.g. > impdp readonly/readonly DIRECTORY=exp_dir NETWORK_LINK=dtest2.world TRANSPORT_TABLESPACES=test1 TRANSPORT_FULL_CHECK=n TRANSPORT_DATAFILES='/prepsp_0006/appl/oracle/prepsp/db1.dbf','/prepsp_0006/appl/oracle/prepsp/db2.dbf'

In this example, the import script should be run with datafiles pointing to datafiles in /prepsp_0006/appl/oracle/prepsp on the destination database.

3. When the transported tablespace needs to be incrementally updated (e.g. on quarterly or monthly basis), first drop the tablespace in the destination database with ‘drop tablespace <tbs name> including contents’. As mentioned previously, only tablespace metadata will be dropped, and physical datafiles will remain intact for use in next step.

4. If a new datafile was added to the source database since the last incremental update, run the following script to make an initial image copy in the destination database filesystem (for example, if the new datafile number is ‘3’).

First, place the tablespace TEST1 in read-only mode: alter tablespace test1 read only;

run { allocate channel d1 device type disk format '/prepsp_0006/appl/oracle/prepsp/db3.dbf'; BACKUP INCREMENTAL LEVEL 1 TAG "TEST9_BACKUP" for recover of copy with tag "TEST9_BACKUP" datafile 3; # See Note 5

}

Note 5: Even though this is an ‘incremental level 1’ command, since there is no existing incremental level 0 of the datafile, an incremental level 0 of the datafile will instead be created.

5. Perform an incremental backup and merge it with the datafiles in the destination database filesystem, thereby creating a new set of datafiles, with the following script.

Place the tablespace TEST1 in read-only mode (if step 4 was not performed): alter tablespace test1 read only;

run { allocate channel d1 device type disk format

'/prepsp_0005/appl/oracle/prepsp/db1%t.dbf';# See Note 6

allocate channel d2 device type disk format '/prepsp_0005/appl/oracle/prepsp/db2%t.dbf';

BACKUP INCREMENTAL LEVEL 1 TAG "TEST9_BACKUP" for recover of copy with tag "TEST9_BACKUP" tablespace

test1; # create new incremental backup recover copy of tablespace test1 with TAG

"TEST9_BACKUP"; # merge latest incremental with existing image copy

Incrementally Updating Transportable Tablespaces Page 3 of 4

} After script finishes, tablespace TEST1 can be put back into read-write mode.

Note 6: A different mount point (/prepsp_0005) is used in this example so that the incremental backups can be created in a different mount point, separate from the target datafiles location.

6. Plug the new datafiles into the destination database.

> impdp readonly/readonly DIRECTORY=exp_dir NETWORK_LINK=dtest2.world TRANSPORT_TABLESPACES=test1 TRANSPORT_FULL_CHECK=n TRANSPORT_DATAFILES='/prepsp_0006/appl/oracle/prepsp/db1.dbf','/prepsp_0006/appl/oracle/prepsp/db2.dbf'

Benefits Some of the benefits with this approach are as follows:

1. Creating the incremental backup used to roll forward the datafiles takes much less time than copying the whole datafiles. For example, this is very useful in data warehouse environments where last month’s data is added to the existing year’s worth of read-only data. Copying datafiles for the year’s worth of data, each time a monthly tablespace transport is needed, would consume an excessive amount of time.

2. Since NFS-mounted filesystems are used in this method, tablespaces can also be transferred between database servers in physically different locations or cities.

3. This procedure, which operates at the datafile level, has certain advantages over hardware-based copy methods. Hardware-based methods typically work at the storage unit of a volume group, which means that datafiles belonging to other tablespaces should not be placed in the same volume group as the tablespaces to be transported. This can result in inefficient space usage in the volume group. For example, in our environment, volume groups have a size of 400 GB and if the tablespace size is only 100 GB, then 300 GB is essentially wasted space.

Restrictions The following restrictions apply:

1. The tablespace transported to the destination database should always be in read-only mode.

2. OMF-style format string cannot be used to make initial image copies (see Note 2 above). The only exception is in the case of a newly added datafile to the existing tablespace.

Alternative Method for Image Copy Creation 1. BACKUP AS COPY .. can be used to make the initial image copies (while database is in read-write)

2. The tablespace is placed immediately into read-only mode

3. An incremental backup of the tablespace is taken

4. Tablespace is put back into read-write mode

5. Image copies are recovered with incremental backup to make them consistent.

In this case, read-only mode is only necessary for the time to make the incremental backup, rather than the entire image copy.

Incrementally Updating Transportable Tablespaces Page 4 of 4