SAP for Utilities Discussions
Connect with fellow SAP users to share best practices, troubleshoot challenges, and collaborate on building a sustainable energy future. Join the discussion.
cancel
Showing results for 
Search instead for 
Did you mean: 

EMIGALL performance for migration object OBJCLASS

daniel_mccollum
Active Contributor
0 Kudos

Hi all,

my previous question, was & was focused on improving performance of classification of IFLOT & EQUI objects.

Testing EMIGALL for migration object OBJCLASS I am seeing no performance gains between a single thread update & parallel update threads.  IE the single thread throughput is reported as ~the same as the parallel threads throughput combined.

I note in the job logs of my various tests;

  • for a single thread, that no messages are logged between the start & end of the migration.
  • for parallel threads, that message C4 200 'Class "CLASSNAMEHERE" is locked' appearing many times.

I don't see any unexpected migration errors in ether case.

Are there any insights on how I might improve over all throughput using this method? I cant see any control parameters for this object, nor does the Guideline have much information on OBJCLASS.

First world problems 😕

1 ACCEPTED SOLUTION

ashvinder_rana
Explorer
0 Kudos

Hello Daniel,
Without having much insight into your system and infrastructure details or the volume that you are working with, I suggest for you to try below for performance improvement.
1. Run DB Statistics on functional location and Equipment related tables such as EQUI, IFLOT, ILOA, etc. (these are HLO objects that you are updating by way of classification). Also update classification table such as AUSP. These tables mentioned here as a starting point.
2. Also strongly suggest that a performance trace be done on this job to analyze and identify another table or steps that may be a performance bottleneck and maybe a candidate for DB statistics refresh Or some other corrective action.
3. The locks maybe occurring due to a mass update which is as expected. Perhaps to get by that you may want to use "commit buffering allowed" option for this migration object and set to say a number "10" or "20" to start with and see if it helps better the performance. As you would have noticed, locks will also impact performance.
4. Please also refer to Cookbook for ISUMIG Performance and refer to sections for DEVICE, CONNOBJ and DEVLOC. These are HLO objects for classification and there may be some useful insight in that document too.


Hope this helps.


Ash



View solution in original post

4 REPLIES 4

ashvinder_rana
Explorer
0 Kudos

Hello Daniel,
Without having much insight into your system and infrastructure details or the volume that you are working with, I suggest for you to try below for performance improvement.
1. Run DB Statistics on functional location and Equipment related tables such as EQUI, IFLOT, ILOA, etc. (these are HLO objects that you are updating by way of classification). Also update classification table such as AUSP. These tables mentioned here as a starting point.
2. Also strongly suggest that a performance trace be done on this job to analyze and identify another table or steps that may be a performance bottleneck and maybe a candidate for DB statistics refresh Or some other corrective action.
3. The locks maybe occurring due to a mass update which is as expected. Perhaps to get by that you may want to use "commit buffering allowed" option for this migration object and set to say a number "10" or "20" to start with and see if it helps better the performance. As you would have noticed, locks will also impact performance.
4. Please also refer to Cookbook for ISUMIG Performance and refer to sections for DEVICE, CONNOBJ and DEVLOC. These are HLO objects for classification and there may be some useful insight in that document too.


Hope this helps.


Ash



0 Kudos

Thanks for the feedback Ashvinder,

I have been pursuing all the above, so great to see Im not missing anything obvious at this point.

I have improved throughput 30% overall so far after the review. Go me.

Regards

Daniel

Former Member
0 Kudos

Hi Daniel

The main problem running in parallel are SAP enqueues on table KSSK, which is a bit surprising because the call includes an object ID which should be unique.

So when running in parallel could you please check the lock arguments via transaction SM12?

BTW according to the object OBJCLASS documentation commit buffering is not allowed, so be careful in case you do buffer and verify the data after loading.

Yep

Jürgen

0 Kudos

Yes, I had thought the same.

Also I have discounted the concept of commit buffering already after reviewing documentation. Thanks for the heads up anyway.