Upgrading a Database Using Transportable Tablespaces

Prévia do material em texto

12/2/21, 11:19 PM Document 1457743.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=15p49rhoec_403&id=1457743.1 1/7
Copyright (c) 2021, Oracle. All rights reserved. Oracle Confidential.
Upgrading a Database Using Transportable Tablespaces (TTS) (Doc ID 1457743.1)
In this Document
Goal
Solution
 Is Transportable Tablespaces (TTS) the best way to upgrade my database?
 What are the prerequisites for using TTS?
 Where can I find a good example for how to do this?
 Can I move my database from this RDBMS/OS to that RDBMS/OS combination?
 Are the following combinations supported? 
 Can I migrate my Oracle E-Business Suite (EBS) using TTS?
 Is testing necessary?
References
APPLIES TO:
Oracle Database Cloud Schema Service - Version N/A and later
 Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
 Oracle Cloud Infrastructure - Database Service - Version N/A and later
 Oracle Database Cloud Exadata Service - Version N/A and later
 Oracle Database Exadata Express Cloud Service - Version N/A and later
 Information in this document applies to any platform.
 
GOAL
 This note addresses upgrading databases via the Transportable Tablespaces method, often referred to as TTS or xTTS
(cross-platform TTS).
SOLUTION
Is Transportable Tablespaces (TTS) the best way to upgrade my database?
There are many ways to upgrade a database. Which method you use depends on what you need to accomplish, how big
the database is, and how long you have to accomplish it. TTS is one method that you can use. In 12c, the Full
Transportable feature is introduced, which is much more flexible and easier to use than TTS, because you no longer need
to explicitly name all the tablespaces in your database, and objects in SYSTEM can now be transported as well. When the
source database is 11.2.0.3 or higher, and the target is 12c, TTS is better used for transporting a subset of tablespaces
from one database to another, vs. transporting the entire database to another version and/or platform.
The chart below shows some advantages/disadvantages of using Transportable functionality as it compares to the other
methods that are discussed in the Oracle Database Upgrade Guide (11gR2), Oracle Database Upgrade Guide 12c Release 1
(12.1), and Oracle Database Upgrade Guide 12c Release 2 (12.2).
Upgrade Method Advantages Disadvantages Optimal For . . .
Transportable Tablespaces
(TTS) Source database
remains intact.
Less downtime than
straight
export/import
utilities because
only the object
metadata is
Cross-platform
migration can
occur only with
RDBMS version
10g or higher.
Requires up-front
preparation in
terms of self-
containment
Flexibility, especially
cross-platform migration
when the source
database is < 11.2..0.3
and the target database
is < 12c.
Upgrading large
databases that need to
be moved to a different
http://docs.oracle.com/cd/E11882_01/server.112/e23633/preup.htm#i694345
http://docs.oracle.com/cd/E16655_01/server.121/e17642/intro.htm#BHCHEAHE
http://docs.oracle.com/database/122/UPGRD/intro-to-upgrading-oracle-database.htm#UPGRD001
12/2/21, 11:19 PM Document 1457743.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=15p49rhoec_403&id=1457743.1 2/7
exported, not the
data.
Allows all three of
the following,
singly, or in
combination:
Version
upgrade.
32-bit to 64-
bit upgrade.
Cross-
platform
migration
(version
10g+ only).
Uses a new, empty
target database (i.e.
just SYSTEM,
SYSAUX, UNDO,
TEMP tablespaces). 
Therefore data
dictionary
inconsistencies,
spurious objects
that don't belong to
SYS and SYSTEM,
etc. are cleaned up.
Allows for dry runs
to determine
downtime
requirements for
change control, and
the opportunity to
work out any issues
in the process
beforehand.
No need for a
complete database
backup before
beginning the
process, as the
source datafiles are
never touched other
than to put them in
read-only mode.
requirements (not
required for the
other methods).
Requires review of
TTS restrictions
and limitations.
Not all objects are
transported;
structural, no-rows
export still
needed. 
Endianness
conversion may be
needed between
OS platforms (not
required for plain
export/import).
A separate copy of
the datafiles is
needed; if large,
this can pose a
significant space
consideration if the
copy is also on the
source server.
Source database
should be kept
viable until you are
sure there are no
issues as a result
of the process.
Original
export/import
utilities (exp, imp)
are not supported
for use with TTS
for 11gR2 and
higher.
OLAP Analytic
Workspaces will
need to be
exported to EIF
formats before
migration if the OS
platform is
different.
server, whether or not the
OS or RDBMS version is
the same.
See these notes to get started:
Document 1166564.1 Primary
Note for Transportable
Tablespaces (TTS) -- Common
Questions and Issues for further
details.
Document 1454872.1
Transportable Tablespace (TTS)
Restrictions and Limitations:
Details, Reference, and Version
Where Applicable
Document 883153.1 What
Objects Are Exported With
Transportable Tablespaces (TTS)
and the ORIGINAL Export
Utility?
Document 438035.1 How To Use
Transportable Tablespaces To
Copy OLAP Analytic Workspaces 
In some cases downtime can be
reduced with these notes (check
restrictions in notes):
Document 1389592.1 11G -
Reduce Transportable
Tablespace Downtime using
Cross Platform Incremental
Backup
Document 2005729.112C -
Reduce Transportable
Tablespace Downtime using
Cross Platform Incremental
Backup
Full Transportable (Data
Pump with
TRANSPORTABLE=ALWAYS
and FULL=Y parameters)
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
Only for source
databases with
RDBMS version
11.2.0.3 and up
being moved to
12c.
Requires review of
Full Transportable
restrictions and
limitations.
Endianness
conversion may be
needed between
OS platforms (not
required for plain
export/import).
Flexibility, combined with
ease. when the source
database is 11.2.0.3 or
higher and the target is
12c, especially cross-
platform migration.
Upgrading large
databases that need to
be moved to a different
server, whether or not the
OS or RDBMS version is
the same.
See this documentation to get
started:
Oracle Database Administrator's
Guide 12c Release 2 (12.2) -
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1166564.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1454872.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=883153.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=438035.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1389592.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=2005729.1
http://docs.oracle.com/database/122/ADMIN/transporting-data.htm#ADMIN13725
12/2/21, 11:19 PM Document 1457743.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=15p49rhoec_403&id=1457743.1 3/7
database to a new
computer system or
upgrading to a new
release of Oracle
Database.
Removes the self-
containment
requirements that
are needed for TTS.
 
