OpenEdge Data Management: DataServer for Microsoft SQL Server

Block cursors on versus off
Cursors
Block cursors are the default over lookahead cursors when PRGRS_BLOCK_CURS is enabled and a
server-side cursor is needed. The switch -Dsrv PRGRS_BLOCK_CURS,0 will turn off block cursors
in MS SQL Server if you want to turn off the feature for this connection. You can always disable
block cursors for a specific query by disabling lookahead with a query tuning option:
QUERY-TUNING(NO-LOOKAHEAD). Block cursors is not a one size fits all feature. There are
application environments where the default values for block allocation sizes can result in either
under-utilization or over-utilization of memory. See the “Using the block cursor switches”
section on page 8–11 for information on tuning the amount of memory that block cursors
utilizes.
For any given query, the use of a block cursor or a lookahead cursor is mutually exclusive. In
certain circumstances, block cursors will downgrade to lookahead. These are the criteria:
• When -Dsrv BINDING,0 is set. When binding is off, block cursors are disabled.
• Predictable single record result sets—FOR FIRST/FOR LAST or dynamic find operations.
• The PRGRS_TABLE_BLOCKSIZE has been exceeded and all existing block table space is
in-use by open cursors.
• The accumulation of memory allocated to all block cursors has reached
PRGRS_MAX_BLOCKSIZE.
• The QT_CACHE_SIZE query-tuning (CACHE-SIZE) value is not larger than 2 times the
maximum row size. At least 2 rows need to fit in the result block to use a block cursor.
Note: The macro BLOCKBUF_AVAILABLE can be used to determine if the current query is or is
not using a block cursor.
Block versus lookahead cursors
Block cursors and lookahead cursors are both associated with NO-LOCK queries. These are
queries where the lock status has been explicitly set to NO-LOCK or where the lock status has been
explicitly set to SHARE-LOCK and the transaction isolation level is set to read-uncommitted.
Block cursors and lookahead cursors are mutually exclusive.
Block cursors are more efficient than lookahead cursors for the following reasons:
• The results of a query are bound directly to the area from which they are copied into the
record buffer on the client. Lookahead cursors copy out of a common bind area into the
lookahead cache and then are copied into client record buffer resulting in multiple copies
of the data.
• The fetch process used by block cursors fetches multiple rows at a time, reducing the
number of driver calls and potentially reducing the total number of network round trips to
the server.
• Block cursor memory is preallocated prior to fetching a result set, whereas lookahead
cursors post allocate memory as records are fetched from the result set.
• Block cursors are directly linked to the result set binding feature whereas lookahead
cursors have no particular dependency on whether binding or late-binding is active.
2–51