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
Before detailing the incrementally updated transportable tablespace procedure, standard database architect for the work on
transportable tablespaces will first be discussed. Complete details of the transportable which this paper is based.
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:

Source
Target Database
Database

Tablespace Tablespace copy

First Time Copy

Plugged-in
Tablespace tablespace
Changed Changed
Blocks Blocks

Subsequent
Copies

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/o
racle/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/o
racle/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