Reorganising a large database can take a very long time: times in excess of 48 hours are not unknown. There are various ways in which database reorganisations can be speeded up:
You can use the Advanced Database Properties dialog to configure certain properties of the index file. You are recommended always to enable Enhanced Index Compression. For a very large database, or a database stored on a solid state device, set the index node size to 4096 bytes.
From release 4.621 REORGDB automatically determines whether the database to be reorganised is local or not by examining the network status table. The −LOCAL option will be selected automatically unless the resil_type field indicates that databases are remote. You can still use −LOCAL to force local file handling to be invoked even where the database should be remote, and you can use −REMOTE to force the database to be treated as though it were remote.
If the database you want to reorganise is on the local machine, run the reorganisation utility with the −LOCAL command tail, for example:
REORGDB −DB SALESORD −LOCAL −DATA
Much of the processing normally done by the database manager is now done by the terminal manager. This provides certain benefits:
Up to release 4.621 REORGDB only allocates 4MB of memory for file and temporary index buffering. by default If your machine has plenty of memory allocating a larger amount of memory may dramatically improve performance. For example −heap 16384 would cause REORGDB to allocate 16MB of memory for the heap. In fact this is the default from release 4.622.
If your database is very large using the −ALTSORT command tail to sort the data file without grouping related tables may improve performance considerably. Although the first pass will be a little slower this is likely to be more than offset by an increase in the efficiency of the file buffering in the phases that rebuild the index. In addition, the resulting database is likely to perform better, particularly if it is very large.
The −FAST command tail makes REORGDB use a different algorithm for building the index file. It uses fewer passes, and the index optimisation phase is skipped. This may therefore speed reorganisation up. An example command is:
REORGDB −DB SALESORD −FAST −INDEX
Note that although −FAST may speed up the reorganisation options that build a completely new index (options 1, 3, and 7), it builds a slightly less efficient and larger index than otherwise.
If your database is very large the −FAST option may well actually degrade performance, because a degradation in the efficiency of file buffering may more than offset any time saved by the use of fewer passes.
The −FAST option has been removed in release 4.622, because fewer passes are used during the indexing phase, and the index optimisation phase is never skipped (in 4.622 this phase, which is very quick, typically reduces the index file size by up to 30%).