After you have published and started a dynamic cube, you can add new fact rows and update data caches in near real time using the incrementallyLoadCubes command that is available from the DCAdmin command line tool.
This command includes a transactionID parameter that you can use to specify a transaction ID (TID) value up to which to load fact data updates. If you do not specify this parameter, the incrementallyLoadCubes command runs a MAX query in order to determine the latest TID value to use.
You are recommended that you use the transactionID parameter for non-indexed databases (Netezza, DB2 BLU) where performance may be adversely affected by using a MAX query. For indexed databases (DB2, Oracle, etc), running a MAX query has no adverse affect, and it is not necessary to use this parameter.
Before running the incrementallyLoadCubes command, you are recommended to use the getCubeMetrics command to check the following metrics:
- timeLastNearRealTimeUpdateAvailable - to check the date and time that the latest increment was loaded.
- timeToApplyLastNearRealTimeUpdates - to check the time taken to build the latest increment.
- valueOfLastNearRealTimeTID - to check the (TID) value of the latest increment.
If required, after running incrementallyLoadCubes, run the getCubeMetrics command to check that the updates completely successfully.
For information on using the DCAdmin command line tool, see http://www.ibm.com/support/docview.wss?uid=swg27040451.
Additional memory requirements during an incremental load
Running an incremental load is a memory intensive process and requires additional memory during its execution. You should plan for 900 bytes for each new tuple. For example, loading 10M tuples requires an additional 9GB of memory.
This additional memory is required only for the duration of the incremental load.
A tuple is defined as the number tuples processed in the incremental update. This is derived from: (number of unique rows at the grain of the cube) * (number of additive measures)
- number of inserted rows is the number of rows added to the fact table.
- number of unique rows at the grain of the cube is the unique rows affected at the grain of the cube.
This value is used by a query to fetch the increment values. It must always be equal to, or less, than the number of inserted rows. It may be less than the number of inserted rows if the grain of the cube is higher. For example, the cube is modelled to [Hour], but rows are inserted to the minute.
Additional memory requirements during dynamic cube operation
Tuples for the latest increment are saved after the incrementallyLoadCubes command finishes, at a cost of 100 bytes per tuple. For example, a 10M increment requires an additional 1GB of memory.
This additional memory is required whilst the cube is running, and applies to the last set of loaded tuples. For example, if you incrementally load a cube ten times, once the load commands are finished, the additional memory required is: (100 bytes * number of tuples in last load).
For information on near real time updates, see http://www.ibm.com/support/docview.wss?uid=swg27040299.
Was this topic helpful?
17 June 2018