Transportable Tablespace

Hi Guys, Now I will give example how to transport one tablespace. I will use two databases. [oracle@papa ~]$ export ORACLE_SID=catprod [oracle@papa ~]$ sqlplus / as sysdba CAT> [oracle@papa ~]$ export ORACLE_SID=proddb [oracle@papa ~]$ sqlplus / as sysdba PRODDB> Let's create a directory: [oracle@papa ~]$ cd /u01 [oracle@papa u01]$ mkdir tsprod tscat Checking my database listener, the both database listener must be working. [oracle@papa u01]$ lsnrctl status [oracle@papa u01]$ lsnrctl start In PRODDB let's create a tablespace. PRODDB>CREATE TABLESPACE PAPATS DATAFILE '/u01/app/oracle/oradata/proddb/papats.dbf' SIZE 20M; Tablespace created. PRODDB> CREATE USER PAPA IDENTIFIED BY PAPA DEFAULT TABLESPACE PAPATS QUOTA UNLIMITED ON PAPATS User created. PRODDB>GRANT RESOURCE, CONNECT TO PAPA; Grant succeeded. PRODDB>CONN PAPA/PAPA Connected. PRODDB>CREATE TABLE PAPA AS SELECT * FROM ALL_OBJECTS; Table created.

Ok, now PRODDB it's prepared, but we need to check some points to be sure that we can transport the tablespace, of course I will not have any problem because I will not make a Cross Platform, but it's important to know that ENDIAN_FORMAT must be the same between the databases. PRODDB>SELECT * FROM V$TRANSPORTABLE_PLATFORM; PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT ----------- ------------------------------------------------ -------------1 Solaris[tm] OE (32-bit) Big 2 Solaris[tm] OE (64-bit) Big 7 Microsoft Windows IA (32-bit) Little 10 Linux IA (32-bit) Little 6 AIX-Based Systems (64-bit) Big 3 HP-UX (64-bit) Big 5 HP Tru64 UNIX Little 4 HP-UX IA (64-bit) Big 11 Linux IA (64-bit) Little 15 HP Open VMS Little 8 Microsoft Windows IA (64-bit) Little PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT ----------- ------------------------------------------------ -------------9 IBM zSeries Based Linux Big 13 Linux 64-bit for AMD Little 16 Apple Mac OS Big 12 Microsoft Windows 64-bit for AMD Little 17 Solaris Operating System (x86) Little 18 IBM Power Based Linux Big 17 rows selected. Let's check our CHARACTER SET: PRODDB>SELECT * FROM NLS_DATABASE_PARAMETERS; PARAMETER VALUE ------------------------------ ---------------------------------------NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CHARACTERSET WE8ISO8859P1 NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD-MON-RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMAT HH.MI.SSXFF AM PARAMETER VALUE ------------------------------ ----------------------------------------

NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY $ NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_RDBMS_VERSION 10.2.0.1.0 20 rows selected. Ok let's check in my CAT database: CAT>SELECT * FROM NLS_DATABASE_PARAMETERS; PARAMETER VALUE ------------------------------ ---------------------------------------NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CHARACTERSET WE8ISO8859P1 NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD-MON-RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMAT HH.MI.SSXFF AM PARAMETER VALUE ------------------------------ ---------------------------------------NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY $ NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_RDBMS_VERSION 10.2.0.1.0 20 rows selected. Perfect is the same, if your database CHARACTER SET it's different you should change, but please always check if is possible or not, for more information how to change your CHARACTER SET click here. Oracle gave to us a packege that you can check if your tablespace is transportable or not, and this package is DBMS_TTS.TRANSPORT_SET_CHECK, to check you should do this: PRODDB>EXEC DBMS_TTS.TRANSPORT_SET_CHECK(ts_list => 'PAPATS' ,

incl_constraints => TRUE); PL/SQL procedure successfully completed. This Package will populate the table transport_set_violations, and after execute the package you should check it: PRODDB>SELECT * FROM transport_set_violations; no rows selected If didn't show any rows to you it's because your tablespace it's transportable and you can proceed. Let's create a directory and make de export. PRODDB>CREATE OR REPLACE DIRECTORY DICPAPA AS '/u01/tsprod/'; Directory created. We should put the tablespace in read only mode. PRODDB>ALTER TABLESPACE PAPATS READ ONLY; Tablespace altered. Let's export as sysdba. [oracle@papa ~]$ expdp directory=dicpapa dumpfile=transpapa.dmp transport_tablespaces='PAPATS' Export: Release 10.2.0.1.0 - Production on Monday, 01 August, 2011 10:53:00 Copyright (c) 2003, 2005, Oracle. All rights reserved. Username: sys as sysdba Password: Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options Starting "SYS"."SYS_EXPORT_TRANSPORTABLE_01": sys/******** AS SYSDBA directory=dicpapa dumpfile=transpapa.dmp transport_tablespaces=PAPATS Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK Processing object type TRANSPORTABLE_EXPORT/TABLE Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK Master table "SYS"."SYS_EXPORT_TRANSPORTABLE_01" successfully loaded/unloaded ****************************************************************************** Dump file set for SYS.SYS_EXPORT_TRANSPORTABLE_01 is:

