Starting and managing dynamic cubes

You can perform most actions on individual or on multiple dynamic cubes. The actions that are available depend on the status of the cubes. Adding and removing cubes from server groups is described in the topic Adding dynamic cubes to the query service. The following list describes other actions that are associated with managing dynamic cubes in the query service.

Start

This action starts dynamic cubes in the query service. You must start dynamic cubes in the query service to use them in IBM® Cognos® studios. When you start a cube, the hierarchy members are loaded in the cache.

Cubes started in the query service display the Available status in the Scorecard section of the Dynamic Cubes view. In some cases, when a cube is starting it will display the status Partially Available. The parent dynamic cube status reflects the consolidated status of child cubes.

Set Properties

This action lets you set a number of general properties for dynamic cubes including hiding entries, and selecting the access account for the entry. For more information see Setting general properties for a dynamic cube.

Stop after active tasks complete

This actions stops cubes after the queries that are currently running are complete. Typically, you stop a cube if it does not need to be online and accessible.

Stop immediately

Stopping immediately stops the cube and cancels any queries that are currently running. This action is useful if you want to restart cubes to apply changes made to the model without waiting for long-running queries to complete.

Restart

This action stops and then starts a cube. For example, you might restart to reset a cube after a failure, or after a successful ETL (Extract, Transform, Load) run. Restarting a cube is a different action than restarting the query service. When following procedures, note whether the cube or the query service must be restarted.

Pause

This action cancels all existing queries and does not allow any new queries against the cube. The query service waits for all queries to clear before changing the cube state. If the request times out, an error occurs and the state reverts to Running. When paused, the dynamic cube continues to run so that the data caches remain valid. While the cube is paused, its status is shown as Partially available.

You can pause a dynamic cube to maintain aggregate tables for near real time updates, or to make database configuration changes, such as recycling a database or increasing buffer pools, while a dynamic cube is active. For more information, see Pausing a dynamic cube to update aggregate tables. You must pause each dynamic cube separately.

Use the Start command to resume the cube to Running state and allow new queries against the cube.

Refresh member cache

If the dimension tables have been updated while the cube is running, you can refresh the member cache which will allow the cube to remain accessible to users while the dimension tables are reloaded from the back-end data source.

An update of the member cache, builds a new set of members in the background. This new set becomes available when the refresh is complete. This refresh requires additional memory to store two copies of the member cache in memory while the new cache is built.

Once the new member cache is available, the data cache is refreshed. This is because the data in the cache is tied to the structure of the members in the member cache.

For more information see Types of caches used by dynamic cubes.

Refresh data cache

Refreshing the data cache picks up changes to the fact table and re-syncs the data caches with the fact table. Data caches are refreshed dynamically while queries are still running so cubes remain accessible to users. When the member cache is brought online, a new corresponding data cache is also created. Even though a new data cache starts as empty, some additional space is required while the new cache is introduced and while queries are using the previous version of the data cache.

For more information see Types of caches used by dynamic cubes.

Refresh security settings

While the cube is still running, this action reloads the access permissions on the security views, and clears cached information that was loaded from the security lookup table.

This action also attempts to reload security rules from the model of a published cube. Rule reload succeeds only if the rest of the model was not significantly changed; for example, no levels, hierarchies or dimensions were added, changed, or removed. If these types of changes were done in the model, the rule reload is not executed and a corresponding message is written to the recent message log for the cube.

Edit security view permissions

Administrators can access the security view models for cubes, override the default group permissions, and add the appropriate users and groups to the model views. For more information see Setting access permissions for security views.

Clear workload log

This action removes all log entries for a dynamic cube. This is useful if you want to capture new information about report usage. For more information, see Workload log for Aggregate Advisor.

Incrementally update data

This action invokes an incremental load that updates the aggregate cache and data cache to reflect the newly-added fact rows.

For more information, see Loading incremental updates to dynamic cubes.

Delete

This action deletes a published cube from Content Manager.

View recent messages

This action allows the administrator to view recent log messages to diagnose problems with dynamic cubes. The time zone displayed is the time zone of the administrator that is viewing the log messages.