Release 10.1A: OpenEdge Data Management:
DataServer for ODBC

> ## Caching records

> The DataServer caches results sets from an ODBC data source to enhance performance. It caches as much data as fits in its allocated cache size. Depending on what kind of cursor a query is using, the DataServer caches row identifiers or records:

> - Standard cursors — The DataServer caches row identifiers (a `PROGRESS_RECID` column or other index) for the results set. Each identifier requires 4 bytes of cache; therefore, a results set of 100 records requires 400 bytes of cache.

> - 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 ODBC 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. 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 ord-num > 20
>       QUERY-TUNING(CACHE-SIZE 20 DEBUG EXTENDED):

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095