Several of our customers complain about poor performances since their migration from OE10.1x to OE10.2B (SP4 or SP5).
Performance profilers show that FOR EACH statements with indexes combination on large tables are running slower than before.
These large and dynamic (i.e. with lots of add/mod/del) tables are seriously fragmented (scatter factor arround 8). I have tested and compared performances before and after a binary dump&load, but also after a conversion into Type II storage areas. The gain is not miraculous (~30%).
Then, for a given table, I've tried to create a brand new index to avoid 2 indexes combination. The gain is greater.
But since our code relies (heavily) on combination of indexes (generally between 2 and 6), I can't imagine that we'll have to review our indexes and source code to reduce (or even avoid) indexes combinations. So I wonder if something internally changes between early OE versions and 10.2B in terms of index bracketing/combination?
Thanks in advance for your help, advices or suggestions.
Jeg er væk fra kontoret indtil den 11. maj, og checker ikke altid mail og telefon regelmæssigt. Jeg vil dog svare på din mail så snart som muligt.
Hvis du har behov for support, kontakt venligst firstname.lastname@example.org, så vender vi tilbage så snart det er mnuligt.
Administrative henvendelser kan ske til : email@example.com.
I am not in the office until May 11th 2012. I will not be checking my mail and phone on a regular basis, but will reply to your mail as soon as I can.
If you need support from appSolutions, please send your mails to firstname.lastname@example.org.
If you need Roundtable support, please send mails to :
Med venlig hilsen / Regards