Using Fusion Middleware Control to Set the User Session Log-Off Period

7-8 System Administrators Guide for Oracle Business Intelligence Enterprise Edition ■ Programmatically. The Oracle BI Server provides ODBC-extension functions for purging cache entries programmatically. These functions give you the choice and the timing flexibility of the Cache Manager with the automation of event tables. You can write your own scripts to call these functions at times that fit your needs. See Section 7.6.2, Purging and Maintaining Cache Using ODBC Procedures for more information. The parameters that control query caching are located in Fusion Middleware Control and in the NQSConfig.INI file, described in Appendix A, NQSConfig.INI File Configuration Settings. See also Section 7.7.3, Using Agents to Seed the Oracle BI Server Cache for additional information. This section contains the following topics: ■ Section 7.4.1, Query Cache Architecture ■ Section 7.4.2, Advantages of Caching ■ Section 7.4.3, Costs of Caching ■ Section 7.4.4, Cache Sharing Across Users ■ Section 7.4.5, About the Refresh Interval for XML Data Sources ■ Section 7.4.6, About the Global Cache

7.4.1 Query Cache Architecture

The query cache consists of cache storage space, cache metadata, and cache detection in query compilation. The process of the Oracle BI Server accessing the cache metadata is very fast. If the metadata shows a cache hit, then the bulk of the query processing is eliminated, and the results are immediately returned to the user. The process of adding the new results to the cache is independent of the results being returned to the user; the only effect on the running query is the resources that are consumed in the process of writing the cached results. Query cache entries are portable across different operating systems, such as Windows or UNIX, and across 32-bit and 64-bit architectures. Incompatible cache entries are automatically removed. For example, you do not have to manually remove cache files when switching between 32-bit and 64-bit systems. Note that query cache entries are not portable across different releases of Oracle Business Intelligence, such as between Version 10.1.3.2 and 11g Release 1 11.1.1. Caching occurs by default at the subrequest level, which results in multiple cache entries for some SQL statements. Caching subrequests improves performance and the cache hit ratio, especially for queries that combine real-time and historical data. To disable subrequest caching, set the NQSConfig.INI file parameter DISABLE_ SUBREQUEST_CACHING to YES. See Appendix A, NQSConfig.INI File Configuration Settings for more information.

7.4.2 Advantages of Caching

The fastest way to process a query is to skip the bulk of the processing and use a precomputed answer. With query caching, the Oracle BI Server stores the precomputed results of queries in a local cache. If another query can use those results, then all database processing for that query is eliminated. This can result in dramatic improvements in the average query response time. Managing Performance Tuning and Query Caching 7-9 In addition to improving performance, being able to answer a query from a local cache conserves network resources and processing time on the database server. Network resources are conserved because the intermediate results do not have to come over the network to the Oracle BI Server. Not running the query on the database frees the database server to do other work. If the database uses a charge back system, then it could save money in the budget as well. Another benefit of using the cache to answer a query is savings in processing time on the Oracle BI Server, especially if the query results are retrieved from multiple databases. Depending on the query, there might be considerable join and sort processing in the server. If the query is already calculated, then this processing is avoided, freeing server resources for other tasks. To summarize, query caching has the following advantages: ■ Dramatic improvement of query performance ■ Less network traffic ■ Reduction in database processing ■ Reduction in Oracle BI Server processing overhead

7.4.3 Costs of Caching

Query caching has many obvious benefits, but also certain costs: ■ Disk space for the cache ■ Administrative costs of managing the cache ■ Potential for cached results being stale ■ CPU and disk IO on server computer With cache management, the benefits typically far outweigh the costs. The following sections discuss the costs of caching.

7.4.3.1 Disk Space

The query cache requires dedicated disk space. How much space depends on the query volume, the size of the query result sets, and how much disk space that you choose to allocate to the cache. For performance purposes, a disk should be used exclusively for caching, and it should be a high performance, high reliability type of disk system.

7.4.3.2 Administrative Tasks

There are a few administrative tasks that are associated with caching. You must set the cache persistence time for each physical table appropriately, knowing how often data in that table is updated. When the frequency of the update varies, you must keep track of when changes occur and purge the cache manually when necessary. You can also create a cache event polling table and modify applications to update the polling table when changes to the databases occur, making the system event-driven. The Oracle BI Server also provides ODBC-extension functions for purging cache entries programmatically. You can write your own scripts to call these functions at the appropriate times.