Health and Diagnostics

Casabase Cube provides administrative procedures for validating application health, collecting diagnostic information, and analyzing query performance.

The primary tools are:

Capability	Procedure
Health validation	HEALTH_CHECK
Support information	GENERATE_SUPPORT_INFO
Performance summary	PERFORMANCE_REPORT
Slow-query analysis	SLOW_QUERY_INSPECTOR
Formula-cost analysis	FORMULA_COST_ESTIMATOR
Clustering recommendations	RECOMMEND_CLUSTERING
Search optimization recommendations	RECOMMEND_SEARCH_OPTIMIZATION

Unless noted otherwise, these administrative procedures require the CUBE_ADMIN application role.

Health Check

Use:

CALL CUBE.HEALTH_CHECK('FINANCE');

to validate a specific cube.

To check every cube, omit the cube name:

CALL CUBE.HEALTH_CHECK(NULL);

HEALTH_CHECK returns:

CUBE_NAME
DIM_NAME
CHECK_TYPE
STATUS
MESSAGE

STATUS is:

OK
WARNING

or an error state.

Snowflake Intelligence and Cortex Agent Validation

The current Casabase Cube Intelligence integration uses an app-created Cortex Agent within the Snowflake Native App model.

For health checks and post-upgrade validation, confirm:

• The app-created agent is available.
• Required Cortex Agent and Snowflake Intelligence capabilities are enabled in the account.
• Intended Snowflake account roles hold the appropriate Casabase Cube application role.
• The user’s default role has the required Cortex Agent and warehouse privileges.
• Required privileges and caller grants for consumer-owned objects are present where applicable.
• A representative Snowflake Intelligence question can invoke the intended Casabase Cube tools successfully.

Customer-created views, BI models, saved SQL, and other external objects that reference application objects by name remain customer-owned and should be validated separately after application upgrades.

See Setting Up the Agent and Governance and Security.

Reviewing Only Issues

After running HEALTH_CHECK, use Snowflake’s result scan to focus on items requiring attention:

SELECT *
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE STATUS <> 'OK';

This is a useful standard workflow:

Run HEALTH_CHECK
       │
       ▼
Filter STATUS <> 'OK'
       │
       ▼
Review WARNING / Error
       │
       ▼
Correct Configuration
       │
       ▼
Run HEALTH_CHECK Again

Formula Safety Warnings

FORMULA_DIVISION_SAFETY identifies formulas containing division that does not guard the denominator with a construct such as NULLIF.

These warnings should be reviewed rather than treated as purely informational.

The definitive Administration reference specifically recommends clearing them because an unprotected divide-by-zero condition can produce a misleading result instead of representing the absence of a meaningful calculation.

For formula guidance, see Formula Best Practices.

Data Freshness

DATA_FRESHNESS helps identify dimensions whose built structures may not reflect recent source metadata.

Dimension structures are built from source hierarchy metadata. When those source tables change, the affected dimension must be rebuilt.

A health warning involving freshness should therefore prompt a review of:

Source Hierarchy Changed?
        │
        ▼
Dimension Rebuilt?
        │
        ▼
Current Built Structure

Fact-data changes do not require the same hierarchy rebuild simply because fact values changed.

See Operational Tasks for dimension rebuild administration.

Configuration Integrity

CONFIG_INTEGRITY validates that the dimensional configuration remains structurally consistent, including the mapping of dimensions to distinct fact columns.

This is useful when troubleshooting problems where:

• A cube was recently configured
• Dimension mappings changed
• A migration occurred during an upgrade
• Query behavior changed unexpectedly

A health error should be addressed before trying to compensate for the problem in consuming queries.

Query Support Objects

The health check also validates:

QUERY_FUNCTION
SHARED_TABLE

These checks confirm that expected query-support and consumer-facing objects exist.

This is particularly useful after an application upgrade because Casabase Cube recreates consumer-facing views such as:

<CUBE>_DIMENSIONS
<CUBE>_FACT_SECURE

as part of the upgrade process.

Health Checks After an Upgrade

HEALTH_CHECK is an important post-upgrade verification step.

The recommended sequence includes:

Confirm New Version
       │
       ▼
Review Upgrade / Migration Events
       │
       ▼
