Additional configuration parameter used to manage automatic cube dependencies in IBM Cognos TM1
The default setting of the AutomaticallyAddCubeDependencies configuration parameter has changed. AutomaticallyAddCubeDependencies determines if cube dependancies are set automatically or if you must manually identify the cube dependencies for each cube.
Understanding cube dependency
IBM® Cognos® TM1® server establishes dependencies so it can properly invalidate cube caches.
The following definitions describe the interrelationships established for different cubes in IBM Cognos TM1. A simple example helps define these relationships:
For Cube A:
Cube A has a rule: [..] = DB( ‘B’, … );
This means that a value in cube A may change when there is a change in cube B since the value of a cell in cube A is computed based on the value of a cell in cube B. Therefore cube A is "dependent" on cube B.
When data changes in cube B, any cached calculations for cube A must be discarded since they are no longer valid.
There are two definitions that describe this relationship:
Cube A is "dependent" on cube B.
Cube B is a "supporting cube" of cube A.
Why Cognos TM1 uses dependencies
The IBM Cognos TM1 server establishes dependencies so it can properly invalidate cube calculation caches when data in cubes is changed. In the previous example, when a value in cube B changes, any calculation cache for cube A must be discarded since the calculation may depend on a value in B which has changed.
Dependencies are established when a rule is run and that rule references a value from another cube. A dependency can be established to one or many cubes based on the scope of the rule. In the previous example, when a value for the cell in cube A is requested, the rule will be run, and the dependency of cube A on cube B will be established.
Changes in dependency mapping
IBM Cognos TM1 9.4.1 FP3 introduced a change to the dependency mapping to make Cognos TM1 more stable and to perform better.
There is an artifact of this change that users upgrading to Cognos TM1 9.4.1 FP3 and above should understand. In previous releases, this dependency map between cubes was established when rules were executed that referenced other cubes. However, these dependencies were cleared when there was any invalidation between the cubes and these dependencies would again be re-established once the rule was run to establish the dependency.
Dependency behavior now follows these rules:
- Dependencies once established are NOT cleared based on data invalidation.
- Cube dependencies can be established ahead of time using the AddCubeDependency TM1 ICAS function.
To make a dependency change, an "exclusive" or "write" lock on the cube was acquired.
This write lock blocks all other readers and writers from querying the cube. This lock persists for the duration of the operation which caused the new dependency to be established .
For fast queries, this impact is minimal and a one time "cost" for each cube-to-cube dependency.
For slower queries that establish new dependencies, other users may be blocked for long periods of time until the dependency-creating operation finishes.
In complex applications, the cube may be locked many times initially as users execute only certain rules, each of which establishes a new dependency.
Once a dependency is established, that dependency is used for cube calculation cache invalidation when a supporting cube changes. Thus, the more dependencies that are established, the more invalidations that will occur.
Clearing cube dependencies
The following table describes the Cognos TM1 events or actions that destroy a cube's dependency.
|Server Shutdown||Cube dependency lists are destroyed.|
|Rule Compile (Note: any dimension update causes a rule compile.)||Eliminates only those cubes where rules have been deleted or modified.|
When cube dependencies are cleared, depending on the application and the level of user activity, you may want to establish those cube dependencies manually.
Using AddCubeDependency to establish dependencies
The AddCubeDependency TurboIntegrator function is used to create a manual dependency between two cubes.
In normal operations, cube dependencies are established when data which crosses cube boundaries (such as data that is derived by a rule that references an external cube) is retrieved. To create the dependency information, the server must lock the cubes while the dependency is established, potentially maintaining the lock during a long view calculation. Since this is a "write" lock, other users are prevented from accessing the cubes. The AddCubeDependency TurboIntegrator function is run prior to any data access action that would normally trigger a rule and generate a new dependency. Using AddCubeDependency prevents later lock contention by establishing the dependency ahead of time.
|SupportingCube||The name of the cube upon which the DependentCube is dependent. This is the source of data used within a rule of the Dependent Cube.|
|DependentCube||The name of a cube that depends on another cube for data. Typically this is a cube that uses rules to pull data from the Supporting Cube.|
Cube ‘SalesCube’ has a rule:
[‘net’]=!Units * DB(‘PriceCube’, … );
This makes the ‘SalesCube’ dependent on values in the ‘PriceCube’. To pre-establish this dependency run the AddCubeDependency() function
AddCubeDependency( ‘PriceCube’, 'SalesCube' );
This example establishes that the SalesCube depends on the PriceCube.
Further dependency enhancements
Enhancements have been made to this functionality to help establish dependencies without any manual intervention.
In the TM1 10.1 and 9.5.2 FP2 releases, additional enhancements are available to better establish dependencies without any manual intervention.
In these versions of IBM Cognos TM1, because the rules are compiled at server startup time, the inter-cube dependencies for standard "DB(…)" functions in rules can be established automatically.
Establishing these dependencies at startup time means that the dependencies need not be established as a query is running. The result is that one query does not block others because of a new dependency.
A new Tm1s.cfg configuration parameter called AutomaticallyAddCubeDependencies was added to control this feature. AutomaticallyAddCubeDependencies can be set to true or false.
In 9.5.2 FP2, this parameter is by default set to "false". In this case, rule based inter-cube DB(…) dependencies are not detected and set at server startup time. You must edit the Tm1s.cfg file and set the parameter to "true" to detect and set inter-cube dependencies at server startup time.
In the 10.1 version of the product this parameter is by default set to "true". In that case, rule based inter-cube DB(…) dependencies are detected and set automatically at server startup time.
For 10.1, set this parameter to "false" to disable this functionality.
In 10.1 the automatic establishment of cube dependencies also includes the dependencies created from the attribute functions ATTRN() and ATTRS(), which establish a dependency between a cube and the supporting attributes cube for a dimension of the dependent cube.
In 10.1, if the parameter AutomaticallyAddCubeDependencies is true, after a rule edit/save/recompile, the dependencies expressed in that rule, whether from DB(), ATTRS(), or ATTRN() functions, are automatically re-established. Normally a rule re-compile would clear the dependencies for a cube.
Debugging and identifying cube dependencies
Using TurboIntegrator to preset dependencies may be necessary.
To identify existing cube dependencies requires an in-depth understanding of an application so that you can analyze all of the rules for each cube including control cubes. Even when you have that level of knowledge about an application, it is important to turn on the following logging capability to identify cube dependencies as they are established.
For example, when the following command is added to the the tm1s-log.properties file:
The following information is returned that identifies dependencies:
INFO 2010-06-09 18:09:23.728 TM1.Cube.Dependency
Adding cube dependency: cube
"}ElementSecurity_}Cubes" depends on cube "}CubeSecurity"
The TurboIntegrator command to establish this dependency is: