Transportable tablespace system+sysaux

Hi
I want to clone a database via transportable tablepsace.I am unable to use transportable database since endian formats are not same.
I know that I cannot transport the SYSTEM and SYSUAX tablespace.
Therefore, objects such as sequences, PL/SQL packages, and other objects that depend on the SYSTEM tablespace are not transported.
What kind of additional steps do I need to perform to copy the necessary objects in SYSTEM and sysaux tablespaces to make these two database identical ?
Thanks

Hi,
after you transported the tablespaces you can use expdp and impdp for the remaining objects. Have a look at this to see how to specify the objects:
http://download.oracle.com/docs/cd/E11882_01/server.112/e16536/dp_export.htm#i1007837
Cheers
Jörg

Similar Messages

Standby not in sync because test on primary of transportable tablespace etc

This environment is new build environment , have not in use yet.
db version is 11.2.0.3 in linux, both primary/standby are configured in RAC two nodes and storage are in ASM storage.
primary db had tested by migration data using transportable tablespace methods. So the datafiles imported were put in a local filesystem which I have to switch to ASM afterwards.
In such way, the standby db got the impression that datafiles should be in local filesystem and it got invalidated.
Here is the error from standby log:
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/stage/index.341.785186191'
and datafiles names are all in local filesystem in standby: /stage/...../
However in primary datafile names are all in ASM instance:
+DAT/prd/datafile/arindex.320.788067609
How to resolve such situation?
Thanks

My steps for transportable tablespaces after scp the datafiles to linux are import the transportable datafiles into the database. and then using rman to copy it to "+DATA' in asm. and then switch dababase to copy.
Those procedure all worked on primary.
The standby was built before the transportable tablespace when there are only system, users, tools etc basic tablespaces. it worked and in sync with primary. However everytime the primary tested data migration with the transportable tablespaces, it will not work.
so what is the right way to perform this migration? how can I made standby in sync with primary and to read the datafiles in ASM storage?
Is there a way before the RMAN command to transfer the filesystem datafile to ASM, can I copy those local filesystem datafiles to ASM storage ? then do a import transportable datafiles with those on ASM?If you added any datafiles manually then those will be created in standby also as per the settings,
But here you performing TTS, of course DML/DDLs can be transfered to standby by archive logs, but what about actual datafiles? Here in this case files exist in primary & those files not exist in standby
AFAIK, you have to perform couple of steps. Once after your complete migration done in primary do as follows. (Do test it)
1) Complete your migration on primary
-- Check all data file status and location.
2) Now Restore standby controlfile & newly migrated tablespaces in standby Database
-- here you can directly restore to ASM using RMAN, because you are taking backup in primary using RMAN. So RMAN can restore them directly in ASM file system.
3) Make sure you have all the datafiles where you want and take care no one data file is missing. Crosscheck all tablespace information in primary & standby databases.
4) Now start *MRP*
Here is my above plan, But I suggest to test it...
One question, After *successful migration* are you able to SYNC standby with primary earlier ?

Transportable tablespaces for migration and upgrade

Hello All,
I'm trying to find out some theory about transportable tablespace and upgrade in a single step. I've to move a DB from a Windows server to a Linux server. Win is running 10.1 and Linux 10.2 . It's possible to use RMAN to migrate the whole database and then on new node run startup upgrade and catupgrd.sql to upgrade catalog ?
Should work?
Thanks
Raj

The following doc for TDB says :-
"Note: TDB requires the same Oracle Database software version on the source and target systems; hence, a database upgrade cannot be accomplished simultaneous with the platform migration. However, best practices for a database upgrade, as documented in the Oracle Upgrade Companion, also apply to any planned database maintenance activity, including platform migration."
http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_PlatformMigrationTDB.pdf
There is also an Oracle Whitepaper called "Database Upgrade Using Transportable Tablespaces: Oracle Database 11g Release 1" but I am still trying to find a copy.

Character set problem with transportable tablespace

Hi,
I'm trying to import a transportable tablespace with data pump into a database with a different character set compared to the source database. I know this is by default not possible. But there's no violating data in the tablespace that could make it a problem when transfering the TS. So I issued 'ALTER SYSTEM SET "_tts_allow_nchar_mismatch"=true;' on the target to force the import. However; I still get the eror:
ORA-29345: can not plug a tablespace into a database using a different character set
How can I fix this?

Hi,
What're the character sets of the source and target database?
A general restriction of transportable tablespace is that the source and target databases must use the same database character set.
Regards
Nat

Transportable tablespaces with Logical Standby