Full transportable
support for
multitenant
container databases
(CDBs) and non-
CDBs.
Source database
remains intact.
Less downtime than
straight
export/import
utilities because
only the object
metadata is
exported, not the
data.
Allows all three of
the following,
singly, or in
combination:
Version
upgrade.
32-bit to 64-
bit upgrade.
Cross-
platform
migration
(version
10g+ only).
Allows for dry runs
to determine
downtime
requirements for
change control, and
the opportunity to
work out any issues
in the processbeforehand.
No need for a
complete database
backup before
beginning the
process, as the
source datafiles are
never touched other
than to put them in
read-only mode.
You cannot
transport an
encrypted
tablespace to a
platform with
different
endianness.
A separate copy of
the datafiles is
needed; if large,
this can pose a
significant space
consideration if the
copy is also on the
source server.
Source database
should be kept
viable until you are
sure there are no
issues as a result
of the process.
OLAP Analytic
Workspaces will
need to be
exported to EIF
formats before
migration if the OS
platform is
different.
Transporting Databases -
Introduction to Full
Transportable Export/Import
(includes
limitations) 
Oracle Database Upgrade Guide
12c Release 2 (12.2) - Choose
an Upgrade Method for Oracle
Database - The Export/Import
Method for Migrating Data When
Upgrading Oracle Database
 
Transporting a Database Over
the Network (with
TRANSPORTABLE=ALWAYS)
Transporting a Database Using
an Export Dump File (with
TRANSPORTABLE=ALWAYS)
Export/Import Utilities
(without TTS parameters) Source database
remains intact.
Allows all three of
the following,
singly, or in
combination:
Time intensive; not
feasible for large
databases.
 Smaller databases
