Using Fusion Middleware Control to Set Query Cache Parameters

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

7.6.1.2 Caching and Cache Persistence Timing for Specified Physical Tables

You can set a cacheable attribute for each physical table, enabling you to specify whether queries for that table are added to the cache to answer future queries. If you enable caching for a table, then any query involving the table is added to the cache. All tables are cacheable by default, but some tables might not be good candidates to include in the cache unless you use the Cache Persistence Time settings. For example, suppose that you have a table that stores stock ticker data that is updated every minute. You could use the Cache Persistence Time settings to purge the entries for that table every 59 seconds. You can also use the Cache persistence time field to specify how long the entries for this table should be kept in the query cache. This is useful for data sources that are updated frequently. To set the caching attributes for a specific physical table: 1. In the Administration Tool, in the Physical layer, double-click the physical table.

2. In the Physical Table properties dialog, in the General tab, make one of the

following selections: – To enable caching, select Cacheable. – To prevent a table from being cached, deselect Cacheable.

3. To set a cache expiration time, specify a Cache persistence time and specify a unit

of measure days, hours, minutes, or seconds. If you do not want cache entries to automatically expire, select Cache never expires.

4. Click OK.

7.6.1.3 Configure Oracle BI Server Event Polling Tables

Oracle BI Server event polling tables store information about updates in the underlying databases. An application such as one that loads data into a data mart could be configured to add rows to an event polling table each time a database table is updated. The Oracle BI Server polls this table at set intervals and invalidates any cache entries corresponding to the updated tables. Event polling tables can be the sole method of cache management, or they can be used with other cache management schemes. Event tables offer less flexibility about choice of cache entries and the timing of purges. See Section 7.8.1, Setting Up Event Polling Tables on the Physical Databases for more information about event polling tables.

7.6.2 Purging and Maintaining Cache Using ODBC Procedures

The Oracle BI Server provides ODBC-extension functions for purging cache entries. Some of these functions are particularly useful for embedding in an Extract, Transform, and Load ETL task. For example, after a nightly ETL is performed, all Oracle BI Server cache entries can be purged. If only the fact table was modified, then only cache related to that table can be purged. In some cases, you might need to purge the cache entries associated with a specific database. Only administrators have the right to purge cache. Therefore, scripts that call these ODBC-extension functions must run under credentials with administrator privileges. The following ODBC functions affect cache entries that are associated with the repository specified by the ODBC connection: Managing Performance Tuning and Query Caching 7-17 ■ SAPurgeCacheByQuery. Purges cache entries that exactly match a specified query. For example, using the following query, you would have one or more query cache entries that retrieve the names of all employees earning more than 100,000: SELECT lastname, firstname FROM employee WHERE salary 100000; The following call purges the cache entries that are associated with this query: Call SAPurgeCacheByQuerySELECT lastname, firstname FROM employee WHERE salary 100000 ; ■ SAPurgeCacheByTable. Purges all cache entries that are associated with a specified physical table name fully qualified for the repository to which the client has connected. This function takes up to four parameters that represent the four components database, catalog, schema, and table name proper of a fully qualified physical table name. For example, you might have a table with the fully qualified name of DBName.CatName.SchName.TabName. To purge the cache entries that are associated with this table in the physical layer of the Oracle Business Intelligence repository, run the following call in a script: Call SAPurgeCacheByTable DBName, CatName, SchName, TabName ; ■ SAPurgeAllCache. Purges all cache entries. The following is an example of this call: Call SAPurgeAllCache; ■ SAPurgeCacheByDatabase. Purges all cache entries associated with a specific physical database name. A record is returned when any of the ODBC procedures to purge the cache are called. This function takes one parameter that represents the physical database name, and the parameter cannot be null. The following shows the syntax of this call: Call SAPurgeCacheByDatabase DBName ;

7.6.2.1 About ODBC Procedure Syntax

If there is a single quotation mark within the string argument of a procedure, then you must use another single quotation mark to escape it. For example: Call SAPurgeCacheByQuerySELECT TOPN- Currency.Markdown , 10 saw_0, XX Line.Order No saw_1, - Bill-To Site.Customer Name saw_2, - Currency.Net USD saw_3, - Currency.Markdown USD saw_4, - Currency.Markdown saw_5 FROM Apps 11i - XX Lines WHERE XX Line.Open Flag = Y AND Operating Unit.Group Name = Group AND - Currency.Net USD = 10000 ORDER BY saw_0; The line in bold highlights the extra single quotation marks that are used as escape characters for the items Y and Group. Note: Wildcards are not supported by the Oracle BI Server for this function. In addition, DBName and TabName cannot be null. If either one is null, then an error message is displayed.