BI 7.0 Migration with customer-specific Tablespaces

[JoMi]

Hi,

I perform a heterogeneous systemcopy of a BI 7.0 system (SP-Stack 14) from HP-UX 11.11 with Oracle 10.2.0.2 to SLES10 SP2 with Oracle 10.2.0.4 with the installation master for SAP Netweaver 7.0 SR3.

Some customer-specific Tablespaces were created according note 46272 with the following syntax:

Example:

PSAPJOWAD

PSAPJOWAI

The DDLORA.TPL and DBSIZE.XML contain these entries.

During the setup of the target system DDLORA.TPL and DBSIZE.XML will copied to the installation directory. On the input screen "Tablespace Information" the customer-specific tablespaces have been mapped to PSAPSR3 (new schema is SR3). I correct the input with the customer-specific tablespace names and sizes. During the import phase with the migration monitor I see that the customer-specific tablespaces were mapped again with PSAPSR3 instead PSAPJOWAD.

Is it possible to keep this customer-specific tablespaces during the migration?

Thanks a lot.

Regards,

Joe

[Former Member]

Hi,

Yes it is possible to migrate customer specific tablespaces - it is not a problem,you can.

ABAP Dictionary is generally structured in the following way:

1. Tables assigned to table types/data classes (TABART's such as APPL0, etc).

2. Table type assigned to database storage units.

If the customer tablespaces have been set-up in the proper way in the source system - it shouldn't pose a problem during export or import.

Make sure the following is maintained properly in the source system:

1. Customer tablespace maintained in table TSORA (if index tablespace exists for this ISORA).

2. The TABARTs which will be a part of this tablespace is maintained in table TAORA and IAORA (for indexes).

3. If a customer specific TABART is used it should be maintained in table DDARt and DARTT.

4. If a customer table is used - it should be tagged to the proper TABART in table DD09L.

To confirm you can use R3LDCTL before you do the actual migration to check whether the proper <TABART>.STR and DDL<DBS>.TPL file is created - you can do this when the SAP system is up.

Let me know if this is sufficient - else I can elaborate.

Please award points if this stuff is useful.

Thanks, Dibya

[Former Member]

Dibya,

you also helped me with explaining whitch tables (tsora, taora..) I need to check/maintain.

Maybe you can help me with this - it is related to the topic:

After exp/imp I want to keep old tablespace schema and also with customer created tablespaces. In my case export creates good DDLORA.TPL file in export directory(EXPORT\ABAP\DB). But in import phase "Import ABAP" (i think) in log directory in sapinst_instdir\ERP\LM\COPY\ORA\SYSTEM\CENTRAL\AS-ABAP it

creates wrong DDLORA.TPL with new tablespace schema! I can replace it with good DDLORA file. But, can this somehow be avoided or fixed? I have everything correct in tables tsora, taora, iaora, ddart, dartt - custom data classes are linked to proper custom tablespaces.

And second question. When doing import with Sapinst we do it with advanced configuration selected. Then we have 2 hour job just to click through all screens and to start the export. It is because we keep the old tablespace schema and have big DB, so in: Dialog "Oracle > Tablespaces" we need to delete all and manualy enter allmost 200 lines (200 datafiles size of 10 GB). And then another 200*4 lines in: Dialog "Oracle > Tablespace Extensions", Dialog "Oracle > General Tablespace Storage", Dialog "Oracle > Default Tablespace Storage", Dialog "Oracle > Extended Tablespace Management".

So, we have 2 hour of system downtime for nothing (in whole exp/imp process).

Any suggestions here?

Thank you!

[Former Member]

Hello Igor,</br>

</br>

I am almost certain that the reason the DDLORA.TPL file for the import contains the PSAPSR3 naming convention is because you might not be changing that input during the installation of the target database. If you are like me and make screenshots for everything, please check the input screen. In SAPINST this would be the screen titled "Oracle > Database Instance" with the instruction "Enter the parameters of the database system". Here is where you specify memory used and where you can specify the database schema. Simply change that to what you want it to be. The DDLORA.TPL will then be generated with the schema name you want. </br>

</br>

To your other question, I always recommend using the Migration Monitor tools from SAP. You have a lot more control and you can plan ahead of time the order of the packages and tables for both the export and import, based on a previous test migration or simply the size of the tables as listed from DB02/DBACOCKPIT under Detailed Analysis. You can use these together with SAPINST by selecting the option "Start the Migration Monitor manually" during the database installation of the target system. This is on the same screen where you will select "Installation Method: Standard System Copy / Migration (load-based)". If you are not seeing this, then you are not using an up-to-date SAPINST. I see from your SAPINST log path that you are definitely making the correct selection from SAPINST.</br>

</br>

If you have never used these tools before, do a search under service.sap.com/swdc for MIGMON, MIGTIME and SPLIT. The SAPINST will also unpack these for you within the log directory of your installation. You will see the files import_montior.sh (and .bat), export_monitor.sh, etc. I don't usually use these files, since I keep a copy of the most up to date versions on my hard drive. Within each MIGMON.SAR, MIGTIME.SAR and SPLIT.SAR file, you will find a PDF file which explains how to use the tools.</br>

</br>

I would also recommend the latest version of the System Copy document from SAP. This includes some very useful information on performing a system copy or migration using SAPINST or the migration tools. I believe it also goes into some detail on how to split tables, which is a real time saver when you are dealing with single tables which are several hundred GB in size. I use this often. As a result, I cannot use SAPINST for the export/import of my migrations/system copies because SAPINST does not know how to handle table splits. </br>

</br>

Please let me know if you have any other questions. </br>

</br>

</br>

Best Regards,</br>

Warren Chirhart</br>

Certified SAP Technical Consultant</br>

Certified SAP Migration Consultant</br>

REALTECH Consulting GmbH</br>

Edited by: Warren Chirhart on Dec 1, 2009 12:17 PM

[markus_doehr2]

I noticed also problems with that "manual maintenance" of the tablespaces in the advanced view during migrations. It never actually took place, neither with SR2 nor with SR3.

I would open an OSS (BC-INS) and ask the support if this is possible. If they offer the possibility of maintaining those tablespaces, they should reflect that also later.

Markus