PPLIES TO:
Oracle Database – Enterprise Edition – Version 9.2.0.1 to 12.1.0.1 [Release 9.2 to 12.1]
Oracle Database – Standard Edition – Version 9.0.2.0 to 12.1.0.1 [Release 9.0.1 to 12.1]
Information in this document applies to any platform.

PURPOSE
This note gives you a single reference point from which to quickly find answers to common questions and issues for Transportable Tablespaces (TTS) from versions 9i through 12c.

SCOPE
Covered topics include (1) why use transportable tablespaces (TTS), (2) commonly asked questions, (3) corruption bugs to patch for, and (4) common issues for using the feature.

In general, using TTS to a lower version of the database is not supported. Refer to Document 291024.1 for a more detailed discussion of this topic.

DETAILS
Why use Transportable Tablespaces (TTS)?
Up through 11gR2, “Oracle transportable tablespaces are the fastest way for moving large volumes of data between two Oracle databases.” Starting with 12c, you may find the full transportable feature more efficient for moving source databases with RDBMS version 11.2.0.3 and up to 12c. “Full transportable is more automated than transportable tablespaces because it moves the metadata and user data that resides in non-transportable tablespaces than would previously have been moved in multiple operations. This makes the full transportable feature useful for efficiently moving a database to a new computer system or upgrading to a new release of Oracle Database. (See Oracle Database New Features Guide 12c Release 1 (12.1) – Database Overall – Oracle Data Pump Support for Database Consolidation: Full Transportable and Oracle Database Administrator’s Guide 12c Release 1 (12.1) – Introduction to Full Transportable Export/Import.)
“The transportable tablespace feature is also useful in a number of scenarios, including:
Exporting and importing partitions in data warehousing tables
Publishing structured data on CDs
Copying multiple read-only versions of a tablespace on multiple databases
Archiving historical data
Performing tablespace point-in-time-recovery (TSPITR)
·

