Operational Tasks

Casabase Cube requires relatively little infrastructure administration because it runs as a Snowflake Native Application.

Routine operational work is focused on the multidimensional application itself:

• Rebuilding dimensions after hierarchy-source changes
• Monitoring asynchronous and serverless operations
• Recovering from stale build locks
• Backing up and restoring cube configuration
• Creating and restoring dimension snapshots
• Reviewing application health
• Reviewing audit activity
• Monitoring scheduled queries
• Performing periodic administrative reviews

Unless noted otherwise, the operational procedures on this page require the CUBE_ADMIN application role.

Operational Model

Casabase Cube does not require administrators to maintain a separate OLAP server environment.

Operational responsibilities are centered on:

Snowflake Platform
      │
      ▼
Casabase Cube Native App
      │
      ├── Dimension Structures
      ├── Cube Configuration
      ├── Security
      ├── Formulas
      ├── Saved Queries
      ├── Scheduled Tasks
      ├── Audit History
      └── Health / Performance

There is no separate Casabase application server, operating system, or proprietary OLAP service to patch and operate.

Rebuilding Dimensions

Dimension structures are built from their configured source tables.

When the source hierarchy metadata changes, the affected dimensions must be rebuilt.

Use:

CALL CUBE.REBUILD_DIMENSIONS(
    'FINANCE',
    FALSE,
    FALSE,
    FALSE
);

to rebuild dimensions on the FINANCE cube that are flagged for automatic rebuild.

The arguments are:

p_cube_name
p_rebuild_all
p_skip_snapshots
p_async

Rebuild Every Dimension

To rebuild every dimension on a cube:

CALL CUBE.REBUILD_DIMENSIONS(
    'FINANCE',
    TRUE,
    FALSE,
    FALSE
);

Setting:

p_rebuild_all = TRUE

causes all dimensions on the cube to be rebuilt rather than only those selected by the normal rebuild configuration.

Rebuild Across Cubes

Pass:

NULL

for the cube name to cover every cube:

CALL CUBE.REBUILD_DIMENSIONS(
    NULL,
    FALSE,
    FALSE,
    FALSE
);

The other arguments retain their normal meanings.

Synchronous vs. Asynchronous Rebuilds

A rebuild can run synchronously or asynchronously.

For a synchronous rebuild:

CALL CUBE.REBUILD_DIMENSIONS(
    'FINANCE',
    TRUE,
    FALSE,
    FALSE
);

the call waits for the requested processing to complete.

For an asynchronous rebuild:

CALL CUBE.REBUILD_DIMENSIONS(
    'FINANCE',
    TRUE,
    FALSE,
    TRUE
);

the call returns immediately and the rebuild continues separately.

Conceptually:

Synchronous

CALL
 │
 ▼
Rebuild
 │
 ▼
Complete
 │
 ▼
Return

versus:

Asynchronous

CALL
 │
 ▼
Start Rebuild
 │
 ▼
Return Immediately

Rebuild Continues

Monitoring an Asynchronous Rebuild

Async rebuild activity can be monitored through the audit log.

For example:

SELECT
    CREATED_AT,
    CUBE_NAME,
    OBJECT_NAME,
    STATUS,
    EXECUTION_TIME_MS,
    ERROR_MESSAGE
FROM CASABASE_CUBE.CONFIG.AUDIT_LOG
WHERE EVENT_TYPE IN (
    'DIMENSION_REBUILD',
    'DIMENSION_CREATE'
)
  AND CREATED_AT > DATEADD(
        'hour',
        -6,
        CURRENT_TIMESTAMP()
      )
ORDER BY CREATED_AT DESC;

This provides visibility into:

• Dimension
• Cube
• Status
• Execution time
• Errors

See Audit Log for broader audit capabilities.

Task History

For serverless task execution, use:

CALL CUBE.GET_TASK_HISTORY(50);

This is useful when reviewing activity associated with serverless operations such as scheduled processing.

Casabase Cube uses Snowflake managed tasks for supported scheduled operations when the required account privilege has been granted.

