Chapter 2. IBM Cognos Dynamic Cubes architecture 25
? The data caches of the different instances of a cube are not synchronized, so if a user
executes a query on one machine and another, query response can fluctuate.
? The underlying database might encounter additional load because each instance of a
cube is required to load data independently of the other node.
? The dispatcher is not knowledgeable of dynamic cubes, therefore it does not account for
whether a cube is available under a particular dispatcher when dispatching a request for
execution. Consequently, extra steps are required to ensure cubes are taken on and off
line on individual dispatchers to ensure users do not encounter error messages to the
effect that a cube is unavailable.
2.2.2 Dynamic cubes within the Dynamic Query Mode server
Dynamic cubes exist in memory within the DQM server. A dynamic cube, when running within
DQM, involves the following cache:
? An in-memory member cache
The members of each hierarchy are retained in memory that allows for the traversal of
parent-child relationships, and level relationships. This cache is used during DQM query
planning to validate member-unique names, and during query execution to perform
member and set operations, which do not require the evaluation of measure values, for
example, MEMBERS([Level Name]).
? An in-memory aggregate cache
If in-memory aggregate recommendations from the Aggregate Advisor are published to
CM and the cube that is configured to assign memory for in-memory aggregates, the cube
will retain the aggregate values in separate
cubelets in a separate cache, up to the amount
of space specified in the configuration for the cube.
? An in-memory data cache
Any queries that retrieve data from the underlying database, or further aggregate data
from the aggregate cache, are stored as cubelets in a separate cache.
? An in-memory security cache
Every unique combination of security views is retained in memory to provide efficient
application of security filters to queries.
26 IBM Cognos Dynamic Cubes
Figure 2-21 shows the various caches in a Dynamic Cube.
Figure 2-21 The various caches in a Dynamic Cube
These structures are retained in a cube construct within, but separate from, the remainder of
DQM. The DQM server interacts with a Dynamic Cube in three ways:
? Administrative commands
? Metadata requests
? Query execution
Administrative commands may be received either through Java Management Extensions
(JMX) or BI bus commands (typically from Cognos SDK applications). These administrative
commands are directed by DQM to the Cognos Dynamic Cubes management interface,
which in turn directs the requests to the specified cube to perform such operations as stop,
start, and so on.
Metadata requests typically are posed by either BI client applications to populate the
metadata browser, or by the DQM query planner, which interacts with a cube to obtain various
pieces of metadata to validate a metadata references of a request.
The DQM server converts queries that it receives into MDX queries, which are then run by
DQM’s own MDX engine. During the running of an MDX query, the MDX engine might need to
perform member operations such as obtaining the children of a member, and does so through
the metadata interface of a cube. The MDX engine might also require measure values, which
it will request through an interface called the
query strategy.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.