As of release 4.622, the contents of this page only apply if you reorganise the database with -CORRUPT. From release 4.622 REORGDB uses the existing index file to build a perfectly sorted DAT file.
As with index optimisation, sorting the data file may improve the performance of programs accessing the database.(The improvement can be very subtantial for a large database). You can specify that the data file is sorted when using option 3 - Rebuild data and index files and option 7 - Delete application data. To enable sorting with either of these options, run the reorganisation with the -SORT or -ALTSORT command tail, for example:
REORGDB -DB SALESORD -DATA -ALTSORT
This rebuilds the SALESORD data file and index, sorting the data file in primary key sequence but with the records from related tables grouped together. For example, ORDER_HEADER records are arranged like this:
order_1, order lines for order 1,
order_2, order lines for order 2.
The -ALTSORT option sorts the data file but does not group records from different tables together like this, but sorts each table individually. On large databases -ALTSORT is likely to give the most benefit.
Neither thhe -SORT and -ALTSORT options perform a complete sort of the the whole data file, which would take a prohibitive amount of time in the case where there is no index available, and probably not significantly improve the performance of the database. Rather the data is partially sorted within the limits of the memory available to the program. Using -ALTSORT regularly the amount of order in the data file will gradually increase, and the performance penalty for the reorganisation will decrease.
Except on legacy versions of DP4, you can increase the amount of memory available to REORGDB for sorting by using the -HEAP command tail. For example -HEAP 16384 allows REORGDB to use 16MB of memory for sorting records rather than the default 4MB.
You may opt to sort the whole data file, but you must use a different method, described in Sorting the Entire Data File.
Some points to consider are:
-SORT and -ALTSORT marginally slow down the first phase reorganisation, but if the index is large this is usually more than offset by a reduction in the time it takes to build the index.
It is never possible to predict what performance benefit will be gained from sorting the data; it depends on how particular applications access the database. However, for programs that using a large database that access large amounts of data sequentially the improvement is likely to be very dramatic: we have seen the times taken to run such programs reduced from the order of 30 to just 1 or 2 minutes.