The required application privilege is:

EXECUTE MANAGED TASK

which allows scheduled dimension rebuilds and Saved Query materialization to run as serverless tasks without requiring a customer-owned warehouse.

Build Locks

A dimension build acquires a build lock to prevent concurrent rebuilds of the same dimension.

Conceptually:

Build Starts
    │
    ▼
Acquire Lock
    │
    ▼
Build Dimension
    │
    ▼
Release Lock

If a build is interrupted unexpectedly, a lock can remain and prevent a later rebuild from starting.

Inspecting Build Locks

To review current locks:

SELECT *
FROM CASABASE_CUBE.CONFIG.BUILD_LOCKS;

Use this when a rebuild appears blocked by an existing build state.

Releasing a Build Lock

To release the lock for one dimension:

CALL CUBE.RELEASE_BUILD_LOCK(
    'FINANCE',
    'ENTITY'
);

To release all build locks on a cube:

CALL CUBE.RELEASE_BUILD_LOCK(
    'FINANCE',
    NULL
);

Verify Before Releasing a Lock

Do not release a build lock simply because a build is taking longer than expected.

explicitly requires administrators to confirm that no build is actually running before releasing the lock.

A safe workflow is:

Build Appears Blocked
       │
       ▼
Inspect BUILD_LOCKS
       │
       ▼
Review Audit / Task History
       │
       ▼
Is Build Actually Running?
       │
       ├── Yes ──► Leave Lock Intact
       │
       └── No
              │
              ▼
      RELEASE_BUILD_LOCK

The build lock protects against concurrent structural changes, so releasing an active lock can create an unsafe rebuild condition.

Configuration Backup

Casabase Cube can export cube structure and settings as configuration JSON.

Use:

CALL CUBE.EXPORT_CUBE_CONFIG('FINANCE');

The export contains structure and settings, not cube data.

This makes configuration export useful as an administrative backup and comparison artifact.

When to Export Configuration

recommends capturing configuration:

• Before an application upgrade
• Before a large modeling change
• On a routine schedule for production cubes

For example:

Production Cube
      │
      ▼
EXPORT_CUBE_CONFIG
      │
      ▼
Retain Configuration Reference
      │
      ▼
Perform Significant Change

This provides a known configuration state for comparison or restoration.

Importing Cube Configuration

Use:

CALL CUBE.IMPORT_CUBE_CONFIG(
    '<json from export>',
    FALSE
);

to restore an exported configuration into a new or existing cube.

The second argument is the procedure’s:

overwrite

setting.

Administrators should understand the intended destination and overwrite behavior before importing configuration into an existing environment.

Configuration Backup Is Not a Data Backup

EXPORT_CUBE_CONFIG captures:

Structure
+
Settings

not the underlying cube data.

Conceptually:

EXPORT_CUBE_CONFIG
       │
       ├── Cube Configuration
       ├── Dimension Definitions
       ├── Application Settings
       └── Model Metadata

rather than:

Fact Data Backup

Customer source data and broader Snowflake data-protection processes remain separate.

Configuration Backup Before an Upgrade

Before a production application upgrade:

CALL CUBE.EXPORT_CUBE_CONFIG('FINANCE');

provides a rollback reference for the existing configuration.

The configuration normally persists across the Native App upgrade, so this export is a precautionary administrative reference rather than a required migration step.

See Application Upgrades.

Dimension Snapshots

Casabase Cube also supports snapshots of individual dimension structures.

A snapshot is useful when a specific hierarchy is about to undergo a significant change.

For example:

CALL CUBE.SNAPSHOT_DIMENSION(
    'FINANCE',
    'ENTITY',
    'Before Q3 restructure'
);

Conceptually:

Current Dimension
      │
      ▼
SNAPSHOT_DIMENSION
      │
      ▼
Saved Dimension State
      │
      ▼
Restructure / Rebuild

This provides a more targeted recovery point than exporting the complete cube configuration.

Listing Dimension Snapshots

Use:

CALL CUBE.LIST_DIMENSION_SNAPSHOTS(
    'FINANCE',
    'ENTITY'
);