HEALTH_CHECK Each Cube
       │
       ▼
Run Known Verification Query
       │
       ▼
Check Scheduled Queries

For example:

CALL CUBE.HEALTH_CHECK('FINANCE');

notes that per-cube migration failures can be recorded without aborting the entire application upgrade, so a successful overall upgrade should still be followed by cube-level health validation.

See Application Upgrades.

Support Information

When an issue requires deeper troubleshooting or escalation, use:

CALL CUBE.GENERATE_SUPPORT_INFO('FINANCE');

For system-level information, use:

CALL CUBE.GENERATE_SUPPORT_INFO(NULL);

GENERATE_SUPPORT_INFO collects version, configuration, and current application state into diagnostic information suitable for a support request.

Conceptually:

Application Version
        +
Cube Configuration
        +
Current State
        │
        ▼
GENERATE_SUPPORT_INFO
        │
        ▼
Support Diagnostic Information

Before Requesting Support

A useful troubleshooting sequence is:

Reproduce the Issue
       │
       ▼
Run HEALTH_CHECK
       │
       ▼
Review Audit History
       │
       ▼
Reduce to Smallest Reproducible Query
       │
       ▼
GENERATE_SUPPORT_INFO
       │
       ▼
Provide Support Context

Useful accompanying information includes:

• Cube name
• Application version
• Exact operation being performed
• Smallest POV reproducing the issue
• Expected result
• Actual result
• Exact error message
• Approximate time of occurrence

The generated support information should provide the application context rather than requiring administrators to manually gather configuration details one at a time.

Performance Diagnostics

Casabase Cube also provides dedicated procedures for examining query and formula performance.

These diagnostics complement HEALTH_CHECK.

The distinction is:

HEALTH_CHECK
    │
    └── Is the cube structurally and operationally healthy?

versus:

Performance Diagnostics
    │
    └── How efficiently is the cube being queried?

Performance Report

Use:

CALL CUBE.PERFORMANCE_REPORT(
    'FINANCE',
    '30'
);

to review performance information for the specified cube and period.

The second argument represents the review period in days.

PERFORMANCE_REPORT is appropriate for periodic review of actual query behavior rather than investigation of one specific failed query. The Administration checklist recommends reviewing it periodically and acting on relevant optimization recommendations.

Slow Query Inspector

Use:

CALL CUBE.SLOW_QUERY_INSPECTOR(
    'FINANCE',
    NULL,
    '7',
    NULL
);

The procedure accepts:

cube
limit
days
slow_ms

and is designed to identify slow query activity for further investigation.

This is useful when:

• Query latency has increased
• A particular cube appears slower than expected
• You need examples of expensive queries
• You are deciding whether physical optimization may help

Conceptually:

Performance Concern
       │
       ▼
SLOW_QUERY_INSPECTOR
       │
       ▼
Identify Expensive Query Patterns
       │
       ▼
Review POV / Formula / Physical Design

Formula Cost Estimator

Use:

CALL CUBE.FORMULA_COST_ESTIMATOR('FINANCE');

to analyze formula-related query cost.

Calculated members can be materially more expensive than stored-member queries because their values are resolved dynamically.

Use the estimator when investigating:

• Complex calculated-member queries
• Broad selections involving formulas
• Formula-heavy cubes
• Performance changes following formula additions
• Candidates for query redesign or materialization

The procedure belongs to the supported health/performance toolset documented in the Administration reference.

Clustering Recommendations

Use:

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

to analyze query history and identify clustering opportunities.

The recommendation procedure examines actual workload behavior rather than applying a generic physical design assumption.

the recommendation procedures report suggested physical optimizations and only apply changes when explicitly asked to do so.

This is important operationally:

Analyze
   │
   ▼
Recommend
   │
   ▼
Administrator Reviews
   │
   ▼
Explicitly Apply if Appropriate

A recommendation by itself does not silently change the physical configuration.

Search Optimization Recommendations

Use:

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

to analyze whether Snowflake Search Optimization may benefit actual cube query patterns.

Like clustering recommendations, the procedure analyzes observed query history and reports a recommendation before any physical optimization is applied.

Recommendation Procedures Are Advisory

The two recommendation procedures are intentionally different from automatic tuning.

