Chapter 8. Optimization and performance tuning 241
heap size and cache size considerations, see Understanding Hardware Requirements for
Cognos Dynamic Cubes at the business analytics proven practices website:
https://www.ibm.com/developerworks/analytics/practices.html
To use the aggregate cache, run the Aggregate Advisor to get and save recommendations for
in-memory aggregates, and enable the aggregate cache by specifying enough memory for
the corresponding cube setting, as described in 8.4.2, “Loading in-memory aggregates into
the aggregate cache” on page 221. At the core of the Aggregate Advisor logic is a
model-based evaluation that uses heuristics to analyze potential slices of the cube to
recommend aggregates that balances coverage with effective size. Running the Aggregate
Advisor to consider workload information in the workload log will significantly weigh the
measures and slices that are actually hit by users so that the aggregate recommendations
are likely to be more reflective of query usage of the data.
As described in 8.4.2, “Loading in-memory aggregates into the aggregate cache” on
page 221, in-memory aggregates can take some time to load, so make sure that the cube
start is initiated during, or immediately after, the underlying database ETL process to allow
enough time for the load and to provide optimal query performance to users.
8.6.2 Priming the caches
Cognos Dynamic Cubes cache-priming involves running a set of reports to populate the result
set cache, expression cache, and data cache to accelerate query performance for users. This
technique can be used to optimize specific reports, especially if they compute lots of values or
it is more efficient to cache certain information in a targeted way rather than relying on large
aggregates.
The reports that are used for cache-priming can be those from a known set of dashboards
and reports that a majority of users will use, or those that process large volumes of data to
cache upfront for reuse by multiple users. For example, if there are a set of dashboards or
reports that most users use as a starting point, these are good candidates for priming so that
all users can benefit from the quick performance that cached values can provide.
The result set cache, expression cache, and data cache are populated in response to
incoming queries, so cube administrative commands such as Refresh Data Cache and
Refresh Member Cache will clear these caches, and incoming queries will miss the cache
until they are repopulated by queries. These caches are gradually populated as user queries
are run and can be used after the values are stored. However, query performance is not as
optimal as compared to when the caches have the relevant data available. The reason is
because there might be longer response times as a result of possible data queries to the
underlying data source or the processing of large volumes of data.
After a cache refresh, cache repopulation can occur naturally in response to user queries, or
proactively by scheduling priming reports to run immediately after cache refresh. Note that
refreshing the data cache also refreshes the aggregate cache. The aggregate cache initiates
its preloading automatically. Depending on the nature of the priming reports, running these
priming reports after the aggregate cache completes loading might be better so that these
reports can also use the aggregate cache and not compete for the same underlying
resources.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.