Showing results for 
Search instead for 
Did you mean: 

het system copy cluster tables

Active Participant
0 Kudos


i retake a discussion i had some days ago about an heterogenous system copy about system 7.01 with many tablespaces created ad hoc .

The problem was that in target system there weren't the same tablespaces of source system. For five of them , infact, the tables came back to original tablespace PSAPSR3.

4 of these  tables  are cluster tables:





I saw that there was a problem in TSORA TAORA and IAORA , missing the entries for these tablespaces. I've adjusted these tables and changing the se13 associating the referred table name to the right class (ex USR62,USR63,etc) and activated it.

I did the same thing also for a not cluster table like STXL and only for this table i solved the problem.

Fot other cluster table i see in export that program r3ldctl and r3szchk don't take these new entries ...only the DDLORA.TPL is right.....but in DBSIZE.XML no tablespace for the four cluster tables.

In STR files i find the following entry:

:{xxxadm}:/mnt/xprt_p1e/EXPP1E2/ABAP/DATA> grep KOCLU *.STR


KOCLU.STR:att: CLUST   3  ?? C all    KOCLU~0                        CLUST   3

It seems that it looks for entry in taora called CLUST

Am i missing something to solve this situation?



Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Nick,

Could you please cross check table DD09L for your tables.

If the TABART is still APPL1 and not your new USR* TABART then please execute report RSFXTBRT  (leave the mode field blank).

The report should confirm the inconsistencies you have. Once you are happy that the report is confirming the tables you have mentioned then please run the report again and this time fill "FIX" in the mode field. Then of course, please cross check DD09L again to make sure the changes are persistent.

After you've done the above, please run your export step again to confirm that DBSIZE.XML now takes the different tablespaces into account.

Kind Regards,


Active Participant
0 Kudos

Hi Amerjit

thanks for you answer

let's take the KONV-KOCLU example....

In DD09L  we have the following situation : (see attachment KONV and KONV-KOCLU).

You can see that KONV belongs to USR63 correctly . I suppose that for table KOCLU will be create the corret tablespace PSAPSR3KOCLU that esists in our system for many years, but this doesn't happen.

Starting the report  RSFXTBRT   i have some inconsistencies but only in some Z* or Y* table and i can fix them but i don't think is a problem:

4 ETG013 "Showing inconsistent tabarts" " " " "

4 ETG011 "Table/Container""/SDF/CMO_O2APPL""PSAPSR3"

4 ETG011 "Table/Old tabart/New Tabart""/SDF/CMO_O2APPL""SSRC""APPL0"

4 ETG011 "Table/Container""ZODA_URG""PSAPSR3"

4 ETG011 "Table/Old tabart/New Tabart""ZODA_URG""USR05""APPL0"

4 ETG011 "Table/Container""ZTERZTEL""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZTERZTEL""APPL0""USER"

4 ETG011 "Table/Container""ZMSC_TPDOC""PSAPSR3ZMS1"

4 ETG011 "Table/Old tabart/New Tabart""ZMSC_TPDOC""APPL0""USR61"

4 ETG011 "Table/Container""ZLTSOM""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZLTSOM""APPL0""USER"

4 ETG011 "Table/Container""ZDISTERGAV""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZDISTERGAV""APPL0""USER"

4 ETG011 "Table/Container""ZMM_MIGRDA_PERI""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZMM_MIGRDA_PERI""APPL0""USER"

4 ETG011 "Table/Container""ZESTRDWH""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZESTRDWH""APPL0""USER"

4 ETG011 "Table/Container""ZFTCS""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZFTCS""APPL0""USER"

4 ETG011 "Table/Container""ZYI7_BL_DBFLUSSO""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZYI7_BL_DBFLUSSO""APPL1""USER"

4 ETG011 "Table/Container""ZYI5_BL_DBFLUSSO""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZYI5_BL_DBFLUSSO""APPL1""USER"

4 ETG011 "Table/Container""ZMS1_IMEI""PSAPSR3ZMS1"

4 ETG011 "Table/Old tabart/New Tabart""ZMS1_IMEI""APPL1""USR61"

4 ETG011 "Table/Container""YMSDT_SAC003_ERR""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""YMSDT_SAC003_ERR""APPL0""USER"

4 ETG011 "Table/Container""YMSDT_VALIDA_FID""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""YMSDT_VALIDA_FID""APPL1""USER"

4 ETG011 "Table/Container""ENHCONTRACTTYP""PSAPSR3701X"

4 ETG011 "Table/Old tabart/New Tabart""ENHCONTRACTTYP""SDIC""SLDEF"

4 ETG011 "Table/Container""SFW_COMPONENT""PSAPSR3701X"

4 ETG011 "Table/Old tabart/New Tabart""SFW_COMPONENT""APPL0""SLDEF"

4 ETG011 "Table/Container""ZGCST_NTWNR""PSAPSR3USR"

4 ETG011 "Table/Old tabart/New Tabart""ZGCST_NTWNR""APPL0""USER"

any ideas? Could be a cluster table problem that sould be manage in different manner?



Former Member
0 Kudos

Hi Nick,

I read your initial post again and clearly I was dancing faster then the music (mea culpa).

What you have said is that for TRANSPARENT tables where you have defined a custom TABART everything is as you expect it to be. It's for POOL/CLUSTER tables that you are unable to change the target tablespace.

If I haven't "danced to quickly" this time then this is normal as POOL/CLUSTER tables are hard coded in the R3* tools to go to the respective TABART (POOL/CLUSTER).



Former Member
Active Participant
0 Kudos


The problem is that now i can't dance 😉

i've read the OSS note and it seems that i can do nothing for these particular tables.

I can do only one thing:


swpm for the import where I can configure tablespaces adding which are missed


after import , in noarchive , reorg on the new tablespaces.



Former Member
0 Kudos


What you're saying is the most "standard" way of going about it.

How big are these tables to warrant being in their own dedicated tablespaces ? Is this to respect a "like for like" migration ?


Active Participant
0 Kudos


well we are talking about

RFBLG  190Gb

EDI40    180Gb



Yes the idea is to respect the source system .

For RFBLG and EDI40 i can accept to give them an own tablespace....for other two tables for me is not so urgent.

The DB is 7TB!.



Former Member
0 Kudos


If I were in your boots I wouldn't even bother with separate tablespaces. There is only one case where I had to do that and that was a unique case.

It seems to me like you're maintaining/have inherited a "legacy" layout whereas now would be the moment to go back to the "norm".

Your RFBLG isn't abnormally big by any reasonable standards and your EDI40 could be significantly reduced by some housekeeping (see note #706478). As for KOCLU/CDCLS/STXL, I'd imagine the sum of all three would be less than 100GB.


Answers (0)