INTRODUCTION:
In Strategy 9.x a new concept is introduced called Intelligent Cubes.
An Intelligent Cube is a set of data that can be shared as a single in-memory copy among many different reports created by multiple users. Rather than returning data from the data warehouse for a single report, Intelligent Cubes return sets of data from the data warehouse and saves them directly to Intelligence Server memory. The reports accessing Intelligent Cubes are called Intelligent Cube Reports, which can use all of the OLAP Services features for analysis and reporting purposes.
For details on this feature, refer to OLAP Services Guide under Product Manuals.
CACHING AND INTELLIGENT CUBES:
Like a report or document cache, an Intelligent Cube cache is only persisted to disk of the node where it is published. However, unlike report and document caches, Intelligent Cube caches can be seen in the Intelligent Cubes monitor (Under Caches > Intelligent Cubes) of all the nodes of the cluster.
The rest of the document assumes there is a two node Intelligence Server cluster with Node A and Node B configured using localized sharing method for Caches, Inbox and Intelligent Cubes.
What happens when a user executes an Intelligent Cube on Node A?
When a user executes an Intelligent Cube on Node A, it gets published on Node A and the information is broadcast to all nodes of the cluster. The cache is then filed to Node A disk and is visible on the Intelligent Cubes Cache monitor of Node A with a status of A, L, F as seen below:
'F' stands for Filed and indicates that the cache is backed up to the disk of the local node.
When the user logs on Node B, the same cache can also be seen on the Intelligent Cubes Cache monitor of Node B with a status of A, D, as seen below:
'D' stands for Dirty and indicates that a newer version of the cube exists in memory and is not written to disk yet.
Note: The way to change the status flag from 'D' to 'F' is to file this cache instance to the disk of Node B.
But persisting caches to remote nodes is not possible by design, so users will see the cache on Node B with a status of 'D' until they restart the Intelligence Server nodes. After a restart the 'D' flag will change to 'F'.
What happens when a user runs a subset report on Node B, based on the above Intelligent Cube?
When users execute an Intelligent Cube Report on Node B, based on the Intelligent Cube above, the Intelligent Cube cache file from Node A's disk will be loaded into Node B's memory and then the Intelligent Cube Report will be executed against the Intelligent Cube that exists in Node B's memory. For a subset report on Node A, based on the Intelligent Cube above, the report will use the Intelligent Cube cache from Node A and display the results to the user.
After running the subset report above, does the Hit Count of cache instances on both Node A and Node B increase?
There are two types of counters to track hit counts in Intelligent Cubes:
1. Hit Count - This count tracks how many times the in-memory version of the Intelligent Cube cache is hit. This count is not shared across nodes of the cluster. It is local to the node and is reset every time the cube is unloaded/loaded.
2. Historical Hit Count - This count tracks the total cumulative number of times a cube instance is hit and is not reset when the cube is unloaded/loaded. Administrator can use the Historical Hit Count information to monitor Intelligent Cube utilization and clear out caches that are not used often. This number is currently not shared across nodes of the cluster either.
Since the user ran the Intelligent Cube Report from Node B, the Intelligent Cube Cache Monitor on Node B shows both Hit counts increasing:
And Node A's Intelligent Cube Monitor is untouched as expected.
Notes:
For details on how to set up a cluster refer to the following Strategy Knowledge Base Documents below:
KB6022: MicroStrategy Intelligence Server Cluster Configuration Guide
KB441125: How to configure Cache, Cube, Inbox, and Session Recovery file sharing for a MicroStrategy Intelligence Server cluster
KB17253: What are the steps to follow to setup the server definition for asymmetrical clustering in MicroStrategy 9.4.1 - 10.x?
KB31352
