Dimension Validation & Build Errors

Dimension problems generally occur at one of two stages:

Dimension Definition
        │
        ▼
VALIDATE_DIMENSION
        │
        ├── Fails ──► Correct Source Metadata
        │
        ▼
REBUILD_DIMENSIONS
        │
        ├── Fails ──► Investigate Build / Access / Lock
        │
        ▼
Built Dimension

Treat validation failures and build failures as different problems.

Validation determines whether the source dimension definition is structurally valid. A rebuild creates the application-managed dimension and hierarchy structures from that definition. Casabase Cube uses VALIDATE_DIMENSION for independent validation and REBUILD_DIMENSIONS for rebuilding changed dimension structures.

Start by Validating the Dimension

When a dimension will not build, validate it before repeatedly attempting another rebuild.

Use the syntax documented in Dimension Validation for the dimension being investigated.

The validation workflow can identify structural problems such as:

• Invalid hierarchy relationships
• Duplicate base members
• Circular references
• Invalid aggregation operators
• Missing member names
• Orphan members
• Invalid shared-member structures

These are source-definition problems and should be corrected before rebuilding.

Understand the Source Definition

A dimension definition table describes the members, hierarchy relationships, and member properties from which Casabase Cube builds a dimension.

Conceptually:

Dimension Definition Table
          │
          ▼
Dimension Configuration
          │
          ▼
Build / Rebuild
          │
          ▼
Dimension and Hierarchy
      Structures

The definition table is metadata. It is separate from the bottom-level fact data stored for the cube.

If the definition table is wrong, rebuilding does not repair the source metadata. Correct the definition first.

Missing Member Names

Every member must have a valid member name in the column mapped as the dimension’s member column.

If validation reports missing member names, inspect the source definition for:

• NULL member names
• Blank member names
• Rows that do not represent valid members
• Incorrect member-column mapping

Correct the source data or configuration, then validate again.

Duplicate Base Members

A base member must not be defined as multiple independent base members where the dimension model requires one base-member definition.

If validation reports duplicate base members, determine whether the duplicate represents:

• An accidental duplicate source row
• A second conflicting parent relationship
• A member that should instead be represented as a shared member
• Duplicate data introduced during source generation

Do not remove duplicates blindly. First determine whether the source intended a shared occurrence.

Invalid Parent Relationships

Each non-root member must participate in a valid parent-child structure.

When validation reports an invalid relationship, check:

• Whether the parent exists
• Whether the parent name is spelled consistently
• Whether the member references the intended parent
• Whether the root structure is valid
• Whether the source contains stale or obsolete relationships

For example:

Total Entity
├── North America
│   ├── United States
│   └── Canada
└── Europe

If Canada references NorthAmerica while the actual parent is North America, the source definition must be corrected.

Orphan Members

An orphan is a member whose configured parent cannot be resolved into the hierarchy.

Conceptually:

Canada
  │
  └── Parent = NorthAmerica
                   │
                   ▼
             Parent Not Found
                   │
                   ▼
                 Orphan

Correct the parent relationship in the dimension definition table and validate again.

Do not work around an orphan by assigning an arbitrary parent unless that relationship is correct for the business model.

Circular References

A hierarchy cannot contain a parent-child cycle.

For example:

A
└── B
    └── C
        └── A

creates a circular relationship.

No valid root-to-leaf hierarchy can be constructed from this structure.

Correct the source relationships so every branch eventually terminates at a valid root rather than referring back to an ancestor.

Invalid Aggregation Operators

If the dimension definition includes an aggregation-operator column, its values must use operators supported by Casabase Cube.

When validation reports an invalid aggregation operator:

1. Identify the affected member.
2. Review the source value.
3. Determine the intended aggregation behavior.
4. Replace the invalid value with the appropriate supported operator.
5. Validate again.

Do not simply replace every invalid operator with addition. The operator is part of the multidimensional business model and can materially change parent values.

Shared-Member Problems

Shared members allow a base member to appear in additional hierarchy locations without creating another independent copy of the underlying member.