to review available snapshots for a dimension.

Use the returned snapshot information to identify the state you want to restore or retain.

Restoring a Dimension Snapshot

Use:

CALL CUBE.RESTORE_DIMENSION_SNAPSHOT(
    'FINANCE',
    'ENTITY',
    '<snapshot>',
    TRUE
);

Passing:

TRUE

as the final argument causes Casabase Cube to take a backup of the current state before performing the restore.

That makes the restore itself reversible.

Conceptually:

Current Dimension
        │
        ▼
Backup Current State
        │
        ▼
Restore Selected Snapshot
        │
        ▼
If Needed
        │
        ▼
Restore Previous State

For an important production hierarchy, this is generally safer than replacing the current state without preserving it first.

Pruning Dimension Snapshots

Use:

CALL CUBE.PRUNE_DIMENSION_SNAPSHOTS(
    'FINANCE',
    'ENTITY',
    10
);

to prune older snapshots while retaining the configured number.

Snapshot retention should reflect how frequently the dimension changes and how much rollback history the organization wants to preserve.

Choosing Between Configuration Export and Dimension Snapshot

These capabilities serve different purposes.

Capability	Scope	Best Use
EXPORT_CUBE_CONFIG	Entire cube configuration	Upgrade reference, broad modeling change, routine production backup
SNAPSHOT_DIMENSION	One dimension	Hierarchy restructuring or dimension-specific rollback
RESTORE_DIMENSION_SNAPSHOT	One dimension	Restore a previous dimension state
IMPORT_CUBE_CONFIG	Cube configuration	Restore or reproduce exported configuration

A useful rule is:

Broad Cube-Level Change
        │
        ▼
EXPORT_CUBE_CONFIG

versus:

Specific Hierarchy Change
        │
        ▼
SNAPSHOT_DIMENSION

Health Review

Routine operations should include application health validation.

Use:

CALL CUBE.HEALTH_CHECK(NULL);

and investigate anything whose status is not:

OK

The definitive Administration checklist recommends this as a recurring review item.

See Health and Diagnostics.

Audit Review

Use:

CALL CUBE.GET_AUDIT_SUMMARY(30);

during routine administrative review.

Investigate:

• Rising error counts
• Failed dimension operations
• Failed scheduled queries
• Significant configuration changes
• Unexpected user query activity

The definitive checklist includes audit-summary review as a routine administrative control.

See Audit Log.

Data Inventory Review

Use:

CALL CUBE.GET_DATA_INVENTORY();

to periodically review:

• Cube inventory
• Classification coverage
• Security coverage
• Last-query activity

The monthly checklist specifically calls for confirming classification coverage.

This can also help identify unused cubes that may be candidates for decommissioning.

Security Review

Routine operations should include reviewing security assignments against current staffing.

Because Casabase Cube row-level security is opt-in per user, administrators should also run the unrestricted-user control check documented in Access Control.

A user with application access but no active security rule remains unrestricted by Casabase Cube row-level security.

This makes security review an operational requirement rather than only a setup activity.

Saved Query Review

Use:

CALL CUBE.LIST_SAVED_QUERY_SCHEDULES(NULL);

and review recent run status for scheduled outputs.

Investigate:

• Failed executions
• Unexpected target-table results
• Stale scheduled output
• Changed Cube Variable values
• Materializations affected by an application upgrade

See Saved Queries.

Initial Setup Checklist

For a new environment:

[ ] Grant READ SESSION to the application
[ ] Grant EXECUTE MANAGED TASK
[ ] Grant required USAGE / SELECT / stage access
[ ] Grant SNOWFLAKE.CORTEX_USER if AI is used
[ ] Grant CUBE_ADMIN only to administrator roles
[ ] Grant CUBE_PUBLIC to consumer roles
[ ] Classify every cube
[ ] Decide which dimensions require security
[ ] Create rules for every user who must be restricted
[ ] Verify restricted-user access
[ ] Establish an audit-retention period

This matches the definitive Administrator checklist.