needing to be moved to a
different server,
regardless of whether the
OS or RDBMS version is
the same.
http://docs.oracle.com/database/122/ADMIN/transporting-data.htm#ADMIN13725
http://docs.oracle.com/database/122/UPGRD/choose-an-upgrade-method-for-oracle-database.htm#GUID-C42206CA-0BCC-424A-A714-FBBE1B0A7BDE
http://docs.oracle.com/database/122/ADMIN/transporting-data.htm#ADMIN13873
http://docs.oracle.com/database/122/ADMIN/transporting-data.htm#ADMIN13726
12/2/21, 11:19 PM Document 1457743.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=15p49rhoec_403&id=1457743.1 4/7
Version
upgrade.
32-bit to 64-
bit upgrade.
Cross-
platform
migration
(no version
limitation).
Since this is a
logical backup being
restored, no
physical structures
from the old
database are
carried over;
therefore, if
corruptions were
present in the
source database,
they will not be
present in the
target.
Tablespaces are
newly reorganized
in terms of space
usage.
No need for a
complete database
backup before
beginning the
process, as the
source datafiles are
never touched.
DBUA
GUI automates the
process.
In-place upgrade of
the data dictionary
and datafile
headers, so no
separate copy of
the datafiles is
needed.
There are no non-
transferrable
objects.
GUI controls the
process.
Requires complete
backup before
beginning the
upgrade process.
Requires a backout
plan and downtime
to execute it, if
needed.
Data dictionary is
not rebuilt, so any
inconsistencies
remain.
The "old version"
of the database no
longer exists.
Databases that do not
need to be moved to
another server or OS
when upgraded.
See these notes to get started:
Document 1503653.1 Complete
Checklist for Manual Upgrades to
Oracle Database 12c Release 1
(12.1)
Document 739485.1 How to
estimate the time required to
upgrade a database?
Document 870814.1 Complete
Checklist to Upgrade the
Database to 11gR2 using DBUA
Document 871665.1 How To
Restore A Database Back To The
Source Release After Upgrading
It To Oracle 11gR2 Using DBUA
Manual Upgrade via Oracle-
provided Scripts Control over the
process being run.
Requires
knowledge of the
 
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1503653.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=739485.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=870814.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=871665.1
12/2/21, 11:19 PM Document 1457743.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=15p49rhoec_403&id=1457743.1 5/7
In-place upgrade of
the data dictionary
and datafile
headers, so no
separate copy of
the datafiles is
needed.
There are no non-
transferrable
objects.
manual commands.
Requires complete
backup before
beginning the
upgrade process.
Requires a backout
plan and downtime
to execute it, if
needed.
Data dictionary is
not rebuilt, so any
inconsistencies
remain.
The "old version"
of the database no
longer exists.
 Databases that do not
need to be moved to
another server or OS
when upgraded.
See these notes to get started:
Document 1503653.1 Complete
Checklist for Manual Upgrades to
Oracle Database 12c Release 1
(12.1)
Document 837570.1 Complete
Checklist for Manual Upgrades to
11gR2
Document 429825.1 Complete
Checklist for Manual Upgrades to
11gR1
Document 316889.1 Complete
Checklist for Manual Upgrades to
10gR2
Unplug/plug PDB into
Higher Version Database is
upgraded by simply
unplugging from
one CDB, plugging
into another CDB of
higher version, and
running an upgrade
script. 
The upgrade script
can be run on
multiple PDBs in the
same CDB at once.
Multitenant option
required for more
than one PDB in a
CDB.
Same restrictions
apply for
considerations
such as
characterset, and
installed options. 
The CDB's
characterset and
installed options
must be equal to
or a superset of
the ones for the
PDB.
Backup
recommended.
PDBs in general.
Moving to a different
server, whether or not the
OS or RDBMS version is
the same.
See the Oracle documentation
for Upgrading a Pluggable
Database for complete, step-by-
step, upgrade instructions.
 
