Moving large table into its own Tablespace on target system during CUUC

[Former Member]

Hi Unicode Gurus,

I am in process of Upgrading 46C system to ERP6 with Combined Upgrade and Unicode Conversion. I am following CUUC guide.

Question i have is related to moving Large table into its own tablespace during unicode conversion in target system.

For example : We have HR Implementation. total size of Database is 1.4 TB. PCL2 is 250 GB in 46C system with 30% tablespace PSAPBTABD in source system. After import in target system PCL2 table is in PSAPSR3 tablespace.

I want to move PCL2 in its own table space (i.e PSAPPCL2) in target system

Please note that : we are using table Spilliting for this table and other 30 different table for performance reason.

---

This is what i think .... you guys know better then me. you may have done several times during you career.

Can you provide me details or what you think about below solution.

Do i need to do anything differently ?

Any downside/precautions I need to take

-

---

I know tablespace and Catagory Mapping is done thru DDLORA.TPL ; in source and Target.

PCL2 has APPL1 catagory and Mapped to PSAPBTABD in source system

in Target ERP6, catagory APPL1 is mapped to PSAPSR3. that's how PCL2 table imported in to PSAPSR3.

When i do package spilliting I get PCL2 STR which has att APPL1.

On source system :

1. Can I modify PCL2.STR to reflect attribute from APPL1 to ZPCL2 ( after table splitting , before starting export monitor, before creating DB / tablespace for target system ) ?

On Target system :

1. Start Installation of DB instance, while creating Tablspspaces create PSAPPCL2 table space with 500GB

2. Reduce total calculated size of PSAPSR3 by ~300GB (Since PCL2 will be in its own tablespace)

3. Change DDLORA.TPL in migmon directory create row under table storage and index storage under loc

ZPCL2 PSAPPCL2 0000

4. Start import Monitor - when ready...

Any thoughts ??

Any prompt input /suggestion/ comments appreciated.

Thanks

Jignesh

[stefan_koehler · Accepted solution]

Hello Jignesh,

your procedure is correct.

Out of curiosity ... why do you wanna put some tables into a different tablespace? I don't know any reason for that.

Regards

Stefan

[Former Member · Accepted solution]

Hi Stefan,

Thanks for your prompt response.... and Comment about process

Are there any issue with modifying DDLORA.TPL or STR file ?

Do you know any pro/cons for moving large table into different tablespace ?

Currently I am doing it for DEV/QA / UAT using Prod Copy. so once development/ testing/ User Testing is done business wants to trim down DB size. Reason of moving into its own tablespace is because business has plans to archive/delete data. when they are done easier for me to manage.

if you can share pro/cons for moving into their own tablespaces would be appriciated. I am planning atleast 10 large tables.

Thanks

Jignesh

[stefan_koehler · Accepted solution]

Hello Jignesh,

> Are there any issue with modifying DDLORA.TPL or STR file ?

If you do it correct without any typo .. there are no issues )

I have done this also several times and it works fine. (migrating to the "new" sap standard tablespace layout by an unicode conversion)

> Do you know any pro/cons for moving large table into different tablespace ?

As i already said i can't think of any reason for that right now with LMTs, etc..

> Reason of moving into its own tablespace is because business has plans to archive/delete data. when they are done easier for me to manage.

Why is it easier to manage?

If you have archived/deleted enough of your data ... just reorg the table / indexes in the same tablespace and it is done.

Ok now you can say that you can reorg the tables / indexes back into the "standard" tablespace and drop the old one ... but mkey ) ... you need to think about the tablespace mapping inside the SAP DDIC (DDART, TAORA and IAORA)

Regards

Stefan