Showing posts with label Cache. Show all posts
Showing posts with label Cache. Show all posts

Thursday, June 28, 2012

Purging Cache


Purging cache is the process of deleting entries from the query cache. You can purge cache entries
in the following ways:

1. Manually, using the Administration Tool Cache Manager facility (in online mode).
2. Automatically, by setting the Cache Persistence Time field in the Physical Table dialog box for a particular       table.
3. Automatically, by setting up an Oracle BI Server Event Polling Table.
4. Automatically, as the cache storage space fills up.
5. Using the ODBC functions.

How Cache System handles Making Changes to a Repository


When you modify an Oracle BI repository in online mode, any changes you make that will 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, 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 will purge all cache entries for that 
business model.

Online Mode
When you modify an Oracle BI repository in online mode, any changes you make that will 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,
1. If you delete a physical table from a repository, all cache entries that reference that table are purged upon check in.
2. Any changes made to a business model in the Business Model and Mapping layer will purge all cache entries for that business model.

Note : In Business Model, if you made any changes like deleting any logical column, renaming a logical column etc. will result in purge of all cache entries for that business model automatically.

Offline Mode
When you modify an Oracle BI repository in offline mode, you might make changes that affect queries 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, 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, you should purge the cache for any business model you have modified.

Switching Between Repositories
If you intend to remove a repository from the configuration of the Oracle BI Server, make sure to purge the cache of all cache entries that reference the repository. Failure to do so will result in a corrupted cache.

Friday, June 22, 2012

Best Practices for Cache in OBIEE


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 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.

Administrative Tasks
There are a few administrative tasks associated with caching. You need to 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 need to 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.

The ODBC functions are :
SAPurgeCacheByQuery()
SAPurgeCacheByTable()
SAPurgeCacheByDatabase()
SAPurgeAllCache()

Keeping the Cache Up To Date
If the cache entries are not purged when the data in the underlying databases changes, queries
can potentially return results that are out of date. You need to evaluate whether this is acceptable. It might be acceptable to allow the cache to contain some stale data. You need to decide what level of stale data is acceptable and then set up (and follow) a set of rules to reflect those levels.

For example, suppose your application analyzes corporate data from a large conglomerate, and you are performing yearly summaries of the different divisions in the company. New data is not going to materially affect your queries because the new data will only affect next year’s summaries. In this case, the tradeoffs for deciding whether to purge the cache might favor leaving the entries in the cache.

Suppose, however, that your databases are updated three times a day and you are performing
queries on the current day’s activities. In this case, you will need to purge the cache much more
often, or perhaps consider not using it at all.

Whatever your situation, you need to evaluate what is acceptable as far as having noncurrent
information returned to the users.


Caches in OBIEE

Main Caches in OBIEE : 
Other Caches in OBIEE : 
  • QUERY_PLAN
  • DRILLDOWN_INFO
  • DRILLDOWN_QUERY
  • session variable via a INIT_BLOCK
Session variable
If you use the row-wise initialization, the result of the query can be cached in the main memory

cache of OBIEE server.

.

Query Cache Architecture

The query cache consists of cache storage space, cache metadata, and cache detection in query
compilation.
The process of accessing the cache metadata is very fast. If the metadata shows a cache hit, 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 consumed in the process of writing the cached results.

When a user request a query, the Presentation Server translate the query into Logical Query and send it to the BI Server. The BI Server searches the Cache Metadata for a matched Logical Query. If the matched Logical query is found (called as Cache Hit), then the results are retrieved from Query Cache by BI Server and sent it to Presentation Server. If the matched query is not found, then the BI server will generate the Physical Query and send it to the underlying Database. The Database processes the physical query and return the result to the BI Server, the Bi Server will send back the result set to Presentation Server and at the same time store the result set in the Query Cache.



Query Cache in OBIEE


The Oracle BI Server can save the results of a query in cache files and then reuse those results later when a similar query is requested. So, for any query request, the database processing is required only once, not every time the query is run.

When a user requests any query, BI Presentation Server generates Logical Query and handover it to the BI server.[Before handover the Logical SQL to BI Server, the Presentation Server checks the Presentation Server cache for similar Logical SQL. If found, the Presentation Server will get the result from that cache and return to the user without contacting the BI Server. Read more...] Then, the BI Server checks the disk-based cache of query result sets (query  cache). If the similar query and its result set are stored in query cache, then BI Server will retrieve the data from the query cache and return it to the Presentation Server. So, the use of cache saves database processing, processing time, and the query response time will be fast.

Advantages of Cache in OBIEE :
Dramatic improvement of query performance : BI Server stores the query results in local cache. The similar subsequent queries can use those results. So, the BI Server does not have to access the backend database. This improves the query performance.

Less network traffic and Reduction in database processing: If the result of a query is stored in a cache, then the result for a similar subsequent queries do not have to come over the network to the 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, it could save money in the budget as well.

Reduction in Oracle BI Server processing overhead : 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, this processing is avoided, freeing server resources for other tasks.

Tip : If there are more than one source tables(those tables may be resides in different sources) for a query, then BI Server will generate separate physical queries and send them to the corresponding databases and get the results. When the BI Server gets the result set, it has to do the appropriate joins and handover it Presentation Server. 

Presentation Server Cache in OBIEE

Presentation Server  has its own cache, stores the result set of queries in that cache. When the user requests any query, and if the query is similar to the one which is stored in cache memory, then the Presentation Server will retrieve the result for this query  from the cache and return the result to the user without contacting the BI Server. This improves the query response time, eliminates BI server processing time.

The files for the Presentation Services cache:
  • Have names such as nQS_xxxx_x_xxxxxx.TMP.
  • Are stored in the following directory:
         C:\OracleBIData\tmp
Refer the following link to know more about the presentation cache : 

Monday, June 11, 2012

Disable the CAche Hit to Query Cache for a particular Request.

We can disable the Cach Hit for a particular request, by overriding/Change the value of System session variable called DISABLE_CACHE_HIT  to 1 in Answers.



Bypass Oracle BI Presentation Services Cache

We can By pass the presentation cach, by selecting the check box option for Bypass Oracle BI Presentation Services Cache in Advanced tab of any Answers.