New Source Database Added for EBS 12 + 11gR2 Transportable Tablespaces

The Transportable Tablespaces (TTS) process was originally certified for the migration of E-Business Suite R12 databases going from a source database of 11gR1 or 11gR2 to a target of 11gR2.

This requirement has now been expanded to include a source database of 10gR2 ( - this will potentially save time for existing 10gR2 customers as they can remove on a crucial upgrade step prior to performing the platform migration.

Transportable Tablespaces supported options

The migration process requires an updated Controlled patch delivered by the Oracle E-Business Suite Platform Engineering team, i.e. it requires a password obtainable from Oracle Support. We released the patch in this manner to gauge uptake, and help identify and monitor any customer issues due to the nature of this technology. This patch has been updated to now include supporting 10gR2 as a source database.

Does it meet your requirements?

Note that for migration across platforms of the same "endian" format, users are advised to use the Transportable Database (TDB) migration process instead for large databases. The "endian-ness" target platforms can be verified by querying the view V$DB_TRANSPORTABLE_PLATFORM using SQL*Plus (connected as sysdba) on the source platform:

SQL>select platform_name from v$db_transportable_platform;

If the intended target platform does not appear in the output, it means that it is of a different endian format from the source. Consequently. database migration will need to be performed via Transportable Tablespaces (for large databases) or export/import.

The use of Transportable Tablespaces can greatly speed up the migration of the data portion of the database. However, it does not affect metadata, which must still be migrated using export/import. We recommend that users initially perform a test migration on their database, using export/import with the 'metrics=y' parameter. This will help identify the relative amounts of data and metadata, and provide a basis for assessing likely gains in timing. In general, the larger the amount of data (compared to metadata), the greater the reduction in downtime that can be expected from using TTS as a migration process.

For smaller databases or for those that have relatively small data compared to metadata, TTS will not be as beneficial for cross endian migration and the use of export/import (datapump) for the whole database is recommended.

Where can I find more information?

Related Articles


Hi John,
Thanks for the posting. We are in the middle of an upgrade from 12.0.3 to 12.1.3 and also a migration from Solaris to Linux. We have been trying to optimize our datapump import timings and I was wondering if there are any metrics on how much faster a Transportable Tablespace migration would be compared to a migration using datapump. I realize that it would depend on how much data vs. metadata is being migrated, but was interested to know if Oracle has some benchmarks.


Posted by guest on August 02, 2013 at 02:57 PM PDT #

Hello Ramesh -
No, we don't have benchmarks on timings, and there would be variances depending on specific customer data which would make it difficult to predict - we highly recommend that customers run export/import first using known optimizations, and to use the metrics=y option to find out the size of metadata vs data on a testbed or copy of their production data. If this is within the tolerance for a downtime (say a weekend), then we'd recommend export/import (datapump) as it's relatively straightforward. If not, customers should look into the use of TTS and educate themselves on the added complexity of the process.
Having said that, generally speaking, it would not be unusual for typical large EBS databases to save multiple days of downtime when using TTS compared to export/import (datapump) where the metadata is also relatively small compared to data.

Posted by John Abraham on August 05, 2013 at 11:10 AM PDT #

Thanks John for the update.


Posted by guest on August 06, 2013 at 09:08 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed


« July 2015