OE10.2B08 idxbuild all - fastest options - Forum - OpenEdge RDBMS - Progress Community

OE10.2B08 idxbuild all - fastest options


OE10.2B08 idxbuild all - fastest options

This question is not answered

Age old question! I need to rebuild indexes on a DB as fast as possible. 

Got 10GB memory

500GB free on DB volume 

250GB free on another volume

What's the best options to use? Need any more info? 

Windows by the way. 

All Replies
  • The customer is receiving files from a German customer, but as far as I can see all connections are Codepage 1252. And the records we get the messages for do not have special characters in them.

  • > we've got index corruption on and it makes the problem go away, but after a while it comes back again.

    Does the customer use the latest hot fix for V10.2B08? If I recall correctly, it fixed some bugs related to the index corruptions.

    > Is there anything else I can do to debug where this is coming from.

    There is no an easy answer. More details are required. What are the errors reported by idxfix? Which indexes were corrupted? Unique or non-unique? Are the records with the corrupted indexes be created recently? What are the typical transactions that create/update these tables? One or many records per transaction?

  • No the customer is not running any hot fixes. I will investigate.

    The indexes are a mix of unique and non-unique. Yes they are recent creations because we very rarely access older records. The transacitons will be multi record ones. Our scoping is really bad.

  • It smells like a known bug. ;-)

  • Crap code? ;)

  • Progress OpenEdge Release Notes

    Release: 10.2B0836

    Date: April 2015

    2.  List of issues fixed in previous 10.2B08x releases


    Issue ID: PSC00328928


    Under certain cases involving multiple database updates, you may end up with logical index corruption if you undo certain sub-transactions.

    The problem may occur on undo of certain sub-transactions when indexed fields of tables from multiple databases are updated in different nested sub-transactions.

    This issue can be avoided by running with the -nosavepoints option.

    The issue was fixed in 10.2B0832

  • Thanks George - that sounds very likely to be a cause.

  • > [2017/07/19@03:49:18.139+0100] P-4460       T-4928  I          : (11480) Temporary sort file at f:\sort\ used up 259868928K of disk space.

    > [2017/07/19@03:49:18.141+0100] P-4460       T-4928  I          : (11483) A total of 259868928K of temporary sort disk space was used for area 6.

    > That's a lot of disk io. So adding more RAM will help that? Not that we'll be able to add 260GB more! I presume putting the sort files on as fast a disk as possible will help?

    > Full idxbuild took 14.5 hours! :(

    Having large tables (or very many smaller ones) together in a single area will increase the required RAM to prevent temp file disk I/O.  Having a well-designed structure will reduce the required RAM.

    Are all of the application tables in the schema area?

  • Yup although I've just been asked to do a full D&L to Type II as part of the solution.