Does anyone know whether or not transportable tablespaces can be used in a Logical Standby environment? I know they can be used with a Physical Standby, and the documentation covers how to do this, but there's nothing about Logical Standby. This is Oracle 10.2.0.4/SLES 10.
Thanks.

Using transportable tablespaces to a logical standby environment. Actually, there is a paragraph in the 10.2 Data Guard Concepts and Administration manual. I will summarize:
After creating the transportable tablespace export file on the source system, copy the datafiles to both the primary and logical standby systems.
On the dataguard logical standby, within SQLplus, issue SQL> alter session disable guard;
Import the tablespaces into the logical standby database
SQL> alter session enable guard;
Import the tablespaces into the primary database.
In 10.1, we imported the tablespaces into an environment with a physical standby and then converted the physical standby to a logical standby.
I tested the procedure for 10.2 and it seemed to work. Has anyone else done this and if so, are you aware of any issues? Like I said, the documentation is one very brief paragraph.
Thanks.

TRANSPORTABLE TABLESPACE IN 8.1

제품 : ORACLE SERVER
작성날짜 : 2004-08-16
Oracle8i에서는 tablespace단위로 그 구성 datafile들을 옮겨서 다른
database에 연결시켜 사용할 수 있는 기능이 제공된다.
SCOPE
8i~10g Standard Edition 에서는 Import transportable tablespaces 기능만이 지원이 됩니다.
유용성
1. 전사적 정보시스템내에서 대량의 data의 흐름이 필요할 경우, - 예를 들어,
OLTP database에서 data warehouse database로의 data이전 또는 data
warehouse에서 data mart로의 data이전 등 - 8.1이전까지는 SQL*Loader의
direct path나 parallel DML등의 방법을 이용하여 그 작업속도를
향상시키려고 시도 하였다. 8.1의 Transportable Tablespace기능을
이용한다면 datafile들을 새로운 system으로 copy하는 정도의 시간으로
작업을 완료할 수 있다.
2. 중앙에서 변경, 관리되고 지방(지사)에서 사용되는 data들을 CD-ROM에 담아서
배포하는 등에 이용가능하다.
예를 들어, 제품의 사양, 가격등에 대한 정보를 담는 tablespace를 중앙에서
변경, 저장하여 배포하고, 이 data를 지방의 database에 연결하여 주문
system등에 이용할 수 있다.
3. Contents 사업자들은 자신이 제공하는 contents들을 Transportable
Tablespace형태로 제공 하여 고객들의 database에 바로 연결하여 사용할 수
있도록 할 수 있다.
특성, 제한사항
1. 특정 tablespace내의 전체 data를 이동시킨다.
2. Media recovery를 지원한다.
3. Source database와 target database는
- 동일한 OS에서 구동되고 있어야 한다.
- Oracle8i(8.1)이상의 version이어야 한다.
- 동일한 block size를 이용해야 한다.
- 동일한 characterset을 이용해야 한다.
작업절차
1. 대상 tablespace를 read only 상태로 변경한다.
file을 copy하는 동안 해당 tablespace에 변경작업이 일어나지 않도록
보장한다.
2. Source database에서 metadata를 export한다.
해당 tablespace와 그 안의 object들에 대한 dictionary정보를 dump file에
받는 과정이다.
3. 대상 tablespace의 datafile들을 target system으로 이동시킨다.
4. Export dump file을 이동시킨다.
5. Metadata를 target database에 import한다.
6. 필요하다면 이후에 해당 tablespace를 read-write mode로 변경한다.
SAMPLE
Source database : dbA
Target database : dbB
이동 대상 tablespace : TRANS_TS(/u01/data/trans_ts01.dbf, /u01/data/trans_ts02.dbf 로 구성)
1. dbA에서 TRANS_TS를 read only로 변경
alter tablespace TRANS_TS read only ;
2. dbA에서 metadata를 export한다.
exp sys/manager file=trans.dmp transport_tablespace=y
tablespaces=trans_ts triggers=n constraints=n
version이 8.1.6이상이라면,
exp system/manager 대신에 exp \'sys/manager as sysdba\'와 같이
주여야 한다.
transport_tablespace(Y or N)는 Y로 설정한다.
tablespaces에는 transport의 대상이 되는 tablespace를 지정한다.
대상 tablespace의 table들에 걸려있는 trigger, constraint들도 대상으로
할 것인지를 지정한다.
3. TRANS_TS의 두개의 datafile들을 dbB가 존재하는 system으로 binary
copy한다.
4. 위의 2번 과정에서 export한 dump file을 dbB가 존재하는 system으로
binary copy한다.
5. dbB에 metadata를 import한다.
imp sys/manager file=trans.dmp transport_tablespace=y
datafiles=/disk1/trans_ts01.dbf,/disk2/trans_ts02.dbf
8.1.6이상이라면 이 부분도 sys/manager대신에 \'sys/manager as dba\'
와 같이 적는다.
transport_tablespace(Y or N)는 Y로 설정한다.
datafile의 name은 dbB system에 copy된 filename을 지칭한다.
6. 필요할 경우 tablespace를 read write mode로 변경한다.
alter tablespace TRANS_TS read write ;
TRANSPORT SET
Transport하고자 하는 tablespace set은 self-contained이어야만 한다.
대상이 되는 tablespace set 내에 partitioned table이 존재한다면 해당
table의 모든 partition들이 이들 tablespace 내에 존재해야 하며, 비슷하게
LOB column의 data들도 table의 data들과 함께 이들 tablespace 내에 존재해야
하는데, 이렇게 서로 관련된 object들이 tablespace set내에 모두 존재하는
것을 self-contained라고 지칭한다.
tablespace set이 self-contained하지 않다면 transport할 수 없다.
Transport tablespace set이 self-contained인지의 여부를 확인하기 위해서
DBMS_TTS.TRANSPORT_SET_CHECK procedure를 이용한다.
예를 들어,
DBMS_TTS.TRANSPORT_SET_CHECK(ts_list=>'A,B,C',incl_constraints=>TRUE)
을 수행하면 A, B, C 세개의 tablespace로 구성된 transport tablespace set이
self-contained인지에 대한 정보를 TRANSPORT_SET_VIOLATIONS view에 기록해
준다.
incl_constraints를 설정하면 referencial(foreign key) constraint에
대해서도 self-contained 여부를 check해준다.

