Print      Open PDF Version of Online Help

Analytics > Designing an Analysis > About Report Performance

About Report Performance

Report performance is a concern for companies with large volumes of data and users. The larger and more sophisticated your reporting needs become, the more important the report performance is to you. Understanding how Oracle CRM On Demand efficiently compensates and processes data with caching and during different times helps you to build reports with the best performance possible.

This topic describes the in-built caching mechanism enabling fast response time as well as the expected performance during the nightly refresh and when using reporting subject areas instead of analytic subject areas. For more information about report performance, see Optimizing Performance.

About Caching

When reports and queries are run using analytic subject areas, the query results are cached. The query cache allows Oracle CRM On Demand to satisfy subsequent query requests faster without having to go back to the database. This reduction allows a faster, query-response time. In addition to a faster, query-response time, this feature conserves network resources and eliminates costly database processing. Queries do not have to be identical to take advantage of this query caching. Even a subset of a previously run query with a filter condition or the same query with less columns can use the cache generated by a previous query. Data visibility is fully respected with query caching. Because the database is updated during the incremental refresh, the query cache is purged and repopulated when a new set of queries are run subsequently.

Query caching is supported only for reports and queries using analytic subject areas. Real-time reports and queries are not enabled with query cache. However, both real-time and historical reports and queries use a Web server cache. The Web server cache is not the same as the query cache supported by Oracle CRM On Demand. The Web server cache for real-time and historical queries exists for at least for 10 minutes after being created or used, but it is purged after 60 minutes. Some queries might be purged sooner than 60 minutes, depending on the number of requests being run.

Analytic (Historical) Reports Compared to Reporting (Real-Time) Reports

Queries run using analytic (historical) subject areas are comparatively faster than queries run using reporting (real-time) subject areas. The analytic subject areas use a specialized data warehouse that is designed and optimized exclusively for analysis and reporting. However, the real-time subject areas use the database that is optimized to support the transactional activities where a low volume of records are read, written, updated extremely fast. So, when real-time subject areas are used, queries have to compete for database resources that also have to cater to the needs of transaction updates of Oracle CRM On Demand affecting the performance of both Oracle CRM On Demand and real-time queries. Due to the need to support the reporting of most current data, the real-time subject areas are not enabled with query caching, which further reduces query-performance problems even for identical queries.

Use real-time subject areas only when it is critical to get the most up-to-the-minute data, or when the historical subject areas do not meet your reporting needs.

Report Performance During the Nightly Refresh

Real-time report query performance is somewhat affected during the nightly refresh process, because the data that is being retrieved to satisfy the request is also being read by the nightly refresh process to populate the data warehouse that drives the historical subject areas. However, the performance of historical report queries is not affected during the nightly refresh process, because a snapshot of the data warehouse is taken at the start of the nightly refresh, and users are directed to that replicated copy. Upon completion of the nightly refresh, users are redirected to the refreshed data warehouse automatically. This feature is transparent to users.