OpenEdge Data Management: DataServer for Microsoft SQL Server

Caching records
Caching records
The DataServer caches results sets from a MS SQL Server data source to enhance performance
when using block cursors. It caches as much data as fits in its allocated cache size. When using
firehose and/or lookahead calls, the allocations are made to fit the size of the result set.
Depending on what kind of cursor a query is using, the DataServer caches row identifiers or
records:
• Standard cursors — The DataServer caches row identifiers (PROGRESS_RECID column or
other unique index) for the results set. If you use the PROGRESS_RECID, each identifier
requires 4 bytes of cache, therefore, a results set of 100 records requires 400 bytes of
cache. If you do not use the PROGRESS_RECID field, the cache size might be greater if the
selected unique index has a greater length than this field.
• Lookahead cursors — The DataServer caches complete records or partial records as
specified by a field list. It uses the maximum length allowed for a row as defined in the
MS SQL Server data source to calculate the record length, not the actual contents of the
record. In addition to the defined row length, the record consists of a row identifier field;
therefore, a row with a defined maximum length of 100 bytes requires 104 bytes of cache.
If a column is longer than 256 bytes, the DataServer refetches it.
In the case of joins, each record in the cache is a result of the fields selected in the join. In
addition to the record, there is a row identifier field (4 bytes) for each table involved in the join.
For example, a three-way join adds 12 bytes to the cache for each record.
You can affect the performance of a query by controlling the size of the cache when lookahead
cursors are used. As queries generate different results, they benefit from different cache sizes.
Generally, the larger the cache, the faster the performance. However, you must balance cache
size against other memory requirements for your system. Consider also that continually
adjusting cache size in an application might decrease performance as each adjustment requires
the DataServer to make several calls to the data source.
To determine the optimal cache size for a query, experiment with different values for
CACHE–SIZE and use DEBUG EXTENDED to generate cursor statistics in the dataserv.lg file that
you can examine. Aim for minimal cursor activity. The following example sets an optimal cache
size for a particular query against the sports database:
FOR EACH customer, EACH order OF customer WHERE order.ordnum GT 20
QUERY-TUNING(CACHE-SIZE 20 DEBUG EXTENDED):
4–13