|
#
|
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.)
|
|
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.
|
|
3.
|
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."
|
|
4.
|
Can I migrate EBS via TTS?
|
Yes.
|
See notes "Using Transportable Database to migrate Oracle E-Business Suite 11i Using Oracle Database 10.2.0 or 11.1.0 Document 729309.1," and "Using Transportable Database to migrate E-Business Suite R12 Using Oracle Database 10gR2 or 11gR1 Document 734763.1."
|
|
5.
|
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.
|
|
6.
|
Can I transport just a single partition?
|
Yes.
|
See "How to move or transport table partition using Transportable Table Space (TTS)? Document 731559.1."
|
|
7.
|
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.
|
|
8.
|
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.
|
|
9.
|
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.
|
|
10.
|
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.
|
|
11.
|
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. If anything were to fail during the alter read-write of the tablespace in the target database, you might not be able to use the datafile(s) in either database, as the alter of the tablespace updates the datafile headers.
|
|
12.
|
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.
|
|
13.
|
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.
|
|
14.
|
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?
|
|
15.
|
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)
|
|
16.
|
If 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?
|
Yes; see complete answer.
|
Yes*, providing (1) the tablespace has not been altered to read-write in the target database (i.e. the datafiles have the same timestamp as when they were copied from the read-only source datafiles), and (2) the export file that corresponds to the copied datafiles has been retained. Also, make sure you do not use 'AND DATAFILES' clause when dropping the plugged-in tablespace.
* The exception is if files are OMF. Oracle Managed Files 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.
|
|
17.
|
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.
|
|
18.
|
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.
|
|
19.
|
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.)
|
|
20.
|
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.
|
|
21.
|
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.
|
|
22.
|
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).
|
|
23.
|
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 users, functions, procedures, views, etc. 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.
|
|
24.
|
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.
|
|
25.
|
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).
|
|
26.
|
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.
|
