2010 Dec 21 3:04 PM
Dear Ladies and Gentlemen,
For performance reasons (selections not via the primary key) we consider to convert the CDPOS table from cluster to transparent.
- did any of you perform this step already?
- what are your experiences and suggestions?
Best regards,
Peter
2010 Dec 21 3:18 PM
What is your desired access path, maybe there is a workaround?
Thomas
2010 Dec 21 7:11 PM
select * from cdpos into corresponding fields of table it_cdhdrpos where
objectclas = 'VERKBELEG' and objectid = par_vbeln and tabname = 'VBAP' and
tabkey = tabkey and fname = 'ABGRU' and chngind = 'U'.
2010 Dec 21 8:08 PM
But you're using the leading fields of the key including the objectid - a table conversion isn't going to boost the performance of that statement. If you wanted to index a non-key field as the leading field of the index, then you would get a performance boost. I've never had the need to convert CDPOS though I have converted others. You should read all of the associated notes about side effects and recoveryadjustment procedures.
2011 Feb 03 10:45 AM
Hi Peter,
you have nearly the complete primary key for cdpos, only changenr is missing. Before converting the table, try to read all cdhdr entries to get the missing change-numbers. This two-step-approach might be faster then a single select with only 3 fields (before the missing field will inhibit the index-usage).
But your select seems to indicate, you are interested to all changes of a specific field -> define change pointers and your performance issue might be solved much more elegant.
Regards,
Christian
2011 Feb 14 5:14 PM
Hi Peter,
Check it with standard report RSSCD100. Do the selections for
object = VERKBELEG
objectid = par_vbeln
and so on.
Surely the performance will be good. Do a debugging session and use the same objects to do the selection
I hope this helps you
Regards
Eduardo
2010 Dec 24 12:29 PM
Its better to use Function modules for your requirement:
CHANGEDOCUMENT_READ_HEADERS
CHANGEDOCUMENT_READ_POSITIONS .