Validation can fail when shared-member metadata does not resolve to a valid base-member structure.

Check:

• Whether the base member exists
• Whether the source correctly identifies the shared occurrence
• Whether the shared-member column and shared value are mapped correctly
• Whether duplicate rows were incorrectly represented as base members
• Whether the parent relationship for the shared occurrence is valid

Shared-member problems should be corrected in the source metadata rather than repaired after the dimension is built.

Formula-Related Build Problems

Dimension definitions can contain member formulas.

A dimension can therefore be structurally close to valid while still containing formula metadata that requires correction.

If the problem points to formula syntax or formula metadata, continue with:

• Formula Errors
• Formula Validation

Health Check can also identify formula-health conditions such as syntax, bracket, CASE, empty-formula, dimension-association, division-safety, and untranslated Essbase syntax problems.

Do not troubleshoot a formula problem by repeatedly rebuilding the dimension without changing the formula.

Source Table Cannot Be Accessed

Customer-created dimension definition tables can reside outside the Native App database, but Casabase Cube must have the required access to them. The configured INPUT_TABLE_NAME identifies the fully qualified source table.

If validation or rebuild reports that the source object cannot be accessed, verify:

Database USAGE
      │
      ▼
Schema USAGE
      │
      ▼
Table SELECT

Also confirm that:

• The database still exists
• The schema still exists
• The table has not been renamed
• The configured table name is correct
• Required source columns still exist

Run:

CALL CUBE.HEALTH_CHECK('FINANCE');

and review INPUT_TABLE_CONFIG findings when source configuration is suspected.

See Access & Permission Issues and Using Health Check.

The Source Table Changed but the Cube Did Not

Changing a dimension definition table does not automatically mean the active built dimension has already changed.

When source dimension metadata changes, rebuild the corresponding Casabase Cube structures before expecting the new hierarchy to appear in queries.

The normal sequence is:

Change Source Metadata
        │
        ▼
VALIDATE_DIMENSION
        │
        ▼
REBUILD_DIMENSIONS
        │
        ▼
HEALTH_CHECK
        │
        ▼
Verification Query

Do not rebuild dimensions merely because fact values changed. Fact-data changes alone do not require a dimension rebuild.

Rebuild Fails After Validation Succeeds

If validation succeeds but the rebuild fails, the source definition may no longer be the primary problem.

Investigate:

• Source-object access
• Current cube configuration
• Build concurrency
• Existing build locks
• Application state
• Exact rebuild error
• Recent application upgrade or configuration change

Run:

CALL CUBE.HEALTH_CHECK('FINANCE');

and review non-OK findings:

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

Then use the exact rebuild error to determine the next step.

Another Build Is Already Running

Casabase Cube uses build locks to prevent conflicting dimension operations from modifying the same structures concurrently. A dimension build acquires a lock while it is running.

If a rebuild reports that another build is already in progress:

1. Determine whether a legitimate rebuild is still running.
2. Do not start another conflicting rebuild.
3. Allow the active operation to finish.
4. Retry only after the active build has completed.

The lock is a concurrency safeguard, not an error to bypass.

Stale Build Lock

An interrupted build can leave a stale lock that prevents a later rebuild from starting.

Before clearing a lock, verify that no legitimate build is still running.

Conceptually:

Build Appears Locked
        │
        ▼
Is a Build Actually Running?
        │
        ├── Yes ──► Wait
        │
        └── No
              │
              ▼
       Treat as Stale Lock
              │
              ▼
       Use Documented
       Recovery Procedure

Use the current Rebuilding Dimensions or Operational Tasks documentation for the supported stale-lock recovery procedure.

Do not clear locks casually. Build locks exist specifically to prevent concurrent operations from corrupting or conflicting with dimension structures.

Build Completes but the Dimension Appears Empty

Run Health Check.

Relevant findings include:

• DIMENSION_TABLE
• DIMENSION_ROW_COUNT
• INPUT_TABLE_CONFIG
• CONFIG_INTEGRITY

Then verify the source definition actually contains the expected members.