you can do the following:
1. export all objects in your tablespace, by using option tables=(x,y,...)
2. drop your tablespace including contents
3. create new tablespace with a desired name using the same datafiles names (you can physically delete them first or use a REUSE option)
4. create objects you exported in the new tablespace.
5. perform your import
By creating objects first, you guarantee that export will populate tables in the tablespace you need.
This is just a general plan, you have to clarify and confirm all details.

Error in Transport Tablespace from linux to windows

I am testing the cross-Platform Transport Tablespace. As per the oracle, we can transport tablespace from linux to windows without conversion because both are using same endian (Little).
But i am fail to do Transport Tablespace from Linux to Windows.
I am performing Transport Tablespace process as following:
from Source Oracle Database server(red had linux as 4 32-bit oracle version:10.2)
Sql> alter tablespace TEST read only;
$ expdp system/pass dumpfile=test.dmp directory=export_dir transport_tablespaces=test transport_full_check=y
after this i am coping test.dmp and data file (test.dbf) to the target machine (ms windows xp 32-bit with oracle 10.1) .
on Target Machine (with Ms windows xp os) here i am giving the following command:
impdp system dumpfile=test.dmp directory=exp_dir transport_datafiles=/exp_dir/test.dbf
but it is giving following error:
ora-39001: invalid argument value
ora-39000: bad dump file specification
ora-31619: invalid dump file "c:\pks\1103.dmp"
what may by ...
Prabhaker

