Transport tablespace from raw to cooked

Hi
I have a tablespace which contains raw devices
What is the best way to copy this tablespace to some other database which has filesystem rather than raw devices?
Both hosts and destinations are Oracle 9.2.0.6.0 on hp unix

Hi,
How about ftp, scp if they have fast network connectity
else tape drive.
and you would to use dd in on the source side to convert it from raw device to cooked file system at source or directly at the target.
I suppose you have different question if yes then please elaborate.
Regards
Anurag

Similar Messages

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

Transport Tablespace from Physical Standby in Oracle 10gr2 - 64 Bit

Hi,
How to Export Transport Tablespaces from Physical Standby Server - Oracle 10gr2 EE in Windows 2003 EE, Since Production Servers are in 24*7 Support to avoid make Read Only Tablespaces.
Regards
Harish

Open your Physical Standby in read only mode and do your export. Then mount it back in managed recovery mode.

Dbid in transportable tablespaces

Is it necessary to have same DBID for rman transportable tablesapace or for normal exp/imp transportable tablespace ?

Pascal Nouma wrote:
Hi Kamran
Someone in database general forum posted that, dbid is essential. Is he wrong?
transport tablespace from raw to cooked
I forget to mark question as resolved sorry about thatI don't like to say someone's answer that it's "right" or "wrong". But according to Oracle documentation, there's no any need for two databases to have same dbid to transport tablespace between them. Generally, database's have different unique DBID which make them different from others. So if you have two databases which runs on Linux and Windows OS and you want to transport a tablespace between them, you don't need to changed dbid of one of them.
Moreover, you can refer to documentation: [Limitations on Transportable Tablespace Use|http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/tspaces013.htm#i1007233]

Transport Tablespace using RMAN from 10.2.0.2 to 10.2.0.3 ??

Hello all,
Is it possible to do RMAN Transport Tablespace from 10.2.0.2 to 10.2.0.3 ??
TIA,
J J

Are the two database on same platform?
Yes, it's possible to move from 10.2.0.2 to 10.2.0.3
You should check Oracle document,
You cannot export transportable tablespaces and then import them into a database at a lower release level. The target database must be at the same or higher release level as the source database.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14215/dp_export.htm#i1006840

Transportable tablespace Windows to Linux different character sets

Hi,
Is it absolutely necessary to have the same character set when doing a cross platform transport tablespace from Windows to Linux? We are trying to do it on Oracle10gR2 from Windows to Linux.
Thank you.

Hi, yes is necessary that your databases have the same chracter set, please review the limitations into the Note:291024.1.
Luck.
Have a good day.
Regards.

Export hangs while transporting tablespace..

Hello,
I have a database running on Win2000. The host is a small machine. I am trying to transport tablespaces from one database to another. I have already checked to make sure that all the data is contained completely within the tablespace. I have already declared the tablespace readonly. When I issue "exp transport_tablespace=y tablespaces=MINE grants=y triggers=y constraints=y file=c:\exp.dmp" it seems to start out fine because I see a lot of disk reads. After a while it just seems to stop..I don't see any activity at all. Any ideas?
Thanks.

Hi
Maybe is performing some CPU work, what is the size of tablespace? Did you check the task manager and CPU usage?
A10!
null

Transportable tablespace accross different oracle versions

Hi
Do I need same oracle versions if I want to transport tablespaces ?
i.e Can I transport tablespaces from oracle9i to oracle 11g ? or from oracle 10g to oracle 11g ?
I read the documents however Im still confused.

Thanks, I have read the document and notice that from oracle 10g and onwards I can transport tablespaces accross different oracle versions.
I think we can change the endian format via rman hence no need to have same endian format
"Beginning with the Oracle10g database, a tablespace can always be transported to a database with the same or higher compatibility setting, whether the target database is on the same or a different platform."

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!

Expdp problem when executing from pl/sql transportable tablespaces

Hello
i have a very strange problem for which your assistance is really appreciated. i am applying the transportable tablespaces approach and i have a problem when executing expdp from commandline in comparison to the procedure generated to make the exact same thing.
more precisely when running:
expdp etl/etl dumpfile=TBSP090609_DMP.dmp logfile=TBSP090609_DMP.log directory=EXPDP transport_tablespaces=TBSP090609 transport_full_check=y
the dmp file produced is over 200MB.
when runng the below pl/sql code the volume produced is around 50MB. any idea what i am missing?
job_handle :=
dbms_datapump.OPEN (operation => 'EXPORT',
job_mode => 'TRANSPORTABLE',
job_name => 'export_tablespace',
VERSION => 'COMPATIBLE'
dbms_datapump.add_file (handle => job_handle,
filename => dump_file_name,
DIRECTORY => export_dir_name
dbms_datapump.set_parameter (handle => job_handle,
NAME => 'TTS_FULL_CHECK',
VALUE => 1
dbms_datapump.metadata_filter (handle => job_handle,
NAME => 'TABLESPACE_LIST',
VALUE => '('''
|| tablespace_name
|| ''')'
dbms_datapump.start_job (job_handle);

thanx you for your response. the problem was eventually managed to be resolved as follows:
job_handle :=
dbms_datapump.OPEN (operation => 'EXPORT',
job_mode => 'TRANSPORTABLE',
job_name => 'export_tablespace',
VERSION => 'COMPATIBLE'
dbms_datapump.add_file (handle => job_handle,
filename => dump_file_name,
DIRECTORY => export_dir_name
dbms_datapump.set_parameter (handle => job_handle,
NAME => 'TTS_FULL_CHECK',
VALUE => 1
dbms_datapump.metadata_filter (handle => job_handle,
NAME => 'TABLESPACE_EXPR',
VALUE => 'IN('''
|| tablespace_name
|| ''')');
dbms_datapump.start_job (job_handle);

Transportable Tablespace in ASM

Hi all,
I want to move one tablespace from a database to another database using the 10g cross platform transportable tablespace.
My source database is running on Linux 32 bit (Little endian format) and the target database is running on AIX (Big endian format). However both databases use the ASM diskgroup as a storage option.
Do I need to convert the endian format of the source tablespace datafile to transport to the target database?
Thanks,

Because ASM diskgroup consists of one or more raw
partitions or raw devices, I am wondersing if I still
have to convert the endian format of datafiles..Interesting question.
As you said earlier:
- Linux natively uses Little endian
- AIX natively uses Big endian
You imply that perhaps Linux's ASM 'converts' to an 'Oracle neutral-endian' format whenever something is stored in the ASM disk group. Which would make it identical to AIX's ASM format, also 'converted'.
(I use 'convert' in quotes, as one or the other would not need to get switched, if a specific endian form is maintained.)
Worth investigating further. Although I am not sure why Oracle would introduce the overhead of conversion to-and-from every storage call.

Steps to create Cross-Platform Transportable Tablespaces

hi
what is the steps to do Cross-Platform Transportable Tablespaces.
i want to perform this in my pc, i have linux and windows in same PC, i want to migrate from linux to windows and vice versa.
so can i know complete steps and commands to perform Cross-Platform Transportable Tablespaces. to get complete knowledge i am doing this so i can implement this in my office when any migrate issues comes. so once i do this i will get confidence so that i can do the same in my office which saves my time.
veeresh s
oracle-dba
[email protected]

Hi, also you can review the Note:413586.1 into metalink site.
Good luck.
Regards.

Transport tablespace related problem

Hi all,
I have a problem i want to export tablespaces as i have to migrate my db from oracle 9.2 to oracle 10.2 from win to RHEL4.......but i am getting an error ,pls suggest me for the same....
SQL> @G:\oracle\ora92\rdbms\admin\dbmsplts.sql;
Package created.
Package created.
Grant succeeded.
Package created.
Grant succeeded.
drop view sys.transport_set_violations
ERROR at line 1:
ORA-00942: table or view does not exist
PL/SQL procedure successfully completed.
drop table sys.transts_error$
ERROR at line 1:
ORA-00942: table or view does not exist
Package created.
SQL> exec sys.dbms_tts.transport_set_check('SRO',true);
BEGIN sys.dbms_tts.transport_set_check('SRO',true); END;
ERROR at line 1:
ORA-04068: existing state of packages has been discarded
ORA-04063: package body "SYS.DBMS_TTS" has errors
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at line 1
SQL> desc dbms_tts
PROCEDURE DOWNGRADE
FUNCTION ISSELFCONTAINED RETURNS BOOLEAN
Argument Name                  Type                    In/Out Default?
TS_LIST                        CLOB                    IN
INCL_CONSTRAINTS               BOOLEAN                 IN
FULL_CHECK                     BOOLEAN                 IN
PROCEDURE KFP_CKCMP
PROCEDURE TRANSPORT_SET_CHECK
Argument Name                  Type                    In/Out Default?
TS_LIST                        CLOB                    IN
INCL_CONSTRAINTS               BOOLEAN                 IN     DEFAULT
FULL_CHECK                     BOOLEAN                 IN     DEFAULT
SQL> exec dbms_tts.transport_set_check('SRO',true);
BEGIN dbms_tts.transport_set_check('SRO',true); END;
ERROR at line 1:
ORA-04068: existing state of packages has been discarded
ORA-04063: package body "SYS.DBMS_TTS" has errors
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at line 1

Are you,by any chance, running Oracle 9i installation code in an Oracle 10g database?
If so : why?
As far as I know you can only transport tablespaces to a database of an identical version, so it looks like this is not going to work.
Sybrand Bakker
Senior Oracle DBA

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 ?

Transport tablespaces between databases with different character sets

Hi everyone:
I have two 10R2 databases on the same hp-ux 64bit server, 1st one with NLS_CHARACTERSET=US7ASCII, 2nd one with
NLS_CHARACTERSET=AL32UTF8.
NLS_NCHAR_CHARACTERSET on both databases is AL16UTF16.
Can I transfer tablespaces from the 1st one to the 2nd. The data could be in English, French & Spanish.
If not what are my options?
Thanks in advance.

First off, if you are storing French and Spanish data in database 1 where the character set is US7ASCII, you've got some serious problems. US7ASCII doesn't support non-English characters (accents, tildes, etc). If you're storing data this way, you've introduced data corruption that you'd have to resolve before copying the data data over to another machine.
Second, technically, the source and target character set have to be identical. Since US7ASCII is a strict binary superset of AL32UTF8, you could theoretically transport a US7ASCII tablespace to an AL32UTF8 database. In your case, though, since the data is not really US7ASCII, you'd end up with corruption.
Any of the Oracle built-in replication options is going to require that you resolve the corruption issue. Assuming that you can figure out what character set the source database really is, you could potentially dump the data to flat files (taking care not to allow character set conversion to take place) and SQL*Loader them into the destination system by identifying the proper character set in your control file. That's obviously going to be a rather laborious process, though.
Justin

Transport tablespace from raw to cooked

Similar Messages

Maybe you are looking for