What are the prerequisites for using TTS?
Take time to thoroughly review the restrictions and limitations for TTS, follow best practices, and review the TTS primary
note, which contains common questions, errors, and a list of known corruption bugs. This takes up-front work, but will
help ensure a smooth export and import without issues. Once you've made this initial investment of time on the
prerequisites, upgrading/moving several databases of the same version becomes quite efficient.
Restrictions and limitations are consolidated into this note: Document 1454872.1 Transportable Tablespace (TTS)
Restrictions and Limitations: Details, Reference, and Version Where Applicable
Best practices are discussed in this note: Doc ID: 1457876.1 - Best Practices for Using Transportable Tablespaces
(TTS).
Common questions, errors, and a list of known corruption bugs are gathered in this note: Document 1166564.1
Primary Note for Transportable Tablespaces (TTS) -- Common Questions and Issues
Where can I find a good example for how to do this?
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1503653.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=837570.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=429825.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=316889.1
http://docs.oracle.com/database/121/UPGRD/upgrade.htm#UPGRD60151
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1454872.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1457876.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1166564.1
12/2/21, 11:19 PM Document 1457743.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=15p49rhoec_403&id=1457743.1 6/7
The TTS primary note Document 1166564.1 provides some good notes that have easy-to-follow examples. They are also
listed here for convenience. (See the TTS primary note for ASM notes.)
Document 371556.1 How to move tablespaces across platforms using Transportable Tablespaces with RMAN
Document 243304.1 10g+ Transportable Tablespaces Across Different Platforms" also gives a nice beginning-to-end
example
Document 733824.1 How To Recreate a database using TTS (Transportable Tablespace)
Can I movemy database from this RDBMS/OS to that RDBMS/OS combination?
Transportable Tablespaces were first introduced in 8i, so you can use TTS between any version of the database from 8i on,
as long as it's on the same architecture. Starting in 10g, you can also move a 10g+ database across OS platforms
(different architectures) with TTS (sometimes also referred to as XTTS for cross-platform). You can always find the OS
platforms supported for TTS by your version of the source database by running this query. If the platform you're looking
to move TO is on this list, then you can move your 10g+ database to it.
SQL> -- This list taken from 11.2.0.3. Older RDBMS versions may contain fewer platforms.
 SQL> -- The list will not contain the platform info for the database from which you are running
the query.
 SQL> col platform_name for a35
 SQL> select * from v$transportable_platform order by platform_id;
 
PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
 ----------- ----------------------------------- --------------
 1 Solaris[tm] OE (32-bit) Big
 2 Solaris[tm] OE (64-bit) Big
 3 HP-UX (64-bit) Big
 4 HP-UX IA (64-bit) Big
 5 HP Tru64 UNIX Little
 6 AIX-Based Systems (64-bit) Big
 7 Microsoft Windows IA (32-bit) Little
 8 Microsoft Windows IA (64-bit) Little
 9 IBM zSeries Based Linux Big
 10 Linux IA (32-bit) Little
 11 Linux IA (64-bit) Little
 12 Microsoft Windows x86 64-bit Little
 13 Linux x86 64-bit Little
 14 Linux x86 32-bit Little
 15 HP Open VMS Little
 16 Apple Mac OS Big
 17 Solaris Operating System (x86) Little
 18 IBM Power Based Linux Big
 19 HP IA Open VMS Little
 20 Solaris Operating System (x86-64) Little
 21 Apple Mac OS (x86-64) Little
SQL> -- You can easily find the platform info for the database running the above query by using
the following SQL:
SQL> SELECT tp.platform_id,substr(d.PLATFORM_NAME,1,30), ENDIAN_FORMAT
 FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d
 WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;
