Using Fusion Middleware Control to Set the Maximum Number of Rows Processed to Render a Table

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. 7-10 System Administrators Guide for Oracle Business Intelligence Enterprise Edition

7.4.3.3 Keeping the Cache Up To Date

If the cache entries are not purged when the data in the underlying databases changes, then queries can potentially return results that are out of date. You must evaluate whether this is acceptable. It might be acceptable to allow the cache to contain some stale data. You must decide what level of stale data is acceptable and then configure and follow a set of rules to reflect those levels. For example, suppose an application analyzes corporate data from a large conglomerate, and you are performing yearly summaries of the different divisions in the company. New data does not materially affect the queries because the new data affects only next years summaries. In this case, the trade-offs for deciding whether to purge the cache might favor leaving the entries in the cache. Suppose, however, that the databases are updated three times a day and you are performing queries on the current days activities. In this case, you must purge the cache much more often, or perhaps consider not using the cache at all. Another scenario is that you rebuild the data mart from the beginning at periodic intervals for example, once per week. In this example, you can purge the entire cache as part of the process of rebuilding the data mart, ensuring that you never have stale data in the cache. Whatever your situation, you must evaluate what is acceptable for noncurrent information returned to the users.

7.4.3.4 CPU Usage and Disk IO

Although usually it is very minor, query caching does require a small amount of CPU time and adds to the disk IO. In most cases, the CPU usage and disk IO is insignificant. The disk IO might be noticeable only when queries return large data sets.

7.4.4 Cache Sharing Across Users

If shared logon has been enabled for a particular connection pool, then the cache can be shared across users and does not need to be seeded for each user. If shared logon has not been enabled and a user-specific database login is used, then each user generates their own cache entries. See Oracle Fusion Middleware Metadata Repository Builders Guide for Oracle Business Intelligence Enterprise Edition for information about enabling shared logon for connection pools.

7.4.5 About the Refresh Interval for XML Data Sources

Typically, XML data sources are updated frequently and in real time. Setting a refresh interval for XML data sources is analogous to setting cache persistence for database tables. The refresh interval is a time interval after which the XML data sources are to be queried again directly, rather than using results in cache. This refresh interval is specified on the XML tab of the Connection Pool dialog. The default interval setting is Infinite, meaning that the XML data source is not automatically refreshed. The refresh interval setting determines the time interval after which the Oracle BI Server XML Gateway connection is refreshed, as follows: ■ For URLs that begin with http: or https:, the gateway is refreshed when it detects that the interval has expired.