Building ElastiCubes

Last updated: November 10, 2026

After defining a schema and connecting your data tables, it's time to build your ElastiCube. Building an ElastiCube imports the data from the data source(s) that you added. The data is stored on the Sisense instance and future dashboard queries will be run against it. You must build an ElastiCube at least once before the ElastiCube data can be used in a dashboard.

For help with build related memory issues, see Troubleshooting Performance Issues.

Watch this short video for an overview of the build settings:

Builds can be monitored in the Build log window, shown in the upper-right of the screen once a build is launched. If your data set is very large, a build may take some time. Build time varies depending on various factors, such as the amount of data being imported. You can cancel the build, by clicking the Cancel button located in the build log, opened when you run a build.

To build an ElastiCube:

1. In the Data page, open the relevant ElastiCube and click . The Build options window is displayed.

   
   

2. Select one of the following build options:

   • Replace All - Builds the ElastiCube from scratch by utilizing the current data from all of the data sources. This option creates a new ElastiCube snapshot of the database. Once the build is complete queries are routed to the new snapshot, and the old snapshot is purged.
   • By Table - Builds the ElastiCube based on a per-table definition. A table that dose not have a build type definition (Build All / Build Changes) is built from scratch. This type of build has a non-blocking mechanism, by creating two ElastiCube snapshots; an 'original', and an 'alternative'.
   • Changes Only - Builds the ElastiCube by adding new tables and / or updating tables with a modified schema (e.g., a new column, a data type change, a custom column added, etc.). For an in-depth description of these settings and their implications, see Defining ElastiCube Build Settings.

   Note:

   • The By Table option requires a duplication of the storage required.
   • The By Table option only becomes available once at least one table is configured with a non-default build type.

3. (Optional) Toggle the Sample Data switch to limit the number of rows imported. The counter determines the maximal amount of rows queried from each individual table.

   This is useful for building samples of your data and reduces the overall amount of time it takes to build an ElastiCube. It is especially relevant when running development cycles rather than working with the entire dataset, saving time by avoiding building and validating logic for larger data.

4. Click Build

   A pop-up opens and displays the build log. The log describes the build process. When the build is complete, the following message appears in the logs: Build Succeeded

   Note:

   • If the log screen stops updating during a build, the actual build continues to run in the background. In such cases, refresh the screen, and from the menu click View Latest Logs.

Data Corruption Validation

During a build, Sisense creates internal dimension tables in the ElastiCube. These tables are not part of your data model or semantic layer, and you do not create or configure them. Sisense creates a dimension table for:

• Each text column that has the Indexed setting enabled (enabled by default). For more information, see Managing Tables and Columns.

• Each column that is used in a relationship between tables, even if its Indexed setting is disabled.

Each dimension table stores the values of its column together with a unique key that Sisense generates for each value during the build. Indexing improves query performance.

In rare cases, a dimension table can become corrupted during the build. When this happens, the build may succeed, but the data that is presented in table previews or in widgets will be inconsistently invalid. For example, a table preview can show the actual number of rows in the table, while the table display is empty.

What the Validations Check

To prevent corrupted data from reaching your dashboards, data corruption validation verifies that all dimension tables are valid. If they are not, the build fails.

The relevant settings are:

• "DataIndexingValidation" - Validates that all keys and values in dimension tables are unique.

• "RelationDimTablesValidation" - Validates that all dimension tables that were created for relations between tables include all of the possible keys and values.

• "IndexingDimTablesValidation" - Validates that all dimension tables that were created for indexing include all of the possible keys and values. The build counts the number of rows in the base table and the number of rows returned by an inner join between the base table and the dimension table of the indexed column. If the two counts are not equal, values are missing from the dimension table and the validation fails.

• "DataIndexingErrors" - Determines whether to fail the build if any of the three validations above fails.

Why Rebuilding Resolves the Issue

The keys in dimension tables are generated by Sisense during the build. They are not taken from your source data. Therefore, a validation failure does not mean that your data contains duplicate or non-unique keys, and you do not need to change your queries or your data model.

Dimension table corruption occurs inconsistently. Because a rebuild starts from scratch and recreates all of the dimension tables, the next build usually succeeds.

Automatic Retry

A specialized retry mechanism exists for dimension table corruption detection during cube builds. A configuration property, "NumberOfBuildRetriesDimTable", is located under the build service configuration. Its value can be set to the range of 0 to 2 (default = 1). Whenever the build fails due to dimension table corruption detection and the value is 1 or 2, a retry of the entire build, from scratch, is immediately triggered. This specialized retry mechanism is in addition to the "RetryBuild" and "RetryOnManualBuilds" features, and to the Build Retry settings.

Starting in L2026.4.1, a known cause of dimension table corruption has been fixed: a timing conflict during parallel processing that could cause builds to randomly fail with error BE#022427 when data indexing was enabled. If your builds frequently fail due to dimension table corruption on an earlier version, consider upgrading.

Troubleshooting

If a build fails due to dimension table corruption detection (for example, with error BE#022427), rebuild the ElastiCube, or let the automatic retry rebuild it. If the build fails again on consecutive builds, contact Sisense Support.

Changing the Validation Settings

The validation settings can be configured by navigating to Admin > Server & Hardware > System Management > Configuration > Build.