Académique Documents
Professionnel Documents
Culture Documents
1]
Modified 29-OCT-2010 Type HOWTO Status PUBLISHED
Starting with Oracle Database 10g, you can transport tablespaces across
platforms. In this note there is a step by step guide about how to do it
with ASM datafiles and with OS filesystem datafiles.
Supported platforms
====================
You can query the V$TRANSPORTABLE_PLATFORM view to see the platforms that are
supported and to determine each platform's endian format (byte ordering).
If the source platform and the target platform are of different endianness, then an additional step must be
done on either the source or target platform to convert the tablespace being transported to the target
format. If they are of the same endianness, then no conversion is necessary and tablespaces can be
transported as if they were on the same platform.
1. The source and target database must use the same character set and national character set.
2. You cannot transport a tablespace to a target database in which a tablespace with the same name
already exists. However, you can rename either the tablespace to be transported or the destination
tablespace before the transport operation.
3. Objects with underlying objects (such as materialized views) or contained objects (such as partitioned
tables) are not transportable unless all of the underlying or contained objects are in the tablespace set. *
Review Table "Objects Exported and Imported in Each Mode" from the Oracle Database Utilities
documentation, there are several object types that are not exported in tablespace mode.
4. If the owner/s of tablespace objects does not exist on target database, the usernames need to be
created manually before starting the transportable tablespace import. * If you use spatial indexes, then:
- be aware that TTS across different endian platforms are not supported for spatial indexes in 10gR1
and 10gR2; such a limitation has been released in 11g - specific Spatial packages must be run before
exporting and after transportation, please see Oracle Spatial documentation.
4. Beginning with Oracle Database 10g Release 2, you can transport tablespaces that contain XMLTypes,
but you must use the IMP and EXP utilities, not Data Pump. When using EXP, ensure that the
CONSTRAINTS and TRIGGERS parameters are set to Y (the default).The following query returns a list
of tablespaces that contain XMLTypes:
select distinct p.tablespace_name
from dba_tablespaces p, dba_xml_tables x, dba_users u, all_all_tables t
where t.table_name=x.table_name and
t.tablespace_name=p.tablespace_name and
x.owner=u.username
5. Advanced Queues Transportable tablespaces do not support 8.0-compatible advanced queues with
multiple recipients.
6. You cannot transport the SYSTEM tablespace or objects owned by the user SYS.
7. Opaque Types Types(such as RAW, BFILE, and the AnyTypes) can be transported, but they are not
converted as part of the cross-platform transport operation. Their actual structure is known only to the
application, so the application must address any endianness issues after these types are moved to the
new platform.
8. Floating-Point Numbers BINARY_FLOAT and BINARY_DOUBLE types are transportable using Data
Pump but not the original export utility, EXP.
There is no direct way to exp/imp ASM files as transportable tablespace. However, the funcationality can
be done via RMAN.
* The tablespaces need to be in READ ONLY mode in order to successfully run a transport tablespace
export.
If you want to perform a transport tablespace operation with a strict containment check, use the
TRANSPORT_FULL_CHECK parameter:
If the tablespace set being transported is not self-contained, then the export will fail.
3. Use V$TRANSPORTABLE_PLATFORM to find the exact platform name of target database. You can
execute the following query on target platform instance:
5. Copy the generated file to target server if different from source, with ftp or cp
6. Import the transportable tablespace
* Using datapump
You can use REMAP_SCHEMA if you want to change the ownership of the transported database
objects.
If you want to transport the datafiles from ASM area to filesystem, you have finished after the above
steps. But if you want to transport tablespaces between two ASM areas you must continue.
8. Copy the datafile '/tmp/....dbf' into the ASM area using rman:
# Note down the name of the copy created in the +DGROUPA diskgroup
# ex. '+DGROUPA/s101/datafile/tts.270.5'
11. Check if datafile is indeed part of the ASM area and online:
* Using DBMS_FILE_TRANSFER
..........................
You can also use DBMS_FILE_TRANSFER to copy datafiles from one ASM disk group to another, even
on another host. Starting with 10g release 2 you can also use DBMS_FILE_TRANSFER also to copy
datafiles from ASM to filesystem and to filesystem to ASM.
This procedure reads a local file or ASM and contacts a remote database to create a copy of the file in
the remote file system. The file that is copied is the source file, and the new file that results from the copy
is the destination file. The destination file is not closed until the procedure completes successfully.
Syntax:
DBMS_FILE_TRANSFER.PUT_FILE(
source_directory_object IN VARCHAR2,
source_file_name IN VARCHAR2,
destination_directory_object IN VARCHAR2,
destination_file_name IN VARCHAR2,
destination_database IN VARCHAR2);
Where:
source_directory_object ->The directory object from which the file is copied
at the local source site. This directory object must
exist at the source site.
source_file_name ->The name of the file that is copied from the local
file system. This file must exist in the local file
system in the directory associated with the source
directory object.
destination_directory_object -> The directory object into which the file is
placed at the destination site. This directory object
must exist in the remote file system.
destination_file_name ->The name of the file placed in the remote file system
A file with the same name must not exist in the
destination directory in the remote file system.
destination_database ->The name of a database link to the remote database
to which the file is copied.
If we want to use DBMS_FILE_TRANSFER.PUT_FILE to transfer the file from source to destination host,
the steps 3,4,5 should be changed by the following.
1) Create a directory at target database host, and give permissions to local user.This is the directory
object into which the file is placed at the destination site, it must exist in the remote file system.
2) Create a directory at source database host. The directory object from which the file is copied at the
local source site. This directory object must exist at the source site.
CREATE OR REPLACE DIRECTORY source_dir AS '+DGROUPS/subdir' ;
GRANT READ,WRITE ON DIRECTORY source_dir TO "USER";
CREATE OR REPLACE DIRECTORY source_dir_1 AS '+DGROUPS/subdir/subdir_2' ;
Where target_connect is the connect string for target database and USER is the user that we are going
to use to transfer the datafiles.
CONNECT user/password@dbs1
* The tablespaces need to be in READ ONLY mode in order to successfully run a transport tablespace
export.
If you want to perform a transport tablespace operation with a strict containment check, use the
TRANSPORT_FULL_CHECK parameter:
expdp system/password DUMPFILE=expdat.dmp DIRECTORY = dpump_dir
TRANSPORT_TABLESPACES= TBS1,TBS2 TRANSPORT_FULL_CHECK=Y
If the tablespace set being transported is not self-contained then the export will fail.
4. If you see that the endian formats are different and then a conversion is necessary for transporting the
tablespace set.
* Using datapump
* Using DBMS_FILE_TRANSFER
You can also use DBMS_FILE_TRANSFER to copy datafiles to another host. You need to follow the
same steps specified above for ASM files.But if the endian formats are different then you must use the
RMAN convert after transfering the files.