IBM Cognos Dynamic Cubes

30 IBM Cognos Dynamic Cubes

2.3.3 Member cache

The hierarchies defined in a cube model are all loaded into memory when the cube starts.

After all hierarchies are loaded, the following actions occur simultaneously:

򐂰 The cube state is changed to available and it is able to respond to metadata and data

queries.

򐂰 If a cube has a startup trigger defined, it is executed.

򐂰 If a cube has in-memory aggregates defined, and space allotted for them, the queries to

retrieve the data are executed.

Members of each hierarchy are retrieved by running a SQL statement to retrieve all of the

attributes for all levels within a hierarchy, including multilingual property values, and are stored

in memory. The parent-child and sibling relationships inherited in the data are used to

construct the hierarchical structure in memory.

All metadata requests by the client application, the DMQ query planning engine, and all

member functions (for example, PARENT, CHILDREN) are serviced from the in-memory

cache. Cognos Dynamic Cubes will never pose a query to retrieve member attribute values

after the member cache is loaded.

Queries that are posed by Cognos Dynamic Cubes to retrieve data to populate its data cache

make use of the level key values stored in the member cache as the basis for constructing

filters in the SQL queries that are posed to the underlying relational database.

2.3.4 Aggregate cache

IBM Cognos Dynamic Cubes supports two types of pre-computed aggregate values: those

stored in database tables and those stored in its in-memory aggregate cache. Though

database tables that contain aggregate values (referred to as

summary or aggregate tables)

may pre-exist within a data warehouse, the Aggregate Advisor within the IBM Cognos

Dynamic Query Analyzer (DQA) can be used to suggest additional aggregate tables to

improve query performance.

In addition to suggesting database aggregate tables, the Aggregate Advisor can also suggest

a collection of in-memory aggregates that will also improve query performance. One primary

difference between the two types of aggregates is that the in-memory aggregates do not

require the involvement of the relational database DBA; the Aggregate Advisor

recommendations can be stored in CM and take effect the next time a cube is started.

As with in-database aggregate tables, in-memory aggregates contain measure values that

are aggregated by the members at the level of one or more hierarchies within the cube. These

values can be used to provide values at precisely the same level of aggregation. In the case

of measures with distributive aggregation rules (SUM, MAX, MIN, and COUNT), in-memory

aggregates can be used to compute values at a higher level of aggregation.

Difference between aggregate types: In-database aggregates are usually built during a

predefined ETL processing “window.”

In-memory aggregates are built during cube-start,

which suggests that cubes should be started during, or immediately after, the ETL process.

The number of queries posed concurrently to populate the in-memory aggregate cache

can be controlled by an advanced property of Cognos Dynamic Cubes to ensure the

underlying relational database is not saturated with concurrent requests computing

summary values.