Monthly Checklist

A recurring monthly review can include:

[ ] HEALTH_CHECK(NULL) and clear anything not OK
[ ] GET_AUDIT_SUMMARY(30) and investigate rising errors
[ ] GET_DATA_INVENTORY() and confirm classification coverage
[ ] Review security rules against current staffing
[ ] Run the unrestricted-users control check
[ ] LIST_SAVED_QUERY_SCHEDULES(NULL) and review last-run status
[ ] Export configuration for production cubes

Quarterly Checklist

A broader quarterly review can include:

[ ] GET_PRIVACY_REPORT()
[ ] Review CUBE_ADMIN membership
[ ] Review application account grants
[ ] Purge audit history beyond the retention policy
[ ] Review PERFORMANCE_REPORT
[ ] Act on appropriate optimization recommendations
[ ] Review cubes with no recent LAST_QUERIED activity

Upgrade Checklist

For an application upgrade:

[ ] Read release notes
[ ] Export production cube configuration
[ ] Confirm VERSION changed
[ ] Review APP_UPGRADE events
[ ] Review UPGRADE_MIGRATION events
[ ] HEALTH_CHECK every cube
[ ] Run known verification queries
[ ] Recreate Cortex Agent if AI is used
[ ] Repoint customer views / BI models affected by renames
[ ] Re-run scheduled queries whose output shape changed

See Application Upgrades for the full process.

User Offboarding

When a user leaves or no longer requires Casabase Cube access:

1. Find the user’s security rules.
2. Deactivate or delete those rules as appropriate.
3. Revoke the account-role path that provides CUBE_PUBLIC or CUBE_ADMIN.
4. Retain the user’s audit history.

The definitive checklist explicitly says not to purge audit records merely to remove a user.

Because security is opt-in, ensure application access is actually revoked. Removing the final security rule alone can make the user unrestricted while their application-role access remains.

Operational Procedure Summary

The primary operational procedures are:

REBUILD_DIMENSIONS(
    cube,
    all,
    skip_snapshots,
    async
)

GET_TASK_HISTORY(limit)

RELEASE_BUILD_LOCK(
    cube,
    dimension
)

EXPORT_CUBE_CONFIG(cube)

IMPORT_CUBE_CONFIG(
    json,
    overwrite
)

SNAPSHOT_DIMENSION(...)

LIST_DIMENSION_SNAPSHOTS(...)

RESTORE_DIMENSION_SNAPSHOT(...)

PRUNE_DIMENSION_SNAPSHOTS(...)

Recommended Practices

• Rebuild dimensions after their hierarchy-source metadata changes.
• Use asynchronous rebuilds for operations that should return control immediately.
• Monitor async processing through audit history and task history.
• Never release a build lock until you have confirmed no build is still running.
• Export production cube configuration before upgrades and significant model changes.
• Remember that configuration export does not contain fact data.
• Create dimension snapshots before significant hierarchy restructuring.
• Use reversible snapshot restore where appropriate.
• Prune old snapshots according to your retention needs.
• Run HEALTH_CHECK(NULL) routinely.
• Review audit-summary error trends.
• Review security assignments against current staffing.
• Review users querying secured cubes without active rules.
• Monitor scheduled-query execution.
• Review performance recommendations periodically.
• Preserve audit history during user offboarding.

Key Principle

Routine Casabase Cube operations are primarily about maintaining the logical model and application state, not a separate OLAP infrastructure stack.

A useful operational cycle is:

Source Metadata Changes
        │
        ▼
Rebuild Dimensions
        │
        ▼
Monitor Tasks
        │
        ▼
Validate Health
        │
        ▼
Review Audit Activity
        │
        ▼
Protect Configuration
        │
        ▼
Review Security and Governance

The built-in operational procedures provide controlled ways to rebuild, monitor, back up, recover, and validate the multidimensional environment.

Related Topics

• Administration Overview
• Roles and Privileges
• Access Control
• Audit Log
• Application Upgrades
• Health and Diagnostics
• Data Classification
• Compliance and Privacy
• Saved Queries