A successful procedure call does not compensate for an empty or incorrectly filtered source definition.

See Using Health Check.

Build Completes but Members Are Missing

If only some members are missing:

1. Verify that the members exist in the source definition table.
2. Verify the member and parent mappings.
3. Check shared-member metadata where applicable.
4. Validate the dimension again.
5. Rebuild after correcting the source.
6. Run a verification query.

If the missing members were added to the source after the last rebuild, the active dimension will not reflect them until the applicable dimension is rebuilt.

Build Completes but the Hierarchy Is Wrong

When members exist but appear under the wrong parents, treat the issue as a source-definition problem first.

Review:

• Parent values
• Member values
• Root relationships
• Shared-member indicators
• Sort-order metadata
• Aggregation operators

The active hierarchy is constructed from the dimension definition table. Casabase Cube does not infer the intended business hierarchy independently of that metadata.

Correct the source, validate it, and rebuild.

Imported Essbase or Cloud EPM Dimension Has Problems

Dimension definition tables generated from an imported Oracle Essbase or Oracle Cloud EPM .otl are stored in the application’s SHARED_DATA schema.

If a migrated dimension does not build as expected:

1. Verify that the correct .otl was imported.
2. Review the generated definition table.
3. Validate the affected dimension.
4. Investigate shared-member, aggregation, or formula findings.
5. Correct supported migration issues as appropriate.
6. Rebuild and reconcile the resulting hierarchy with the source.

Do not fall back to an XML outline or CSV-per-dimension workflow. The current migration model uses the native .otl as the multidimensional metadata source.

See Oracle Essbase and Cloud EPM Migration.

Attribute Dimension Problems

Attribute dimensions have their own validation and build lifecycle.

If the failing object is an attribute dimension, use the attribute-specific procedures and documentation rather than assuming that every base-dimension recovery command applies unchanged.

Also consider whether the underlying base dimension changed. Dependent attribute structures may need to be rebuilt after relevant base-hierarchy changes.

Validate Before Production Rebuilds

For planned metadata changes, use validation before applying the rebuild.

A safer operational pattern is:

Modify Definition
      │
      ▼
Validate
      │
      ├── Error ──► Correct Definition
      │
      ▼
Rebuild
      │
      ▼
Health Check
      │
      ▼
Verification Query

This separates source-metadata errors from rebuild-time problems and reduces unnecessary failed build attempts.

Do Not Drop the Cube as a First Response

A failed dimension rebuild is not normally a reason to drop and recreate the cube.

DROP_CUBE is a destructive lifecycle operation.

Before considering recreation:

• Validate the dimension
• Correct the source definition
• Check source-object access
• Review build locks
• Run Health Check
• Review recent audit activity
• Generate support information

Preserve the current configuration before making destructive changes.

Recommended Diagnostic Sequence

For a dimension that will not build:

Capture Exact Error
        │
        ▼
Inspect Source Definition
        │
        ▼
VALIDATE_DIMENSION
        │
        ├── Fails
        │     │
        │     ▼
        │ Correct Metadata
        │     │
        │     └──────┐
        │            │
        ▼            │
REBUILD_DIMENSIONS ◄─┘
        │
        ├── Locked
        │     │
        │     ▼
        │ Check Active / Stale Lock
        │
        ├── Access Error
        │     │
        │     ▼
        │ Check Source Grants
        │
        ▼
HEALTH_CHECK
        │
        ▼
Verification Query

If the Problem Remains

Generate support information for the affected cube:

CALL CUBE.GENERATE_SUPPORT_INFO('FINANCE');

Collect:

• Cube name
• Dimension name
• Exact validation result
• Exact rebuild error
• Relevant source-table definition
• Recent metadata changes
• Health Check findings
• Whether another build was running
• Approximate time of the failure

Do not include passwords, private keys, authentication tokens, or other credentials.

See Getting Additional Help.

Related Topics

• Dimension Definition Tables
• Dimension Validation
• Rebuilding Dimensions
• Using Health Check
• Access & Permission Issues
• Formula Errors
• Operational Tasks
• Health and Diagnostics