cancel
Showing results for 
Search instead for 
Did you mean: 

Transportable Tablespace:Tables not active in dictionary

Former Member
0 Kudos

Hi,

I have a custom/user defined tablespace in source system(ABC) and the same was moved to the target system(XYZ) using transportable tablespace(1035051 - homogenous method). I am able to see the entire details of that tablespace in DB02, but when I try to access the tables via se11, the error message displayed is "Table does not exist".

Any help would be highly appreciated.

Informations:

I have made the desired entries in the tables DDART, TSORA, TAORA & IAORA.

Source & Target System Details:

OS - Windows 2003(64bit)

DB - Oracle 10G(10.2.0.2)

Regards,

Karthik

Accepted Solutions (0)

Answers (2)

Answers (2)

volker_borowski2
Active Contributor
0 Kudos

Hi,

assuming that the OWNER of the tables in the database has the same

name (SAPR3 / SAPSR3) on Source and Target:

On source, you need to do a check in SE14 for all tables in this tablespace.

There must be no inconsistencies.

There should be no CLUSTER Tables involved (showstopper.)

Create a transport in SE01 (can be a transport of copies).

Enter

R3TR TABL table1

R3TR TABL table2

R3TR TABL table3

for all tables of the transported tablespace.

Release the transport.

Backup your target database (! allways a good idea !).

count all rows in all tables for your tablespace (just for later verification)

Import the transport to your target system.

Check the transport logs.

You should now have active DDIC sources for your tables

and fitting runtime objects, so the SE11 should know your tables now

and SE14 on the target must be green for all tables as well.

Your distribution log and your nametab activation log from the

transport should not show any DDL (ALTER/CREATE/DROP) related to

one of your tables. If you find one you might have a problem.

This could be the case for tables that have a field sequence missmatch

between db-object and runtime object. If you have such table, your import

will most likely trigger a conversion (which may not be a fault, but too

resource consuming).

If your DDIC Source has an incorrect setup of the TABART stuff, and

the target has no active nametab, the transport might force a conversion

to a diffrent tablespace than intended. So check the table locations after the import.

In case you like to try carefully, choose a small single table first and do

an oracle export of the table before the import of the transport.

Good luck

Volker

Edited by: Volker Borowski on Oct 29, 2009 8:57 PM

former_member204746
Active Contributor
0 Kudos

transportable tablespace is an Oracle concept. it does not update SAP's data dictionary. SE11 uses SAP's data dictionary.

you must tell SAP that these tables and indexes exists. Talk to your abapper to create this in SAP's data dictionary.

Former Member
0 Kudos

You mean to say SAP does not support "Transportable Tablespace" feature!!

Transportable tablespace is similar to Export/Import method, provided few different steps involved. Also this note 1035051 talks about homogeneous and hetrogeneous copy using transportable tablespace feature.

So the above mentioned note is incorrect!

Regards,

Karthik

Edited by: M R Karthik Kumar on Oct 29, 2009 1:21 PM

former_member204746
Active Contributor
0 Kudos

This is not what I said.

SAP supports transportable tablespace, but you must find a way to inform SAP's data dictionary that this was done. Without this. your table will exist in Oracle database but not in SAP's data dictionary.

Is there a solution for this? Probably but I do not have it for you.