Introduction | Information Center
Tuning Parameter | Description |
---|---|
Maximum Concurrent Connections |
The maximum number of concurrent connections to this IBM Alphablox cube. The limit is reached only when the connections are all executing queries simultaneously. When the limit is reached, a new connection must wait for a free connection. |
Data Source Connection Pooling |
Connection pooling for IBM Alphablox cubes can be enabled by selecting the Connection Pooling Enabled check box in the Data Source Connection Pooling group. When connection pooling is enabled, you should also specify the maximum number of persistent connections that can be made to the underlying relational database. The default value for Maximum Persistent Connections is 10. When the specified number of connections is reached, a new connection must wait for a free database connection. When using this limit, once each connection is opened it remains open (up to the specified maximum number of persistent connection) for use by other SQL queries. When Connection Pooling Enabled is not selected, each query uses and then closes a separate connection. Note: Although connection pooling is available using this setting in the IBM Alphablox Cube Server, this setting is primarily useful for IBM Alphablox installations on Apache Tomcat 3.2.4, where connection pooling is not available. For IBM Alphablox installations on WebSphere and WebLogic servers, you should use the connection pooling capabilities of the application server. To use connection pooling on your WebSphere or WebLogic servers, you need to use the Application Server Adapter option when defining IBM Alphablox relational data source definitions. See your application server documentation for details on configuring connection pooling with supported data sources. |
Data Cache |
By default, the Unlimited option is selected for the data cache associated with the selected IBM Alphablox cube. To restrict the size of the data cache for the selected cube, you can uncheck the Unlimited option and then specify the maximum size (number of rows) of the data cache to be stored in the IBM Alphablox Cube Server’s in-memory data cache. After the maximum size is reached, the results from the least recently used cached queries are aged out of the cache to make room for the new rows. Optionally, you can specify an MDX query in the Cache seeding query (optional) field. By default, no seeding query is specified. To enable the optional query, you must also select the Enabled option. The query entered in this text box executes when the cube is started or rebuilt. This query will populate the IBM Alphablox Cube Server in-memory cache with an initial set of results. These results seed the cache with data retrieved from the underlying database. Any subsequent IBM Alphablox cube queries requiring only data that is already in the IBM Alphablox Cube Server cache are answered directly from the cache, thus improving response time by avoiding additional SQL queries to the underlying database. The name of the cube referenced in the FROM clause of the MDX query must be the name previously defined in the IBM Alphablox Cube Name text box. |
Member Cache |
By default, the Static (All members loaded into memory) option is selected and all members will be loaded into the member cache. Optionally, you can choose the Dynamic (Members loaded into memory as needed) option and members will be loaded into the member cache only as they are needed. If this dynamic member cache option is selected, the default maximum size (number of members) is set to 100,000. You can choose another non-zero value, or select the Unlimited option, loading all members into the data cache memory as they are needed. For more information on member caching, see Member Cache Directory Path section of the Using the IBM Alphablox Cube Manager page. |