OpenEdge Data Management: DataServer for Microsoft SQL Server

Chapter 4: Additional Features to Enhance DataServer Performance
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):
174 OpenEdge Data Management: DataServer for Microsoft SQL Server