cancel
Showing results for 
Search instead for 
Did you mean: 

Not able to understand the reason for long export of SAP Tables

Former Member
0 Kudos
495

Hi,

    I recently did a export of CRM 7.0 System of about 600 GB of DB size. It took nearly 10 hours for a table CRMORDERCONT to be exported and DBTABLOG of about 4 hours to be exported. Entries in CRMORDERCONT is around 3 lakhs records and DBTABLOG is around 13 crore records.

I ran update statistics and tunned the Oracle parameter.

CRMORDERCONT.TSK file contains only the CRMORDERCONT Table and DBTABLOG.TSK  contains DBTABLOG table only.

Size of  table is

select SEGMENT_NAME,SEGMENT_TYPE,BYTES/1024/1024 "MB",MAX_SIZE/1024/1024 "MB" from dba_segments where SEGMENT_NAME='CONTENTDATA';

SEGMENT_NAME
--------------------------------------------------------------------------------
SEGMENT_TYPE               MB         MB
------------------ ---------- ----------
CRMORDERCONT
TABLE                1013.375       2048

SQL> select SEGMENT_NAME,SEGMENT_TYPE,BYTES/1024/1024 "MB",MAX_SIZE/1024/1024 "MB" from dba_segments where SEGMENT_NAME='DBTABLOG';

SEGMENT_NAME

--------------------------------------------------------------------------------

SEGMENT_TYPE               MB         MB

------------------ ---------- ----------

DBTABLOG

TABLE               45227.125       2048

Can anyone please help me to understand the reason for such a long duration of export of these tables ?

Thanks and Regards,

Vimal

View Entire Topic
former_member189725
Active Contributor
0 Kudos

These 2 tables have Long RAW data type and the R3load needs to convert them during the export to a platform independent format before dumping into data files. This conversion is CPU intensive and hence it is always expected it is going to take a lot time.

You can do very little from your end to tune them .

1. You can split these tables and parallely export them using orderby file.

2. Use can use an application server with higher CPU power.

3. Utilize the CPU to the maximum extent ( as SAP application is already down) by increasing the number of R3load processes on the fly editing the export_monitor_cmd.properties and orderby files in the installation directory.

Regards

Ratnajit

Former Member
0 Kudos

Hi jairo & Ratnajit,

   Thanks a lot for your valuable answers. Now I got the reason for this long export.

I will try the option of table splitting and do a test export again to find out whether we can reduce the downtime.

Thanks again.

Will get back in case of any issues.

Thanks and Regards,

Vimal

martin_E
Active Contributor
0 Kudos

Sorry, I missed this yesterday.

DBTABLOG contains the change records. If you don't need them, remove them / archive them before performing the export copy, or modify the export SQL / DDL to not export them.