About ODBC Procedure Syntax

7-20 System Administrators Guide for Oracle Business Intelligence Enterprise Edition

7.6.3 How Repository Changes Affect the Query Cache

When you modify Oracle Business Intelligence repositories, the changes can have implications for entries that are stored in the cache. For example, if you change the definition of a physical object or a dynamic repository variable, cache entries that reference that object or variable might no longer be valid. These changes might result in the need to purge the cache. There are three scenarios to be aware of: when the changes occur in online mode, when they occur in offline mode, and when you are switching between repositories.

7.6.3.1 Online Mode

When you modify an Oracle Business Intelligence repository in online mode, any changes that you make that affect cache entries automatically result in a purge of all cache entries that reference the changed objects. The purge occurs when you check in the changes. For example, if you delete a physical table from a repository, then all cache entries that reference that table are purged upon check in. Any changes made to a business model in the Business Model and Mapping layer purge all cache entries for that business model.

7.6.3.2 Offline Mode

When you modify an Oracle Business Intelligence repository in offline mode, you might make changes that affect queries that are stored in the cache and render those cached results obsolete. Because the repository is not loaded by the server during offline mode edits, the server has no way of determining if the changes made affect any cached entries. The server therefore does not automatically purge the cache after offline changes. If you do not purge the cache, then there might be invalid entries when the repository is next loaded. Unless you are sure that there are no entries in the cache that are affected by your offline changes, then you should purge the cache for any business model that you have modified.

7.6.3.3 Switching Between Repositories

If you intend to remove a repository from the configuration of the Oracle BI Server, then ensure that you purge the cache of all cache entries that reference the repository. Failure to do so results in a corrupted cache. See Section 7.7.4.2, Purging Cache in the Administration Tool for more information.

7.6.3.4 Changes to Dynamic Repository Variables

The values of dynamic repository variables are refreshed by data that is returned from queries. When you define a dynamic repository variable, you create an initialization block or use a preexisting one that contains a SQL query. You also configure a schedule for the Oracle BI Server to follow to execute the query and periodically refresh the value of the variable. When the value of a dynamic repository variable changes, all cache entries that are associated with a business model that reference the value of that variable are purged automatically. The cache entries are purged when the repository variable refresh rate is reached, if its value has changed. Note that if a business model is not associated with a changed dynamic repository variable, then no cache purging action occurs. For example, suppose an initialization block has been defined with a repository variable and a refresh rate of 5 minutes. But, no logical column has been defined that references the variable. When the value of the dynamic repository variable changes, cache is not purged because no logical column exists within a business model that uses the variable. Managing Performance Tuning and Query Caching 7-21

7.7 Strategies for Using the Cache

One of the main advantages of query caching is to improve apparent query performance. It might be valuable to seed the cache during off hours by running queries and caching their results. A good seeding strategy requires that you know when cache hits occur. To seed the cache for all users, then you might seed the cache with the following query: SELECT User, SRs After seeding the cache using SELECT User, SRs, the following queries are cache hits: SELECT User, SRs WHERE user = valueofnq_SESSION.USER and the user was USER1 SELECT User, SRs WHERE user = valueofnq_SESSION.USER and the user was USER2 SELECT User, SRs WHERE user = valueofnq_SESSION.USER and the user was USER3 This section contains the following topics: ■ Section 7.7.1, About Cache Hits ■ Section 7.7.2, Running a Suite of Queries to Populate the Cache ■ Section 7.7.3, Using Agents to Seed the Oracle BI Server Cache ■ Section 7.7.4, Using the Cache Manager

7.7.1 About Cache Hits

When caching is enabled, each query is evaluated to determine whether it qualifies for a cache hit. A cache hit means that the server was able to use cache to answer the query and did not go to the database at all. The Oracle BI Server can use the query cache to answer queries at the same or higher level of aggregation. Many factors determine whether cache is hit. Table 7–3 describes these factors.