now for version compatibility i am inclusding version option with expdp
edpdp scott dumpfile=1103.dmp directory=pks transport_tablespaces=prabhu version=10.1.0.2.0
but now it is giving following error:
Import: Release 10.1.0.2.0 - Production on Saturday, 11 March, 2006 19:07
Copyright (c) 2003, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
Master table "SCOTT"."SYS_IMPORT_TRANSPORTABLE_01" successfully loaded/unloaded
Starting "SCOTT"."SYS_IMPORT_TRANSPORTABLE_01": scott/******** DUMPFILE=1103.DMP DIRECTORY=PKS TRANSPORT_DATAFILES=C:\PKS\PRABHU version=10.1.0
Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK
ORA-39123: Data Pump transportable tablespace job aborted
ORA-06550: line 2, column 2:
PLS-00306: wrong number or types of arguments in call to 'BEGINIMPORT'
ORA-06550: line 2, column 2:
PL/SQL: Statement ignored
Job "SCOTT"."SYS_IMPORT_TRANSPORTABLE_01" stopped due to fatal error at 19:07
regards
Prabhu

Run transportable tablespace

Hi;
I have a file system database on linux which is 10g.I want to transport this database to new host asm on 11g.
I am unable to use transportable database since the endian formats are different. I want to use transportable tablespace feature with rman.
The database is pretty big. I dont have enough space to do the conversion on the source database.
If I ship the backup of the database to new host, can I do the conversion on new host ?
ie:
run {
allocate channel t1 type 'SBT_TAPE';
transport tablespace "USERS"
Tablespace destination '/ora_backup/tts'
Auxiliary destination '/ora_backup/tts'
Datapump directory data_pump_dir
dump file 'tts_test.dmp'
Import script 'tts_test.imp'
Export log 'exp_tts_test.log'

Ricardo,
I had given you a link in the other thread of yours. Did you see it? If not , please do. You can do the conversion either on the source or you can ship the files on the target host and can convert there as well. Please see the link since it covers it completely.
Aman....

Transport tablespace

I have to transport a tablespace from 9i to 10g with same database character-set. Is it possible ?
Pls. suggest some good document.

I have to transport a tablespace from 9i to 10g with same database character-set. Is it possible ?Yes, you can take it from 9i to 10g. The only thing you have to watch out for is that are these two going to be on the same operating system - if not what is the 9i operating system and what is the 10g operating system. Remember between some of the operating systems you cannot use transport tablespaces. Use:
SQL> COLUMN PLATFORM_NAME FORMAT A32
SQL> SELECT * FROM V$TRANSPORTABLE_PLATFORM;
to see if the Endian formats match for the two operating systems. Please note again, this is for case where the 9i and the 10g will be in separate operating systems.
Hope this helps.

Transport Tablespace Issues

hi.. i'm trying to use transport tablespace across the same platforms rather than performing export/import . i'm following the steps in Note:371556.1to exp/imp ASM files.
i have finished all the steps and successfully transport the tablespace. this process involved only 2 TBS, CC_DATA and CC_INDEXES and the schema is CC. i choose to check the full containment before the export done. but when i count the objects before export and after the import, the count is different. the question is how to make the count of objects is same before and after transport.
before export
SQL> select count(*), object_type from user_objects group by object_type;
COUNT(*) OBJECT_TYPE
33 SEQUENCE
3 DATABASE LINK
55 TABLE
82 INDEX
19 SYNONYM
39 VIEW
6 rows selected.
after import
SQL> select count(*), object_type from user_objects group by object_type;
COUNT(*) OBJECT_TYPE
82 INDEX
55 TABLE
thanks in advance.
-julie-
Edited by: gunit on Nov 17, 2008 7:35 PM

It's a limitation on transportable tablespace (http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#i1007233)
You cannot transport the SYSTEM tablespace or objects owned by the user SYS. Some examples of such objects are PL/SQL, Java classes, callouts, views, synonyms, users, privileges, dimensions, directories, and sequences.So you need to transfer the views, sequences,etc., one method is using exp/imp.
[source]$ exp cc/<pwd> file=cc.dmp rows=no
[target]$ imp cc/<pwd> file=cc.dmp ignore=yes HTH
Enrique

Transportable Tablespace Importing - Failed to read stderr from process

Hello,
I'm using the normal EM console packaged with Oracle (10gR2) and am trying to import a tablespace on RedHat rel4.
I follow the Transport Tablespaces link on the maintenance tab and get the option of export or import and also the place to put the host credentials in. I select import, enter the credentials and click continue and am given this error: Failed to read stderr from process.
I've tried logging into EM as SYSTEM, SYS, and a DBA account I use and have used both root and the oracle account with no luck.
Searching hasn't gotten me any useful results here or in metalink so I'm stuck. What am I missing?
Thanks

Thank you thank you!
The short version is I traced it back to an error with /bin/nmo which traced back to a failure to run root.sh when upgrading to 10.2.0.3.
Thanks again!

Transportable tablespaces requirment

Hello All,
This is what I am running on.
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production
We have datawarehouse env. and we are thinking of doing transportable tablespace. From what I understand when you do transportable tablespace the block size have to be the same and NLS_chracater? I am sure there are more requirments that I am not aware of. Please if you have a helpful link please let me know. My question is what are the requirments for transportable tablespace?
Thanks in advance

http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#sthref1288
OR
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#i1007169

Transport Tablespace export error.

Hello to All.
Oracle Version : 9.2.0.1
Operating System : Windows XP
Sir.
On testing to export a transportable tables space I got the following errors. I am unable to understand the cause of errors. Please guide
The command fired and errors are :
Before this I have made the tablespace users read only by this command :;
sql> alter tablespace users read only;
Tablespace Altered
C:\Documents and Settings\admin>exp \"sys/oracle as sysdba\" transport_tablespace=Y tablespaces=users log=ts_users.log
Export: Release 9.2.0.1.0 - Production on Fri Oct 3 20:23:09 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
Note: table data (rows) will not be exported
About to export transportable tablespace metadata...
EXP-00008: ORACLE error 1001 encountered
ORA-01001: invalid cursor
ORA-06512: at "SYS.DBMS_SYS_SQL", line 819
ORA-06512: at "SYS.DBMS_SQL", line 19
ORA-06512: at "SYS.DBMS_TTS", line 774
ORA-25153: Temporary Tablespace is Empty
ORA-06512: at "SYS.DBMS_PLUGTS", line 1093
ORA-06512: at line 1
EXP-00000: Export terminated unsuccessfully
thanks and regards
Neeraj
Edited by: ora-boy on Oct 3, 2008 8:05 AM
Edited by: ora-boy on Oct 3, 2008 8:06 AM

EXTREMELY sorry for this type of silly blunder.
now the result is
PL/SQL procedure successfully completed.
SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;
VIOLATIONS
Default Partition (Table) Tablespace SYSTEM for EMP1 not contained in transportable set
Default Partition (Table) Tablespace SYSTEM for EMP1 not contained in transportable set
Default Partition (Table) Tablespace SYSTEM for EMP1 not contained in transportable set
Default Partition (Table) Tablespace USERS for EMP1 not contained in transportable set
Default Partition (Table) Tablespace USERS for EMP1 not contained in transportable set
Default Partition (Table) Tablespace USERS for EMP1 not contained in transportable set
6 rows selected.
but I am unable to understand this.
thanks

Rman transportable tablespace ORA-39087: directory name is invalid

Hello all,
We are trying to restore a backup of a tablepace using RMAN's TRANSPORTABLE TABLESPACE command. I created the director in oracle (and it exists on the server), granted privs yet it fails with ORA-39087: directory name is invalid. It seems to fail at the end. Here's my steps, does anyone know how to fix? Thanks in advance for your time!
Dave
CREATE DIRECTORY ARCH_DIR as '/opt/oracle/arch';
GRANT IMP_FULL_DB, EXP_FULL_DB TO SYS, RMAN, SYSTEM;
GRANT READ, WRITE ON DIRECTORY ARCH_DIR TO SYS, RMAN, SYSTEM;
export ORACLE_SID=ADMIN_P1
rman target / catalog rman/rmanpassword@mydb
TRANSPORT TABLESPACE REPORTER
TABLESPACE DESTINATION '/opt/oracle/arch'
AUXILIARY DESTINATION '/opt/oracle/arch'
UNTIL SCN 2144439724
DATAPUMP DIRECTORY ARCH_DIR
DUMP FILE 'reporter.dmp'
IMPORT SCRIPT 'reporter.imp'
EXPORT LOG 'reporter.log';

Creating a directory object inside the database does not create anything in the operating system. My guess is that the physical directory, with appropriate permissions, does not exist.

Why transportable tablespace for platform migration of same endian format?

RDBMS Version : 10.2.0.4
We are planning to migrate our DB to a different platform. Both platforms are of BIG endian format. From googling , I came across the following link
http://levipereira.files.wordpress.com/2011/01/oracle_generic_migration_version_1.pdf
In this IBM document, they are migrating from Solaris 5.9 (SPARC) to AIX 6 . Both are of BIG endian format.Since they both are of same endian format can't they use TRANSPORTABLE DATABASE ? Why are they using RMAN COVERT DATAFILE (Transportable tablespace ) ?

In this IBM document, they are migrating from Solaris 5.9 (SPARC) to AIX 6 . Both are of BIG endian format.Since they both are of same endian format can't they use TRANSPORTABLE DATABASE ? Why are they using RMAN COVERT DATAFILE (Transportable tablespace ) ?they are using transportable database - they are not importing data to dictionary, not creating users... - instead of using convert database, they used convert datafile to avoid of converting all datafiles (you need to convert only undo + system tablespace) - there's MOS note: Avoid Datafile Conversion during Transportable Database [ID 732053.1].
Basic steps for convert database:
1. Verify the prerequisites
2. Identify any external files and directories with DBMS_TDB.CHECK_EXTERNAL.
3. Shutdown (consistent) and restart the source database in READ ONLY mode.
4. Use DBMS_TDB.CHECK_DB to make sure the database is ready to be transported.
5. Run the RMAN convert database command.
6. Copy the converted files to the target database. Note that this implies that you will need 2x the storage on the source database for the converted files.
7. Copy the parameter file to the target database.
8. Adjust configuration files as required (parameter, listener.ora, tnsnames, etc).
9. Fire up the new database!
All other details are in:
http://docs.oracle.com/cd/B19306_01/backup.102/b14191/dbxptrn.htm#CHDFHBFI
Lukas

Transportable tablespace system+sysaux

Similar Messages

Maybe you are looking for