Online Mode How Repository Changes Affect the Query Cache

Managing Performance Tuning and Query Caching 7-23

7.7.1.1 Ensuring Correct Cache Results When Using Row-Level Database Security

When using a row-level database security strategy, such as a Virtual Private Database VPD, the returned data results are contingent on the authorization credentials of the user. Because of this, the Oracle BI Server must know whether a data source is using row-level database security and which variables are relevant to security. To ensure that cache hits only occur on cache entries that include and match all security-sensitive variables, you must correctly configure the database object and session variable objects in the Administration Tool, as follows: ■ Database object. In the Physical layer, in the General tab of the Database dialog, select Virtual Private Database to specify that the data source is using row-level database security. If you are using row-level database security with shared caching, then you must select this option to prevent the sharing of cache entries whose security-sensitive variables do not match. Session variable values must match, including security session variables If the logical SQL or physical SQL statement refers to any session variable, then the session variable values must match. Otherwise, the cache is not hit. In addition, the value of session variables that are security sensitive must match the security session variable values that are defined in the repository, even though the logical SQL statement itself does not reference session variables. See Section 7.7.1.1, Ensuring Correct Cache Results When Using Row-Level Database Security for more information. Equivalent join conditions The resultant joined logical table of a new query request has to be the same as or a subset of the cached results to qualify for a cache hit. DISTINCT attribute must be the same If a cached query eliminates duplicate records with DISTINCT processing for example, SELECT DISTINCT..., then requests for the cached columns must also include the DISTINCT processing; a request for the same column without the DISTINCT processing is a cache miss. Queries must contain compatible aggregation levels Queries that request an aggregated level of information can use cached results at a lower level of aggregation. For example, the following query requests the quantity sold at the supplier and region and city level: SELECT supplier, region, city, qtysold FROM suppliercity The following query requests the quantity sold at the city level: SELECT city, qtysold FROM suppliercity The second query results in a cache hit on the first query. Limited additional aggregation For example, if a query with the column qtysold is cached, then a request for RANKqtysold results in a cache miss. Additionally, a query that requests qtysold at the country level can get a cache hit from a query that requests qtysold at the country, region level. ORDER BY clause must be comprised of columns in the select list Queries that order by columns that are not contained in the select list result in cache misses. Avoiding cache misses using advanced hit detection You can avoid some cache misses by setting the parameter USE_ADVANCED_HIT_ DETECTION to YES in the NQSConfig.INI file. Advanced hit detection enables an expanded search of the cache for hits. See USE_ADVANCED_HIT_DETECTION for more information. Table 7–3 Cont. Factors That Determine Whether Cache Is Hit Factor or Rule Description