/u01/tsprod/transpapa.dmp Job "SYS"."SYS_EXPORT_TRANSPORTABLE_01" successfully completed at 10:53:19 Well to import now we can make a copy of datafile to your location, you can chose the location. [oracle@papa proddb]$ cp papats.dbf /u01/tscat/ PRODDB> ALTER TABLESPACE PAPATS READ WRITE Tablespace altered. I don't have anything to do with PRODDB now, so let's go to CAT> CAT>CREATE OR REPLACE DIRECTORY DICPAPA AS '/u01/tscat/'; Directory created. CAT>GRANT RESOURCE,CONNECT TO ITC IDENTIFIED BY ITC; Grant succeeded. Well now my CAT> it's prepared to receive the tablespace. [oracle@papa ~]$ impdp DIRECTORY=dicpapa DUMPFILE=transpapa.dmp TRANSPORT_DATAFILES=/u01/tscat/papats.dbf REMAP_SCHEMA=PAPA:ITC Import: Release 10.2.0.1.0 - Production on Monday, 01 August, 2011 11:14:26 Copyright (c) 2003, 2005, Oracle. All rights reserved. Username: sys as sysdba Password: Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options Master table "SYS"."SYS_IMPORT_TRANSPORTABLE_01" successfully loaded/unloaded Starting "SYS"."SYS_IMPORT_TRANSPORTABLE_01": sys/******** AS SYSDBA DIRECTORY=dicpapa DUMPFILE=transpapa.dmp TRANSPORT_DATAFILES=/u01/tscat/papats.dbf REMAP_SCHEMA=PAPA:ITC Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK Processing object type TRANSPORTABLE_EXPORT/TABLE Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK Job "SYS"."SYS_IMPORT_TRANSPORTABLE_01" successfully completed at 11:14:33 If you look to the impdp you will see that I used REMAP_SCHEMA, it's to show that you can move objects from PAPA user to ITC user in the transportable process too, it's like this: "ORACLE Says> Oh this owner is PAPA but I don't have him here so I will put ITC as owner now because DBA authorized me. hehehe"

CAT>conn itc/itc Connected. CAT>select * from tab; TNAME TABTYPE CLUSTERID ------------------------------ ------- ---------PAPA TABLE CAT>SELECT COUNT(*) FROM PAPA; COUNT(*) ---------40688 Done.

Limitations on Transportable Tablespace Use

Be aware of the following limitations as you plan to transport tablespaces: The source and target database must use the same character set and national character set. 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. 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. Encrypted tablespaces have the following the limitations: Before transporting an encrypted tablespace, you must copy the Oracle wallet manually to the destination database, unless the master encryption key is stored in a Hardware Security Module (HSM) device instead of an Oracle wallet. When copying the wallet, the wallet password remains the same in the destination database. However, it is recommended that you change the password on the destination database so that each database has its own wallet password. See Oracle Database Advanced Security Administrator's Guide for information about HSM devices, about determining the location of the Oracle wallet, and about changing the wallet password with Oracle Wallet Manager. You cannot transport an encrypted tablespace to a database that already has an Oracle wallet for transparent data encryption. In this case, you must use Oracle Data Pump to export the tablespace's schema objects and then import them to the destination database. You can optionally take advantage of Oracle Data Pump features that enable you to maintain encryption for the data while it is being exported and imported. See Oracle Database Utilities for more information. You cannot transport an encrypted tablespace to a platform with different endianness. Tablespaces that do not use block encryption but that contain tables with encrypted columns cannot be transported. You must use Oracle Data Pump to export and import the tablespace's schema objects. You can take advantage of Oracle Data Pump features that enable you to

maintain encryption for the data while it is being exported and imported. See Oracle Database Utilities for more information. Beginning with Oracle Database 10g Release 2, you can transport tablespaces that contain XMLTypes. Beginning with Oracle Database 11g Release 1, you must use only Data Pump to export and import the tablespace metadata for tablespaces that contain XMLTypes. 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

See Oracle XML DB Developer's Guide for information on XMLTypes. Transporting tablespaces with XMLTypes has the following limitations: The target database must have XML DB installed. Schemas referenced by XMLType tables cannot be the XML DB standard schemas. Schemas referenced by XMLType tables cannot have cyclic dependencies. XMLType tables with row level security are not supported, because they cannot be exported or imported. If the schema for a transported XMLType table is not present in the target database, it is imported and registered. If the schema already exists in the target database, an error is returned unless the ignore=y option is set. If an XMLType table uses a schema that is dependent on another schema, the schema that is depended on is not exported. The import succeeds only if that schema is already in the target database.