APPLIES TO:
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Oracle Database - Enterprise Edition - Version 9.2.0.1 and later
Oracle Database - Standard Edition - Version 9.2.0.1 and later
Oracle Database Cloud Schema Service - Version N/A and later
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.
本说明为您提供了一个参考点，可从中快速找到版本9i至版本12c的Transportable Tablespaces (TTS)常见问题的答案
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.
涵盖的主题包括（1）为什么使用 transportable tablespaces (TTS)，（2）常见问题，（3）要修补的BUG 以及（4）使用该功能的常见问题。
DETAILS
Why use Transportable Tablespaces (TTS)? 为什么要使用传输表空间（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 Database New Features Guide for 12.1 and Oracle Database Administrator's Guide 12c Release 1 (12.1) - Introduction to Full Transportable Export/Import.)
- 直到 11gR2，"Oracle传输表空间是在两个Oracle数据库之间移动大量数据的最快方法" 从12c开始，您可能会发现 Full transportable 功能对于移动RDBMS版本11.2.0.3和最高12c的源数据库更加有效。 "Full transportable 比 transportable tablespaces 具有更高的自动化程度，因为它移动了元数据和驻留在 non-transportable tablespaces 中的用户数据比以前在多个操作中进行的移动要多。。这使得 full transportable 功能对于将数据库有效地移动到新计算机系统或升级到新版本的Oracle数据库非常有用。
- "The transportable tablespace feature is also useful in a number of scenarios, including: TTS功能在许多情况下也很有用，包括
- Exporting and importing partitions in data warehousing tables 在数据仓库表中导出和导入分区
- Publishing structured data on CDs 在CD上发布结构化数据
- Copying multiple read-only versions of a tablespace on multiple databases 在多个数据库上复制表空间的多个只读版本
- Archiving historical data 存档历史数据
- Performing tablespace point-in-time-recovery (TSPITR) 执行表空间时间点恢复（TSPITR）
-
- Migrating databases among RDBMS versions and OS platforms" 在RDBMS版本和OS平台之间迁移数据库
(See: Transporting Tablespaces Between Databases)
Commonly Asked Questions
| # | Question | Short Answer | Complete Answer |
|---|---|---|---|
|
1. |
Are TTS export/import jobs restartable? TTS export/import 作业是否可以重新启动 |
No. |
The Oracle® Database Utilities guides state that exports/imports done in transportable tablespace mode are not restartable. (START_JOB is not applicable.) This applies to any type of transportable job, including full=y transportable=always. 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. Oracle®数据库实用程序指南指出，在可传输表空间模式下完成的导出/导入不可重新启动。（START_JOB不适用）这适用于任何类型的 transportable job，包括full=y transportable=always。如果TTS导入失败，则需要删除目标中已插入的所有表空间，可能会重新复制数据文件，然后再次导入。请参阅以下有关使用原始数据文件进行导入而不是使用副本和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.1 Transportable tablespace on standby. 是的，但是您必须激活并打开备用数据库才能这样做。请参阅Document 788176.1 Transportable tablespace on standby |
|
3. |
Can I downgrade a database with TTS? 我可以使用TTS降级数据库吗 |
No if the compatibility setting is lower in the target than in the source. 如果目标中的兼容性设置低于源中的兼容性设置，则为No |
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." 根据《 Oracle文档，传输数据的兼容性注意事项》，“如果源数据库的兼容性级别高于目标数据库的兼容性级别，则数据库会发出错误信号。” |
|
4. |
Can I move/migrate to both a different RDBMS version and OS platform at the same time? 我可以同时移动/迁移到另一个RDBMS版本和OS平台吗 |
Yes; must be 10g or higher to move across OS platforms. Yes; 必须为10g或更高才能在OS平台之间移动 |
See "Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable Document 1454872.1." 请参阅“可传输表空间（TTS）限制和限制：适用文档1454872.1的详细信息，参考和版本” |
|
5. |
Can I migrate EBS via TTS? 我可以通过TTS迁移EBS吗 |
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? 是否可以将PDB移回non-CDB，是否需要进行调整？ |
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? 我可以在ASM中使用TTS吗 |
Yes, with DBMS_FILE_TRANSFER, ASM files can be moved. RMAN may also be needed if endianness is different, depending on RDBMS version. 使用DBMS_FILE_TRANSFER可以移动ASM文件。如果字节序不同，则可能还需要RMAN，具体取决于RDBMS版本 |
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? 是否可以使用RDBMS版本低于源数据库的二进制文件执行TTS导出？ |
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? 我可以通过TTS将字典管理的表空间移动到具有本地管理的SYSTEM表空间的数据库吗？ |
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. 如果计划通过传输表空间（TTS）将字典管理的表空间移动到另一个数据库，并且希望能够在目标数据库中以读写方式打开它，则必须先将其在源数据库中转换为本地管理，然后再进行操作 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? 可以从TTS导出或导入中排除对象吗 |
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: 查找合格的对象类型 The example above will exclude table <table_name> in all schemas, and will exclude all objects in the schema <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)? 可传输表空间模式可以并行运行吗（即使用parallel参数） |
Not < 12.2. 不小于12.2 |
The "transport_tablespaces" and "transport_datafiles" parameters are mutually exclusive with the |
| 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. 如果字节序不同，则为YES。 如果字节序没有不同，请参见右侧的完整答案。 |
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. 满足以下所有三个要求的表空间数据文件不需要文件转换：（1）具有相同字节顺序的源OS和目标OS（位无关紧要），（2）将被导入到包含以下内容的RDBMS版本中 未发布的Bug 8973825（10.2.0.5或11.2.0.2及更高版本）的修补程序，以及（3）不包含undo和回滚段（即，当常规表空间处于只读模式时）。 如果未发布的Bug 8973825的修复不适用于您的目标数据库版本，则您需要使用RMAN转换功能。 |
| 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. 从12c开始，在TTS导入操作期间，它在内部将数据文件状态设置为READ WRITE，以便“清理无人认领的段并可以修复TSTZ表”。 但是，在TTS导入操作结束时，它将数据文件状态设置回“只读”。 因为它在中间将状态设置为READ WRITE，所以数据文件头被更改，因此如果重新使用它会报告ORA-19721。 已经附加一次的相同数据文件不能再次使用。 |
| 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. 请注意，如果您预先创建了一个用户，并且该用户使用了尚未插入的默认表空间，则需要临时分配目标数据库中存在的默认表空间。 导入完成后，您可以更改用户并将默认表空间设置为所需的表空间。 |
| 17. |
Does TTS guarantee the first fast refresh of a materialized view (mview) will succeed after TTS import? TTS是否保证在导入TTS后成功实现实例化视图（mview）的第一次快速刷新？ |
No, not even if it is a local mview. 即使是本地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)? TTS是否支持透明数据加密（TDE） |
From 11.2.0.4+ |
Document 1674166.1 "How to use TTS with TDE" demonstrates this is possible with 11.2.0.4+. This is currently at odds with the Oracle documentation, which says it is a restriction; a documentation bug has been filed to get the documentation for 12.1 and 12.2 corrected. |
| 19. |
Does TTS support Analytical Workspace (AW) objects? TTS是否支持分析工作区（AW）对象？ |
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 468496.1> How To EIF Export and EIF Import An OLAP Analytic Workspace? |
| 20. |
How can I tell if a tablespace has been plugged into this database? 如何判断表空间是否已插入此数据库？ |
PLUGGED_IN column in DBA_TABLESPACES. |
SELECT TABLESPACE_NAME, PLUGGED_IN FROM DBA_TABLESPACES WHERE PLUGGED_IN='YES' ; |
| 21. |
How can I use a parfile with multiple lines for the transport_tablespaces and transport_datafiles parameters? 如何将带有多行的parfile用于transport_tablespaces和transport_datafiles参数？ |
See syntax to the right. 请参阅右侧的语法。 |
Inside the parfile: transport_tablespaces= -- OR -- transport_datafiles= (See Document 1131484.1 Expdp Transportable Tablespace Fails With ORA-39071 for details for compatibility < 10.2.0.4) |
| 22. |
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? 如果TTS导入在途中失败，并且已通过TTS imp/impdp将数据文件插入到目标数据库中，但表空间未更改为可读写，则如果使用了相同的数据文件，则可以重新导入 表空间首先从目标中删除？ |
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. 导入过程可以在导入过程中的各个点修改文件头，尤其是在使用transportable = always时； 目前，即使从时间戳记中，也无法确定导入过程中发生的时间。 您唯一可以做的就是删除*已插入到目标中的所有表空间，然后重试整个TTS导入。 如果出错，则需要再次重新复制/转换所有数据文件。 您不能仅执行部分表空间的导入，因为导出文件会引用所有表空间。 * 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. *每当删除表空间时，即使不使用“ AND DATAFILES”子句，也会删除Oracle Managed Files（OMF）。 还应注意，对于ASM文件，除非在文件创建过程中指定ASM别名文件名，否则该文件为OMF。 |
| 23. |
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. |
| 24. |
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. 否，除了几个与大小有关的bug外，一个小于11g的潜在bug。 请参阅注释以获取描述和补丁信息。 另请参阅本说明中关于transportable_tablespaces参数的问题/答案。 |
See Document 566875.1 Size Limitations On Cross Platform Transportable Tablespaces. |
| 25. |
Is there a limit to the number of tablespaces that can be specified in the transport_tablespaces parameter? 在transport_tablespaces参数中可以指定的表空间数量是否有限制？ |
No, but there is a character limit for the parameter when compatible < 10.2.0.4. 但是当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.) compatibility < 10.2.0.4时，transport_tablespaces参数的值有4000个字符的限制，该限制以10.2.0.4更改为32K个字符。 这是一个字符数限制，而不是表空间数限制； 如果表空间名称很长，则可以指定的表空间名称少于表空间名称较短的名称。 |
| 26. |
Is TTS the best way to upgrade/migrate my database? TTS是升级/迁移数据库的最佳方法吗？ |
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. |
| 27. |
Is XML supported in TTS? TTS支持XML吗？ |
See note. |
Beginning in 12.2.0.1 there is almost complete support for the tablespace and fully transportable modes of TTS. Lower RDBMS versions have varying degrees of support. See the section "Tablespace containing XML Types" in "Document 1454872.1 Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable (Doc ID 1454872.1)" for details. Also note there is a recommended patch to be installed for 12.2.0.1 only. |
| 28. |
What restrictions/limitations exist for TTS? TTS存在哪些限制 |
See note. |
Document 1454872.1 Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable (Doc ID 1454872.1). |
| 29. |
What are best practices for using TTS, especially when migrating a database? 使用TTS的最佳实践是什么，尤其是在迁移数据库时？ |
See note. |
See Document 1457876.1 Best Practices for Using Transportable Tablespaces (TTS). |
| 30. |
What if I don't wind up with the same number of non-SYS-owned objects in the target database as in the source? 如果我在目标数据库中没有获得与源数据库中相同数量的非SYS拥有的对象怎么办？ |
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. 对象，例如PL/SQL, Java classes, callouts, views, triggers, roles, procedures, synonyms, users, privileges, dimensions, directories, and sequences. 由于未传输SYSTEM和SYSAUX，因此不一定包含在要传输的表空间中。 在TTS导入之后，您应该使用结构化导入（即 full export/import with no rows）来创建所需的任何缺少的对象。 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. |
| 31. | What is XTTS? 什么是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. 在讨论跨OS平台传输表空间时，知识库中的某些文档涉及XTTS与TTS。 首字母缩写词TTS同样适用。 |
| 32. |
Windows-specific: Are Microsoft Windows 64-bit and Microsoft Windows 64-bit for AMD the same? Windows特定：用于AMD的Microsoft Windows 64位和Microsoft Windows 64位是否相同？ |
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. 是的，无论您的系统具有AMD64还是EM64T（英特尔）处理器，Windows x64机器都使用相同的软件。 这些都与Windows Itanium不同。 The "IA" in the v$_transportable_platform for Microsoft Windows refers to Intel Architecture (IA). Microsoft Windows 的v$_transportable_platform中的“ IA”是指英特尔体系结构（IA） |
|
33. |
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 'Task1: Pick a Self-Contained Set of Tablespaces' in the Oracle Administrator's Guide (scroll down to find the heading). |
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.
export/import 的TTS功能的损坏BUG 包括但不限于以下内容。 请检查相关的注释，以查看是否有潜在的问题。 如果没有RDBMS / OS组合的修补程序，这些说明还记录了变通方法（如果有）。
| Bug | Fixed In | Description/Note |
|---|---|---|
| 5936058 | 10.2.0.4 onward |
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. |
| 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 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 6730429.8>, ORA-600[ktecgeb-2] Raised During Insert After OS Platform Conversion 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 Exercise 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 1232675.1> Ora-0600 [ktecgetsh-inc] After Using Transportable Tablespaces. |
| 9145541 | 11.1.0.7.4, 11.2.0.1.2, 11.2.0.2, 12.1.0.1 | OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile after CREATE CONTROLFILE in 11g |
| 9786142 | 12.1, 11.2.0.3 | Tablespace Transport with DataPump can corrupt the dictionary for LOB columns 9786142.8> |
| 9816640 | Not feasible to fix; workaround only. | Corrupt IOT when using Transportable Tablespace to HP from different OS 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: 10136415.8> "Bug 10136415 - ORA-8103 on Partitioned IOT after partition maintenance." This note tells how to find and fix the corruption: 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) 10226927.8> |
| 10249791 | 11.2.0.2.7, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1 | ORA-600 [4097] / ORA-600 [4000] reported on DMLS referencing SECUREFILE plugged using transportable tablespaces |
| 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 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 1440203.1>. Note: Applying the patch does not fix the corruption; it prevents the corruption upon the next import. |
| 10132870 | 12.1 | See 10132870.8 Index leaf block corruption possible after plugging in transportable tablespace |
| 13366199 | 11.2.0.3.11, 11.2.0.3.BP23, 11.2.0.4, 12.1.0.1 | ORA-600 [4097] or [ktugin_cr:1] after plugging a Transportable Tablespace with Securefiles |
| 14363143 | 11.2.0.4, 12.1.0.1 | Document 14363143.8 Bug 14363143 - TTS import create corrupt dictionary entry in COL$ if tables have unused virtual column/s |
| 22869914 | 18.1 | See 2158312.1> "Wrong Results for Partitioned Table after TTS Import when Export done with UNUSABLE Bitmap Index Partition" for the workaround, which must be done in the source database BEFORE export. |
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-00001 ORA-39126 KUPW$WORKER.UNLOAD_DATA |
Document 21828674.8 Bug 21828674 - Various errors with Full Transportable export/import when PARALLEL= clause used with a value greater than 1. Affects < 12.2; fix cannot be backported to lower versions. |
|
ORA-00009 |
Document 1318855.1 ORA-00009 |
|
ORA-1422 (with preceding ORA-39126) |
Document 1539648.1 ORA-39126 & ORA-01422 When Running Expdp With Transportable Tablespaces, Document 14215851.8 Bug 14215851 - EXPDP of transportable tablespace fails with ORA-39126 / ORA-01422, Document 1537612.1 EXPDP OF TRANSPORTABLE TABLESPACE FAILS WITH ORA-39126 AND ORA-01422 EVEN WITH PATCH14215851 APPLIED. |
|
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-1647: tablespace is read only, cannot allocate space in it |
Make sure deferred_segment_creation = true in the target. Also make sure there are no invalid objects or unusable indexes in the source (if there are, fix them and redo the export). Invalid objects and unusable indexes will not have the SEG_FILE and SEG_BLOCK storage parameters in the exported metadata, which are necessary to plug in an object; without SEG_FILE and SEG_BLOCK in the plug-in metadata, the import will try to actually create it in the database, which causes the ORA-1647. You may need to patch for Bug 17402461 if you are importing a subpartitioned table with LOBs into a database < RDBMS version 12.1.0.2. |
|
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 |
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, |
| 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: (<object name>) 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.8 Bug 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, |
Additional Resources
Community Discussions: Data Warehousing
Still have questions? Use the above community to search for similar discussions or start a new discussion on this subject.
REFERENCES
BUG:22869914 - UNUSABLE INDEX USABLE AFTER TTS CAUSING WRONG RESULTS
NOTE:137482.1 - OMF (Oracle Managed Files) Usage for Datafiles
BUG:17402461 - TTS IMPDP FAILS WITH ORA-1647 FOR INTERVAL PARTITIONED TABLE WITH CLOB COLUMN
BUG:14363143 - DOWN STREAMS CAPTURE ABORTING WITH ORA-1400 ERRORS
NOTE:21828674.8 - Bug 21828674 - Various errors with Full Transportable export/import when PARALLEL= clause used with a value greater than 1