Beruflich Dokumente
Kultur Dokumente
EXPDP commands. You need to put the source tablespace in READ ONLY MODE and export the metadata.
Source Tablespace must be in read only mode until to complete the process. The EXP/IMP utilities
are used to copy the metadata for the objects residing in the transported tablespaces, and ordinary
file copy commands like cp or scp are used to copy the actual data files.
From 10g, transportation of tablespaces between databases running on different OS platforms such
as (Windows to Linux) - which has same ENDIAN formats. If ENDIAN formats are different we have to
use RMAN.
CHECK PLATFORM SUPPORT AND FILE CONVERSION REQUIREMENT
On the source database & Target database
SQL> SELECT A.platform_id, A.platform_name, B.endian_format
FROM
v$database A,
WHERE
A.platform_id = B.platform_id;
PLATFORM_ID
v$transportable_platform B
PLATFORM_NAME
ENDIAN_FORMAT
Linux IA (32-bit)
Little;
Usually ENDIAN_FORMAT shows either Big, Little or will be blank. A blank indicates that the
platform is NOT supported for cross-platform. If the source & target platform have the same endian
format, then file conversion is NOT necessary. If the endian formats differ, however then file
conversion is required.
Conversion produces output files in the correct format for use on the destination platform, but
does NOT alter the contents of the source datafiles. We can query the V$TRANSPORTABLE_PLATFORM
view to see the platforms that are supported, and to determine each platform's endian format.
SQL> select * from V$TRANSPORTABLE_PLATFORM;
PLATFORM_ID
PLATFORM_NAME
ENDIAN_FORMAT
------------
---------------------------
Solaris[tm] OE (32-bit)
Big
Solaris[tm] OE (64-bit)
Big
Little
10
Linux IA (32-bit)
Little
Big
HP-UX (64-bit)
Big
HP Tru64 UNIX
Little
HP-UX IA (64-bit)
Big
11
Linux IA (64-bit)
Little
15
HP Open VMS
Little
Little
Big
------------------
..
...
Endian format describes the order in which a processor architecture natively places bytes in
memory, a CPU register, or a file.
low-order byte and work their way up while some others start with the high-order byte and work
their way down).
To transport a tablespace from one platform to another, datafiles on different platforms must be
in the same endian format (Byte ordering). Big endian and little endian. Big endian means the most
significant byte comes first, and little endian means the least significant byte comes first.
As you see in this article I explain Transportable Tablespace across two databases running on same
version of database and operating systems. Both databases are within the list of platforms in
v$trasportable_platform. Both platforms are with the same byte ordering.
STEPS FOR TRANSPORTABLE TABLESPACES
Following steps must be done on the source database.
1. Validate the tablespace is self-contained.
2. Make the migration tablespace to Read only mode.
3. Export the metadata of the source tablespace.
4. Copy the datafiles to the target server.
5. Perform the tablespace import.
System, undo, sysaux and temporary tablespaces can NOT be transported. We can transport one or
more tablespaces at a time. You cannot transport part of a tablespace.
TTS requires source tablespace must be SELF CONTAINED means Objects in the tablespace set cannot
reference or depend on objects that reside outside of the tablespace.
To find out if a tablespace set is self-contained execute the TRANSPORT_SET_CHECK procedure as SYS
user, which is in the DBMS_TTS package.
SYS> execute sys.dbms_tts.transport_set_check('tbs1', true);
Next query the transport_set_violations view.
SQL> select * from sys.transport_set_violations;
If we get any output other than no rows selected then we can NOT export the source tablespace,
we need to go through that output and we should take appropriate actions.
Which tablespace(s) you wish to transport should be self contained, it means should not contain
any objects that depend on objects outside the tablespaces.
Some examples of self-containment issues are,
1) An index inside the tablespace for a table but the table is in another tablespace.
2) A table containing LOB columns that either reference or utilize another tablespace not in the
export set. Ex: LOB storage.
3) A partitioned object only partially contained within the tablespace (one or more partitions
outside the set). I.e. objects partitions and/or sub-partitions span tablespaces.
4) A table in the transported tablespace set with a foreign key constraint that references a table
outside the tablespace set.
Prior to attempt to export need to ensure self-contained set of objects for transport Lets see
perfect example below.
A table (tab5) in the BPMS TABLESPACE had an index(indx1) in the USERS TABLESPACE, then transporting
the USERS tablespaces (without the CRMS tablespace) would present a problem. When the USERS
tablespace is transported into the target database, there would be an index on a non-exist table.
We can transport a table without its indexes but cannot transport an index without its table.
Oracle will not allow this and will point out the problem.
You can see as I tried to transport users tablespace independently but it would fail since it
contains index (indx1) for table(tab5) which is in BPMS tablespace. Finally both the tablespaces
(BPMS & USERS) can be transported together.
SQL> execute sys.dbms_tts.transport_set_check('users, bpms', true);
PL/SQL procedure successfully completed.
SQL> select * from sys.transport_set_violations;
no rows selected
where username='ROSE';
DEFAULT_TABLESPACE
TEMPORARY_TABLESPACE
------------------------------ -----------------------------TBS1
TEMP
TABTYPE
CLUSTERID
TABLE
EMP
TABLE
PAYROLL
TABLE
TABLESPACE_NAME
------------------------------ -----------------------------EMP
TBS1
DEPT
TBS1
PAYROLL
TBS1
TABLE_NAME
------------------------------ ----------
TABLESPACE_NAME
--------------------
PAYROLL_SALARY_INDX4
PAYROLL
TBS2
CONS6_PKEY
PAYROLL
TBS1
EMP_NAME_INDX2
EMP
TBS2
EMP_GENDER_INDX1
EMP
TBS2
CONS1_PKEY
EMP
TBS1
CONS3_UNIQ
EMP
TBS1
CONS4_UNIQ
EMP
TBS1
DEPT_DNAME_INDX3
DEPT
TBS2
CONS5_PKEY
DEPT
TBS1
9 rows selected.
C VALIDATED
TABLE_NAME
P VALIDATED
PAYROLL
CONS4_UNIQ
U VALIDATED
EMP
CONS5_PKEY
P VALIDATED
DEPT
CONS3_UNIQ
U VALIDATED
EMP
CONS1_PKEY
P VALIDATED
EMP
CONS2_NOTNULL
C VALIDATED
EMP
6 rows selected.
COLLECTING ALL OBJECT DETAILS IN ROSE SCHEMA.
SYS> SELECT
FROM
dba_segments
WHERE
owner = 'ROSE'
ORDER BY 1, 2 DESC;
TABLESPACE_NAME
SEGMENT_TYPE
COUNT(*)
MB
TABLE
1875
TBS1
INDEX
3125
TBS2
INDEX
25.2
I am finding on the source database self-containment problems. You can see some violations at the
result of query so TBS2 is NOT self-contained tablespace.
FROM
dba_tables A, dba_tab_columns B
WHERE A.tablespace_name=TBS1
AND
B.owner = A.owner
AND
B.table_name = A.table_name
GROUP BY B.data_type
ORDER BY B.data_type;
DATA_TYPE
---------
COUNT(*)
-----------
DATE
NUMBER
VARCHAR2
11
Transportable tablespace feature does NOT support some data type for transporting (raw, long raw,
bfile, etc. In our case no problem with data types.
CHECKING ALL SCHEMAS WITH ASSOCIATED TABLESPACE
First we need to check the source database what schemas own objects in the tablespaces. What
schemas will be required on the target database and create them if they dont exist
SYS> SELECT owner, COUNT(*) FROM
2
OWNER
WHERE
dba_segments
COUNT(*)
------- -------ROSE
12
In our case we have only one schema and name is rose in source database. We also need to rename
tablespaces or schema objects on either the source or target database if there are duplications.
TARGET DATABASE
SYS> select username from dba_users where username='ROSE';
no rows selected
In our case there is no schema ROSE in target database. So we need to create required schema on
the target database. Create the ROSE user and assign appropriate privileges. Note that TTS only
imports tables, indexes and associated triggers. You need to have pre-created schema.
TABLESPACE_NAME
STATUS
------------------------------ --------TBS1
READ ONLY
TBS2
READ ONLY
EMP
. . exporting table
DEPT
. . exporting table
PAYROLL
3 12:15 /u02/app/oracle/oradata/hrms/tbs1_01.dbf
-rw-r-----
3 12:15 /u02/app/oracle/oradata/hrms/tbs1_02.dbf
-rw-r-----
3 12:15 /u02/app/oracle/oradata/hrms/tbs2_01.dbf
-rw-r-----
3 12:15 /u02/app/oracle/oradata/hrms/tbs2_02.dbf
$ export ORACLE_SID=hrms
$ imp file=tts_exp.dmp
log=tts_imp.log
TRANSPORT_TABLESPACE=Y
TABLESPACES='TBS1,TBS2'
datafiles=/u02/app/oracle/oradata/hrms/tbs1_01.dbf,
/u02/app/oracle/oradata/hrms/tbs1_02.dbf,
/u02/app/oracle/oradata/hrms/tbs2_01.dbf,
/u02/app/oracle/oradata/hrms/tbs2_02.dbf
Import: Release 11.2.0.1.0 - Production on Fri Apr 3 12:40:44 2015
Copyright (c) 1982, 2009, Oracle and/or its affiliates.
Username: / as sysdba
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export file created by EXPORT:V11.02.00 via conventional path
About to import transportable tablespace(s) metadata...
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses WE8MSWIN1252 character set (possible charset conversion)
. importing SYS's objects into SYS
. importing SYS's objects into SYS
. importing ROSE's objects into ROSE
. . importing table
"EMP"
. . importing table
"DEPT"
. . importing table
"PAYROLL"
SYSTEM
NO
SYSAUX
NO
UNDOTBS1
NO
TEMP
NO
USERS
NO
HRMS
YES
TBS2
NO
BPMS
YES
TBS1
10 rows selected.
SYS> conn rose/rose
Connected.
ROSE> select * from tab;
TNAME
TABTYPE
CLUSTERID
TABLE
EMP
TABLE
PAYROLL
TABLE