Migrating databases among RDBMS versions and OS platforms”
(See: Oracle Database Administrator’s Guide 11g Release 2 (11.2)

Commonly Asked Questions
#

Question

Short Answer

Complete Answer

1.

Are TTS export/import jobs restartable?

No.

The Oracle® Database Utilities guides state that exports/imports done in transportable tablespace mode are not restartable. (START_JOB is not applicable.) If a TTS import fails, you need to drop all of the tablespaces in the target that have been plugged in, likely recopy the datafiles, then import again. See the question below about the risk of using your original datafiles for import vs. a copy and ORA-19721.

2.

Can I create a transportable tablespace set from a standby database?

Yes; see complete answer.

Yes, but you must activate and open the standby database in order to do it. See Document 788176.1Transportable tablespace on standby.

3.

Can I downgrade a database with TTS?

No if the compatibility setting is lower in the target than in the source.

Per the Oracle Documentation, Compatibility Considerations for Transporting Data “the database signals an error if the compatibility level of the source database is higher than the compatibility level of the target database.”

4.

Can I move/migrate to both a different RDBMS version and OS platform at the same time?

Yes; must be 10g or higher to move across OS platforms.

See “Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable Document 1454872.1.”

5.

Can I migrate EBS via TTS?

Yes.

See notes “Using Transportable Database to migrate E-Business Suite R12 Using Oracle Database 10gR2 or 11gR1 Document 734763.1,” “Using Transportable Tablespaces for EBS Release 12.0 or 12.1 Using Database 11gR2 Document 1311487.1,” and “Using Transportable Tablespaces to Migrate Oracle EBS Release 12.0 or 12.1 Using Oracle Database 12.1.0 Document 1945814.1.”

6.

Can I move a PDB back to a non-CDB, and are adjustments needed?

Yes and Yes.

See “How to Move a PDB Back to a Non-CDB Using TRANSPORTABLE=ALWAYS Document 2027352.1.”

7.

Can I move raw files?

Yes, with RMAN.

See “Transportable tablespace EXP/IMP of ASM files” in Document 371556.1 How to move tablespaces across platforms using Transportable Tablespaces with RMAN.

8.

Can I transport just a single partition?

Yes.

See “How to move or transport table partition using Transportable Table Space (TTS)? Document 731559.1.”

9.

Can I use TTS with ASM?

Yes, with DBMS_FILE_TRANSFER, ASM files can be moved. RMAN may also be needed if endianness is different, depending on RDBMS version.

Use this document if the endian formats on the source/target databases are the same — OR — if the source version is at least 11.2.0.4: “How to Create Transportable Tablespaces Where the Source and Destination are ASM-Based Document 394798.1.” Use this document if the endian formats on the source/target database are different — AND — the source version is < 11.2.0.4: How to Migrate to different Endian Platform Using Transportable Tablespaces With RMAN Document 371556.1. 10. Can I perform a TTS export with a binary that has a lower RDBMS version than my source database? No. See Document 1454872.1 Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable (Doc ID 1454872.1). Also see the reference for ORA-1455 in the "Common Errors" section in the last table of this note. 11. Can I move a dictionary-managed tablespace to a database with a locally managed SYSTEM tablespace via TTS? Yes, but you will not be able to alter it read-write. If you plan to move a dictionary-managed tablespace to another database via transportable tablespaces (TTS), and you want to be able to open it read-write in the target database, you must convert it in the source database to locally managed before doing the TTS export. See Document 735978.1 How To Change A Dictionary Managed Tablespace To A Locally Managed Tablespace? to change the tablespace to locally managed before using TTS. 12. Can objects be EXCLUDED from the TTS export or import? Yes. The datafile size will remain the same. However space inside the datafile that remains unmapped at the end of the import (i.e. not recorded in the database) is reclaimed. (1) Find eligible object types: select object_path, comments from transportable_export_objects where object_path like 'TRANSPORTABLE_EXPORT%' and object_path not like '%PLUGTS%'; (2) See Document 1517267.1 TTS Using Datapump Expdp and Impdp Exports Statistics Despite Setting EXCLUDE=STATISTICS for an example of excluding table and index statistics. See Document 341733.1Export/Import DataPump Parameters INCLUDE and EXCLUDE - How to Load and Unload Specific Objects for more syntax. Specific, named objects (for example, specific tables) can also be excluded, as given in this note. Example: SQL> HOS expdp system/oracle directory= dumpfile= transport_tablespaces=,, EXCLUDE=TABLE:”IN(‘‘,’‘)” EXCLUDE=SCHEMA:”IN(‘‘)”

The example above will exclude table in all schemas, and will exclude all objects in the schema .

Hint: if you use the HOS (host) parameter, you can run the export/import commands from SQL*Plus and avoid having to use \ characters to escape all the quotes that would be needed if run from the OS. Putting the EXCLUDE/INCLUDE options in a parfile will also eliminate the need to escape the quotes.

13.

Can Transportable Tablespace Mode run with parallelism (i.e. use the parallel parameter)?

No.

The “transport_tablespaces” and “transport_datafiles” parameters are mutually exclusive with the
“parallel” parameter; transportable tablespace mode cannot be run in parallel. Trying to do so will yield an “ORA-39047: Jobs of type TRANSPORTABLE cannot use multiple execution streams.” However, the full transportable mode (full=y transportable=always) can use the parallel parameter.

14.

Do I have to convert the datafiles?

Yes, if the endianness is different. If the endianness is not different, see the complete answer to the right.

File conversion is NOT needed for tablespace data files that meet all three of the following requirements: (1) have a source and target OS with the same endianness (bitness does not matter), (2) will be imported into an RDBMS version that contains the patch for unpublished Bug 8973825 (10.2.0.5, or 11.2.0.2 and higher), and (3) do not contain undo and rollback segments (i.e. when a regular tablespace is in read-only mode). If the fix for unpublished Bug 8973825 is not available for your target database version, then you need to use the RMAN convert feature.

15.

Do I have to copy the datafiles? Or can I just use the originals?

You should always copy the original datafiles and use the copy to plug into the new database. You should never use the original source datafiles.

To use the original datafiles is extremely risky. You MUST have a viable backup of your database if you are going to use the original datafiles. If anything were to fail during the import of the tablespace in the target database, you might not be able to use the datafile(s) in either database, as the import alters the datafile headers at various points in the import process; restoring the datafiles from backup would be your only recovery option. There is not currently a way to tell at which point in the import process the datafile could be reused and when it could not.

Starting from 12c, during the TTS import operation, it internally sets the datafile status to READ WRITE in order to “clean up unclaimed segments and the TSTZ tables can be fixed up”. However, at the end of TTS import operation, it sets the datafile status back to READ ONLY. Since, it intermediately sets the status to READ WRITE, the datafile header gets changed and so it reports ORA-19721 if reused. The same datafile which was already attached once cannot be reused again.

16.

Do I need to pre-create users in the target database before importing?

Yes.

The other option is to use the remap_schema parameter to map exported users to existing users in the target database. See the Oracle Database Administrator’s Guide 11gR2 for details.

Note that if you pre-create a user and it uses a default tablespace that is not yet plugged in, you need to temporarily assign a default tablespace that exists in the target database. After the import is complete, you can alter the user and set the default tablespace to the desired one.

17.

Does TTS guarantee the first fast refresh of a materialized view (mview) will succeed after TTS import?

No, not even if it is a local mview.

See Document 1498846.1 TTS Does NOT Guarantee an MVIEW Fast Refresh Will Succeed after TTS Import — ORA-12034 Possible for an explanation and reference to the enhancement bug.

18.

Does TTS support Transparent Data Encryption (TDE)?

No.

Regular TTS does not support TDE. Only Full Transportable Export/Import (transportable=always) from 11.2.0.3+ supports tables with TDE columns when (1) the import target is V12 (i.e, parameter VERSION=12) and (2) when the endianness is the same between source and target. An example of using full transportable database is in Document 1958865.1 “How to Clone a Pluggable Database (PDB) Without Closing the PDB.” Restrictions on Full Transportable Export/Import are here.

19.

Does TTS support Analytical Workspace (AW) objects?

Limited.

TTS supports moving AW objects ONLY when the platform/operating system/word size/endianness/etc. all match between the source and target databases.

EIF format is the long-standing method to move OLAP objects between platforms. EIF is used to support NON-transportable datapump exports. See Document 468496.1 How To EIF Export and EIF Import An OLAP Analytic Workspace?

20.

How can I use a parfile with multiple lines for the transport_tablespaces and transport_datafiles parameters?

See syntax to the right.

Inside the parfile:

transport_tablespaces=
TABLESPACE001,
TABLESPACE002,
TABLESPACE003

— OR —

transport_datafiles=
‘/oradata/sid/data_01.dbf’,
‘/oradata/sid/data_02.dbf’,
‘/oradata/sid/index_01dbf’

(See Document 1131484.1 Expdp Transportable Tablespace Fails With ORA-39071 for details for compatibility < 10.2.0.4) 21. If the TTS import fails part way through, and a datafile has been plugged into the target database via TTS imp/impdp, but the tablespace has not been changed to read-write, is it possible to re-import using that same datafile if the tablespace is dropped from the target first? It depends, see full answer. The import process can modify the file headers at various points during the import, especially when transportable=always is used; it not currently possible to tell at which point in the import process that has happened, not even from a timestamp. The only thing you can do is drop* all of the tablespaces that have been plugged into the target and retry the entire TTS import. If it errors, you will need to recopy/convert all the datafiles again. You cannot do only a partial-tablespace import, as the export file references all tablespaces. * Oracle Managed Files (OMF) are dropped whenever the tablespace is dropped even if you do not use the 'AND DATAFILES' clause. Also be aware that for ASM files, unless you specify an ASM alias filename during file creation, the file is OMF. 22. Is there an easy-to-follow example? Yes, see note. See either "Transportable tablespace EXP/IMP of ASM files" or "Transportable tablespace EXP/IMP with OS files" in Document 371556.1 How to move tablespaces across platforms using Transportable Tablespaces with RMAN. The Document 243304.1 "10g+ Transportable Tablespaces Across Different Platforms" also gives a nice beginning-to-end example. 23. Is there a size limitation? No, except for a couple of size-related bugs, one which is a potential-corruption bug in < 11g. Please see note for description and patch information. Also see question/answer for the transportable_tablespaces parameter in this note. See Document 566875.1 Size Limitations On Cross Platform Transportable Tablespaces. 24. Is there a limit to the number of tablespaces that can be specified in the transport_tablespaces parameter? No, but there is a character limit for the parameter when compatible < 10.2.0.4. With compatibility < 10.2.0.4, there is a 4000-character limit to the value of the transport_tablespaces parameter, which is changed in 10.2.0.4 to 32K characters. This is a character limit, not a number-of-tablespaces limit; you will be able to specify fewer tablespace names if they are very long names than you would if you had shorter tablespace names. (See Document 1131484.1 ExpdpTransportable Tablespace Fails With ORA-39071 for details.) 25. Is TTS the best way to upgrade/migrate my database? It depends on a number of factors such as size, downtime, endianness conversion, etc. Document 1457743.1 Upgrading a Database Using Transportable Tablespaces (TTS) lists the pros and cons of using TTS to upgrade/migrate a database and provides information on other methods. 26. What restrictions/limitations exist for TTS? See note. Document 1454872.1 Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable (Doc ID 1454872.1). Also see Feature Availability for Oracle Database Editions in the Oracle licensing documentation. TTS import is available into SE, SE1, and EE, but TTS export is available only from EE. 27. What are best practices for using TTS, especially when migrating a database? See note. See Document 1457876.1 Best Practices for Using Transportable Tablespaces (TTS). 28. What if I don't wind up with the same number of non-SYS-owned objects in the target database as in the source? Use the structural export to recreate missing objects for the schemas that were transported. Objects such as PL/SQL, Java classes, callouts, views, triggers, roles, procedures, synonyms, users, privileges, dimensions, directories, and sequences. are not necessarily contained in the tablespaces you transport, since SYSTEM and SYSAUX are not transported. You should use a structural import (i.e. full export/import with no rows) after the TTS import to create any missing objects that you need. Users such as 'CTXSYS, 'ORDSYS', 'MDSYS', 'ORDPLUGINS', 'LBACSYS', 'XDB', 'SI_INFORMTN_SCHEMA', 'DIP', 'DMSYS', 'DBSNMP are treated as objects owned by 'SYS' and not exported with TTS. 29. What is XTTS? Cross-platform transportable tablespace. Some documents in the knowledge base refer to XTTS vs. TTS when talking about transporting tablespaces across OS platforms. The acronym TTS is just as applicable, however. 30. Windows-specific: Are Microsoft Windows 64-bit and Microsoft Windows 64-bit for AMD the same? Yes. Yes, the Windows x64 machines use the same software, no matter if your system has the AMD64 or the EM64T (Intel) processor. These are both different from Windows Itanium. The "IA" in the v$_transportable_platform for Microsoft Windows refers to Intel Architecture (IA). 31. What if I have set check violations? See note. Document 1459800.1 How to Fix Transport Set Check Violations (DBMS_TTS.TRANSPORT_SET_CHECK)(ORA-39908, ORA-39910, ORA-39932, ORA-39921, etc.). For more details, you can also refer to the section 'Self-Contained Set of Tablespaces' in the Oracle Administrator's Guide. Corruption Bugs Corruption bugs for the TTS feature of export/import include, but may not be limited to, the following. Please check the associated notes to see if you have potential for the issue. These notes also document workarounds, if available, in case there is not a patch for your RDBMS/OS combination. Bug Fixed In Description/Note 5936058 10.2.0.4 onwards Unpublished Bug 5936058: TABLESPACE TRANSPORT CAN GET CORRUPT TABLE METADATA. Table data will be out of sync in the target database after transporting a tablespace if in the source database long columns are dropped from a table. This fix is needed at the source and destination of the transport. The fix requires a new transport set to be created after the fix has been applied (ie: new .dmp file from source side). The fix should also be applied at the destination prior to importing that newly created transport set. See Document 5936058.8. Note: An issue of data transposed to different columns when a table contained a LONG was also reported for 11.2, but was abandoned because the customer could not wait for root cause. The workaround was to drop/recreate the table with the LONG in the source database and then re-export. 6120696 Not a bug. Even though the Endian formats are the same for certain different platforms, you need to use RMAN convert when source or target platform is HP-TRU64 ORA-600 [kcbz_check_objd_typ_3] Raised During Cross Platform Transportable Tablespace Operation on HP-TRU64 Document 458038.1 6730429 11.1.0.7, 10.2.0.5, 10.2.0.4 PB37 (Win) Windows Platforms ORA-600 [ktecgeb-2] may occur after converting an ASSM tablespace to a different endianness using RMAN Document 6730429.8, ORA-600[ktecgeb-2] Raised During Insert After OS Platform Conversion Document 554670.1 6906874, 9373087 10.2.0.5, 11.2.0.1 (6906874 only), 11.2.0.2 (9373087) Very High Next_extent After Transportable Tablespace ExerciseDocument 1362579.1 7044798 Not fixed in any version; workaround only. Although this is not technically a corruption bug, it requires action in the source database before doing the TTS export. See the workaround in Document 1232675.1 Ora-0600 [ktecgetsh-inc] After Using Transportable Tablespaces. 9786142 12.1, 11.2.0.3 Tablespace Transport with DataPump can corrupt the dictionary for LOB columns Document 9786142.8 9816640 Not feasible to fix; workaround only. Corrupt IOT when using Transportable Tablespace to HP from different OS Document 1334152.1 Causes ORA-600 [6200] or ORA-600 [kddummy_blkchk] 10136415 12.1.0.1, 11.2.0.3 This note tells about the bug: Document 10136415.8 "Bug 10136415 - ORA-8103 on Partitioned IOT after partition maintenance." This note tells how to find and fix the corruption:Document 1623077.1 "ORA-8103 on TTS IMPDP For IOT Partitioned Table Even After Applying Patch for Bug 10136415." 10226927 12.1, 11.2.0.3 Wrong Results/ Assorted errors on queries over tables after transportable tablespace import -- for exp (not expdp) Document 10226927.8 10324526 12.1; 11.2.0.3; 11.2.0.2.3 PSU; 11.2.0.2 BP6 for Exadata; 11.1.0.7.8 PSU; 10.2.0.5.4PSU; Win PBs for 11.2.0.2, 11.1.0.7, 10.2.0.5 ORA-600 [kddummy_blkchk] [6106] / corruption on COMPRESS table in TTS Document 10324526.8 13001379 12.1, 11.2.0.4* Datapump transport_tablespaces produces wrong dictionary metadata for some tables Document 13001379.8. See also Alert: TTS Bug 13001379 Can Cause Dictionary Corruption for Some Tables in Versions < 12.1 Document 1440203.1. Note: Applying the patch does not fix the corruption; it prevents the corruption upon the next import. * At the time this bug was added to the table (Mar. 2012), the 11.2.0.4 Patch Set had not yet been released. Common Errors/Issues with Transportable Tablespaces Please note this is not an exhaustive list of issues. Please check the "Transportable Tablespaces" heading in the "List of Bugs Fixed by Problem Type" notes for the patch set or version above the one you are currently running. These notes have the most comprehensive list of bug fixes in each patch set. (For example, 11.2.0.2 Patch Set - List of Bug Fixes by Problem Type (Document 1179583.1)). Error/Problem Suggested Solution ORA-00009 Document 1318855.1 ORA-00009 IMP-9 Due To Deferred Storage Segment Tables. Affects 11.2.0.1-11.2.0.2; fixed 11.2.0.3. ORA-1455 Document 1083330.1 Exporting Schema In 11.2 Database With 10g Client Gives ORA-1455, Document 1381690.1 EXP: ORA-1455 is raised when exporting from an 11.2 database using a 9i,10g or 11gR1 exp utility. ORA-8103 This note tells about the bug: Document 10136415.8 "Bug 10136415 - ORA-8103 on Partitioned IOT after partition maintenance." This note tells how to find and fix the corruption: Document 1623077.1 "ORA-8103 on TTS IMPDP For IOT Partitioned Table Even After Applying Patch for Bug 10136415." ORA-31671 ORA-600 [krhpfh_03-1204] ORA-600 [krhpfh_03-1206] Document 8973825.8 Bug 8973825 - ORA-600 [krhpfh_03-xxx] during IMPDP on cross platform transport. Fixed in 10.2.0.5, 11.2.0.2. Ora-0600 [ktecgetsh-inc] Document 1232675.1 Ora-0600 [ktecgetsh-inc] After Using Transportable Tablespaces. Workaround is to purge recyclebin of objects for the tablespace before exporting. Not currently fixed in any version. ORA-19721, IMP-3, IMP-0 ORA-19721 can be caused by a number of reasons. The most common are these: (1) Wrong endianness of the data file(s), (2) COMPATIBLE parameter has too low a value, (3) the file is not in the path specified by the TRANSPORT_DATAFILES parameter, (4) specifying datafiles for fewer tablespaces than were included in the expdp, (5) duplicate file names are included in the TRANSPORT_DATAFILES parameter, (6) the TRANSPORT_DATAFILES parameter had too long a value and was specified on the OS command line vs. via a parfile, and (7) the datafile was attached during a TTS import, but the import failed (see the question above about the ability to reuse the same datafiles for another TTS import attempt, especially for 12c+). These are some of the corresponding documents:Document 757795.1 Transportable Tablespace Import (TTS) Receives Error ORA-19721, Document 1459012.1 Error ORA-19721 during Transportable Tablespace (TTS) Import, Document 742436.1 ORA-19721 with Duplicated Datafiles name in the Import Command, Document 1624380.1 ORA-19721 With DataPump Export Using TRANSPORTABLE=ALWAYS and FULL=Y, Document 1621015.1 ORA-19721 During Transportable Tablespace Import When Using ASMCMD cp to Do Endianness Conversion, Document 1677412.1 ORA-19721 When Long List of TRANSPORT_DATAFILES Given in Command Line VS. Parfile. ORA-29341 The transportable set is not self-contained Document 114915.1 Using Dbms_tts.transport_set_check Results in Entry in Transport_set_violations, Document 867246.1 New Partitions or Subpartitions Are Being Created in the Wrong Tablespace, Bug 9723566 - Iot with constraints shows violations in transport_set_violations (Doc ID 9723566.8). ORA-27048: skgfifi: file header information is invalid when endianness is the same for source and target databases If the endianness is the same for source and target databases, this is caused by unpublished Bug 7594309: INCORRECT PLATFORM ID IN FILE HEADERS FOLLOWING TRANSPORTABLE DATABASE, which is superceded by unpublished Bug 8973825 - TMDCETTS.DIF IN SDO LABEL FAILING ON WINDOWS. See Document 8973825.8 for patch information, or use the RMAN CONVERT feature as a workaround. Fixed in 10.2.0.5 and 11.2.0.2. ORA-37145: () Cannot transport analytic workspace across platforms

TTS supports moving AW objects ONLY when the platform/operating system/word size/endianness/etc. all match between the source and target databases.

EIF format is the long-standing method to move OLAP objects between platforms; move OLAP schemas with regular (non-transportable) datapump via EIF format. See Document 468496.1 How To EIF Export and EIF Import An OLAP Analytic Workspace?

ORA-39002/ORA-39322

Document 10384616.8 Bug 10384616 – Data Pump transportable tablespace import fails with ORA-39002 / ORA-39322 with TIMESTAMP data. (Seems to affect 11.2.x only.)

ORA-39123, ORA-29344

Document 294992.1 Import DataPump: Transport Tablespace Fails with ORA-39123 and 29344 (Failed to match owner SYS). Fixed in 10.2.0.1.

ORA-39908, ORA-39910, ORA-39932, ORA-39921

Document 1459800.1 How to Fix Transport Set Check Violations (DBMS_TTS.TRANSPORT_SET_CHECK)(ORA-39908, ORA-39910, ORA-39932, ORA-39921, etc.).

ORA-37145 “(XSTTS_PLAT) Cannot transport analytic workspace across platforms.”

This error will appear in the import log if any of the platform/operating system/word size/endianness/etc. are different between the source and target databases.

TTS import completes successfully, but objects are missing

If you used traditional exp/imp, see Document 883153.1 What Objects Are Exported With Transportable Tablespaces (TTS) and the ORIGINAL Export Utility?

See answer in Q&A table above for question “What if I don’t wind up with the same number of non-SYS-owned objects in the target database as in the source?”

Bad performance/hang of TTS export of Oracle Text (domain) indexes

Document 1302676.1 Bad performance(hang) at TTS export of Oracle Text (domain) indexes.

Bad performance with TTS export and import of tables/indexes with many partitions/subpartitions (100,000+)

Document 1555857.1 Metadata Data Pump Export Is Slow When Exporting Indexes, Document 16298117.8Bug 16298117 – expdp for transport very slow with many partitioned tables/indexes. Fixed 11.2.0.4.

Bad performance/hang of TTS import and high CPU usage

Document 1560225.1 Transportable Tablespace (TTS) Using Impdp Seems to Hang at TRANSPORTABLE_EXPORT/PLUGTS_BLK Phase,
Document 16396856.8 Bug 16396856 : TTS IMPDP SEEMS TO HANG AND CONSUME 100% CPU….etc. Fixed 11.2.0.4 (11.2.0.3 P26 for Windows platform), 12.1.0.2.