SQL Cursor Cache

The SQL cursor cache is configured using the DSMaxCachedCursors parameter. This cache can be enabled on multithreaded components (such as Siebel Application Object Manager) with database connection pooling. The value represents the number of SQL cursors per database connection.

For a Siebel Application Object Manager for which the Siebel Server computer is more likely to reach its memory capacity before it reaches its CPU capacity (for example, for Siebel Call Center), you can set DSMaxCachedCursors to a low value, even to 0. (Such an application is sometimes referred to as memory-bound.)

For a Siebel Application Object Manager for which the Siebel Server computer is more likely to reach its CPU capacity before it reaches its memory capacity, the default value of 16 for the DSMaxCachedCursors parameter might be appropriate. (Such an application is sometimes referred to as CPU-bound.)

In general, the value must reflect the CPU and memory resource availability on the Siebel Server computer running a particular Siebel Application Object Manager component. The trade-off in setting this parameter is that allocating memory to caching SQL cursors means that they would need to be created less often, but at a cost in memory.

The memory requirement per cursor depends on factors such as the size of the query, type of database connection, row size, and number or rows returned by the query. The utility of these cached cursors depends on the uniqueness of the queries that they represent. In general, most Siebel application queries are unique and would not benefit from reusing a cached cursor.

Generally, when more users share a database connection, through connection pooling, you would increase the number of cursors cached, provided that the required memory is available. For more information about database connection pooling, see Configuring Database Connection Pooling for Siebel Application Object Managers.