They allow the workflow:

Observed Query History
       │
       ▼
Casabase Analysis
       │
       ▼
Physical Optimization Recommendation
       │
       ▼
Administrator Decision

This gives administrators control over physical optimizations that can affect Snowflake cost or storage.

Diagnosing Query Performance

A practical performance troubleshooting sequence is:

Slow Query Reported
       │
       ▼
Run HEALTH_CHECK
       │
       ▼
Healthy?
       │
       ├── No ──► Correct Health Issue
       │
       └── Yes
              │
              ▼
      SLOW_QUERY_INSPECTOR
              │
              ▼
      Formula Heavy?
              │
              ├── Yes ──► FORMULA_COST_ESTIMATOR
              │
              └── No
                    │
                    ▼
          Review Query Shape
                    │
                    ▼
      Review Physical Recommendations

Do not immediately apply physical optimization to compensate for a structurally unhealthy cube or an unnecessarily broad query.

Query Shape Still Matters

Performance tools do not remove the need for appropriate query design.

Casabase Cube queries should request the grain actually required by the consumer.

For example:

Required Report
  3 dimensions
  20 members

should not automatically become:

Entire Cube
All Descendants
Multiple Calculated Dimensions

followed by filtering in the consuming tool.

Broad selections and calculated-member expansions can create significantly larger calculation spaces.

See Query Best Practices for query design guidance.

Health and Audit History

Current health and historical audit information answer different questions.

HEALTH_CHECK
      │
      └── What is wrong now?

AUDIT LOG
      │
      └── What changed or failed previously?

Together:

Current Condition
       +
Historical Activity
       │
       ▼
Diagnostic Context

For example, if HEALTH_CHECK reports a missing or stale structure after an upgrade, the audit log can be reviewed for:

APP_UPGRADE
UPGRADE_MIGRATION
DIMENSION_REBUILD

events.

See Audit Log.

Routine Health Review

The definitive Administration checklist recommends including:

CALL CUBE.HEALTH_CHECK(NULL);

in regular administrative review and clearing items that are not OK.

A practical review can be:

HEALTH_CHECK(NULL)
       │
       ▼
Review Non-OK Results
       │
       ▼
GET_AUDIT_SUMMARY(30)
       │
       ▼
Review Failed / Slow Operations
       │
       ▼
PERFORMANCE_REPORT
       │
       ▼
Address Exceptions

The exact frequency should follow the organization’s operational requirements.

When to Use Each Tool

Situation	Recommended Tool
Validate cube configuration	HEALTH_CHECK
Check all cubes after an upgrade	HEALTH_CHECK(NULL)
Prepare information for support	GENERATE_SUPPORT_INFO
Review overall query performance	PERFORMANCE_REPORT
Investigate specific slow workloads	SLOW_QUERY_INSPECTOR
Assess formula-related cost	FORMULA_COST_ESTIMATOR
Evaluate clustering opportunities	RECOMMEND_CLUSTERING
Evaluate Search Optimization opportunities	RECOMMEND_SEARCH_OPTIMIZATION
Investigate what changed	Audit Log

Key Procedures

HEALTH_CHECK(cube)

GENERATE_SUPPORT_INFO(cube)

PERFORMANCE_REPORT(cube, days)

SLOW_QUERY_INSPECTOR(
    cube,
    limit,
    days,
    slow_ms
)

FORMULA_COST_ESTIMATOR(cube)

RECOMMEND_CLUSTERING(...)

RECOMMEND_SEARCH_OPTIMIZATION(...)

These procedures provide the primary supported interfaces for application validation, support diagnostics, performance analysis, and physical optimization recommendations.

Key Principle

Health and diagnostics should move an investigation through a structured sequence:

Is the Cube Healthy?
        │
        ▼
What Needs Attention?
        │
        ▼
What Changed?
        │
        ▼
What Is Slow?
        │
        ▼
Why Is It Slow?
        │
        ▼
What Optimization Is Appropriate?

Casabase Cube provides separate tools for each of those questions rather than treating all operational problems as the same type of failure.

Related Topics

• Administration Overview
• Application Upgrades
• Audit Log
• Operational Tasks
• Access Control
• Formula Best Practices
• Query Best Practices