Are the following combinations supported? 
The following lists some common scenarios and whether or not they are supported by TTS:
1. Move 9.2.0.x on Solaris 64-bit to 11.2.0.x on Solaris 64-bit (same OS)?
Yes, TTS will support this, since the 9.2.0.8 supports version upgrades, and the OS didn't change.
2. Move 9.2.0.x on Solaris 64-bit to 11.2.0.x on Linux x86_64?
No, TTS will NOT support this. The endianness of the OS is different (big to little), and cross-platform is not
supported until 10g. You will need to upgrade the database to 10g (or higher) on the current server, and then use
TTS to move cross-platform.
3. Move 9.2.0.x on Solaris 64-bit to 11.2.0.x on AIX-Based Systems (64 bit)?
No, TTS will NOT support this. Even though the endianness is the same (both big), the RDBMS version is written
into the datafile headers, and cross-platform is not supported until 10g; the import will fail. You also CANNOT use a
10g export binary to export the 9i database, as it will also fail on the import. You will need to upgrade the
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1166564.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=371556.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=243304.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=733824.1
12/2/21, 11:19 PM Document 1457743.1
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=15p49rhoec_403&id=1457743.1 7/7
database to 10g (or higher) on the current server, and then use TTS to move cross-platform. Once your source
database is at 10g (or higher), if tablespaces you are transporting do not contain undo or rollback segments, you
do not need to convert them when moving to another OS with the same endianness (rollback segments and undo
segments are removed from a data/index tablespace when the tablespace is put in read-only mode).
4. Move 10.1.0.x on AIX-Based Systems (64-bit) to 11.2.0.x on Solaris 64-bit?
Yes, TTS will support this, since endianness is the same (both big), and the RDBMS version is 10g (or higher). If
tablespaces you are transporting do not contain undo or rollback segments, you do not need to convert them when
moving to another OS with the same endianness (rollback segments and undo segments are removed from a
data/index tablespace when the tablespace is put in read-only mode).
5. Move 10.1.0.x on Linux x86_64 to 12c on Solaris 64-bit?
Yes, TTS should support this, since the source RDBMS version is 10g (or higher). You will need to convert the
datafiles before importing; instructions for doing this are contained in the notes referenced above under the
question, "Where can I find a good example for how to do this?" 
Note that the older the source database, and the higher the version difference, the more the likelihood you may discover
issues that have not been previously encountered; depending on RDBMS version, exception patching may or may not be
available for your case.
 Can I migrate my Oracle E-Business Suite (EBS) using TTS?
Yes, the EBS migration uses TTS, but has its own set of scripts and procedures. The restrictions and limitations
referenced in this note still apply. Please see one of the following note for EBS migration procedures.
Document 729309.1 Using Transportable Database to migrate Oracle E-Business Suite 11i Using Oracle Database
10.2.0 or 11.1.0
Document 734763.1 Using Transportable Database to migrate E-Business Suite R12 Using Oracle Database 10gR2
or 11gR1
Document 1945814.1 Using Transportable Tablespaces to Migrate Oracle EBS Release 12.0 or 12.1 Using Oracle
Database 12.1.0
Document 2157661.1 Using Transportable Tablespaces to Migrate Oracle EBS Release 12.2 Using Oracle Database
12.1.0
Is testing necessary?
Absolutely! Any upgrade process resulting in a new database version and possibly changes in platform, operating system,
and hardware should be thoroughly tested to ensure all functionality is verified and performance meets expectations prior
to employing the process for production operations.
REFERENCES
NOTE:1454872.1 - Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where
Applicable
 NOTE:1166564.1 - Primary Note for Transportable Tablespaces (TTS) -- Common Questions and Issues
NOTE:243304.1 - 10g+: Transportable Tablespaces Across Different Platforms
NOTE:733824.1 - How To Recreate A Database Using TTS (Transportable TableSpace)
 NOTE:419550.1 - Different Upgrade Methods For Upgrading Your Database
 
NOTE:371556.1 - How to Migrate to different Endian Platform Using Transportable Tablespaces With RMAN
 NOTE:1457876.1 - Best Practices for Using Transportable Tablespaces (TTS)
Didn't find what you are looking for?
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=729309.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=734763.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1945814.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=2157661.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1454872.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1166564.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=243304.1https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=733824.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=419550.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=371556.1
https://support.oracle.com/epmos/faces/DocumentDisplay?parent=DOCUMENT&sourceId=1457743.1&id=1457876.1