1977584 – Technical Consistency Checks for SAP HANA Databases


You are interested in an pro-active SAP HANA consistency check
You already face symptoms that can indicate SAP HANA inconsistencies and want to check if and to what extent corruptions exist.

Reason and Prerequisites

This SAP Note covers options to check for technical SAP HANA inconsistencies.
This SAP Note doesn’t cover pure application related inconsistencies or deviations between the application view and the actual state on SAP HANA side (like e.g. reported via report RSDU_TABLE_CONSISTENCY in BW).
See SAP Note 2116157 for general information about SAP HANA consistency checks and corruptions.


The following options exist to check for technical HANA consistency:
1. Meta data: CHECK_CATALOG procedure

The CHECK_CATALOG procedure can be used to check the consistency of the HANA catalog meta data. Its parameters are:
  • CHECK_NAME: Type of action, e.g. ‘CHECK’ for performing all checks
  • SCHEMA_NAME: Name of analyzed schema
  • OBJECT_NAME: Name of analyzed object
  • OBJECT_TYPE: Type of analyzed database object (e.g. ‘TABLE’, ‘VIEW’)
A consistency check of the whole catalog can be done with the following command:
A consistency check of the meta data of table MARA in schema SAPSR3 is performed as follows:
The following individual checks are available:
Check name Description
CHECK_OBJECT_REFERENTIAL_INTEGRITY consistency of references in catalog object
CHECK_VALUE_DOMAIN consistency check of value domains in catalog object (table type, field types, …)
Be aware that this check only covers the meta data. The actual structure and data of tables and indexes is not covered.
See section “Catalog Consistency Check” in the SAP HANA Administration Guide for further details related to CHECK_CATALOG.

2. Row and column store: CHECK_TABLE_CONSISTENCY procedure

The CHECK_TABLE_CONSISTENCY procedure can be used to check the consistency of the structure and data of tables. Its parameters are:
  • ACTION: Type of action, e.g. ‘CHECK’
  • SCHEMA_NAME: Name of analyzed schema (NULL for all schemas)
  • TABLE_NAME: Name of analyzed object (NULL for all objects)
With the action ‘CHECK’ all available checks are executed. With ‘REPAIR’ all available repairs are performed.
For a complete check you can execute the following command:
It is also possible to execute the following individual checks and repair actions on SP8 and higher:
Check name Min. SPS Description Store
CHECK_COLUMN_TABLES all available checks restricted to column store tables Column
CHECK_COMBINED_KEY_COLUMN consistency of key columns to combined key column Column
CHECK_DATA_CONTAINER consistency of row store page and data container Row
CHECK_DATA_LENGTH check for actual data length of variable length field Row
CHECK_INDEXES consistency of indexes Row
CHECK_LOBS 10 consistency of LOBs Both
CHECK_METADATA_SEPARATION check if metadata and data are stored separately, not necessarily an issue, but can impact row store reorganization Row
CHECK_NOT_NULL_CONSTRAINT check for NULL value in NOT NULL fields Row
CHECK_PARTITIONING consistency of partitioning related meta data Column
CHECK_PARTITIONING_DATA check assignment of rows to partitions Column
CHECK_PRIMARY_KEY consistency of the primary key Column
CHECK_REPLICATION consistency of meta data of replicated tables Column
CHECK_REPLICATION_DATA_FULL full check of consistency of replicated data Column
CHECK_REPLICATION_DATA_LIGHTWEIGHT lightweight check of consistency of replicated data Column
CHECK_ROWID consistency of internal $rowid$ column Column
CHECK_ROW_TABLES all available checks restricted to row store tables Row
CHECK_VALUE_INDEXES consistency of internal value indexes Column
CHECK_VARIABLE_PART_BINDING check for variable part of table mixed with other tables Row
CHECK_VARIABLE_PART_DOUBLE_REFERENCE check for table-wise double reference to variable part Row
10 Check for table-wise and inter-table double reference to variable part Row
CHECK_VARIABLE_PART_SANITY check for sanity of logical pointers Row
REPAIR_PARTITIONING_DATA repair assignment of rows to partitions Column
For an overview of available checks you can also run:
The following table provides an overview of error messages that are reported by CHECK_TABLE_CONSISTENCY:
Min. SPS  Store Error Details
7 Row cannot find tableinfo failed to get required metadata for some reason
7 Row table is busy table lock acquisition failed
8 Row cid mismatch between page and table info there’s mismatched data between metadata
7 Row invalid field some parts of row table have unexpected values
7 Row broken NOT NULL constraint null value in not null column
7 Row invalid data length column whose actual data length is longer than its specification
7 Row broken variable part reference to variable part (containing the data of varchar, nvarchar, lob, …) of table is invalid
7 Row bad index problem with index, detailed information will be appended at the end of error message, error may disappear after database restart
7 Row unseparated variable part some parts of row table are stored in unintended location of memory
7 Row variable part double reference there are double references to variable part
7 Row broken variable part some parts of row table are stored in unintended location of memory
8 Row page consistency check failed mismatched data between memory storage and persistent storage
8 Row slot size mismatch between page and table info mismatched data between metadata
8 Column key column value is NULL at udiv NULL value in primary key
8 Column duplicate row visible in main table for key duplicate key in primary key
8 Column corrupt value at udiv combined index column is invalid (wrong search results possible)
8 Column externalkey concat at udiv combined key column is invalid
8 Column found illegal value 0 for rowid at udiv internal $rowid$ column is corrupt
8 Column found NULL rowid at udiv internal $rowid$ column is corrupt
8 Column duplicate rowid internal $rowid$ column is corrupt
9 Column Maximum rowid in table (<id1>) is larger than max rowid in runtime data (<id2>) in <schema>:<table> inconsistency between table and runtime data, see SAP Note 2125399 for more information
10 Both Invalid lob type Lob type of value doesn’t match lob type of column which owns it
10 Both (Column) Invalid inplace lob size
(Row) Invalid memory threshold
Lob value which is longer than memory threshold is placed in memory
10 Row Invalid lob owner id Lob owner id of value doesn’t match ids of column and table which own it
10 Column Consistency check failed for disk lob Inconsistency in disk lob
10 Row Pointing to free variable part some variable part of a certain record are marked as deleted
10 Row Variable part page has an invalid type some variable part of the table are broken
Column IndexMgr: index not found table exists in metadata, but is not physically accessible
TABLES lists the column table, but M_CS_TABLES doesn’t show it
Can be a consequence of errors like “Table.cpp(00111) : Exception in Table::Table <table_name>” and restart of nameserver may resolve the issue
Up to SPS 07 tables are locked during CHECK_TABLE_CONSISTENCY runs. In case of lock timeouts due to concurrent changes a “table is busy” error (# 2) is thrown. Starting with SP8 a lock is no longer required.
Rev. 71 and below can result in a significant number of false alerts, i.e. error messages that don’t indicate a real issue.
Up to rev. 80 CHECK_TABLE_CONSISTENCY can result in a crash if virtual tables are analyzed (SAP Note 2052419).
See section “Table Consistency Check” in the SAP HANA Administration Guide for further details related to CHECK_TABLE_CONSISTENCY.
In SAP ABAP environments (>= 7.40) you can schedule CHECK_TABLE_CONSISTENCY with transaction DB13 (Action = ‘Consistency Check’).

3. Column store: uniqueChecker.py script

The Python script uniqueChecker.py can be used to check for inconsistencies in areas like uniqueness, primary keys, indexes, partitioning, replication and NOT NULL constraints in the column store. It doesn’t cover tables that are located in the row store. Over time CHECK_TABLE_CONSISTENCY (see above) will more and more take over the functionality of the Unique Checker.
The script is located in the SAP HANA subdirectory exe/python_support. The following individual checks are executed per default:
See SAP Note 1666976 that describes the Unique Checker functionality in detail.

4. Row store: checkRowStore.py script

The script checkRowStore.py provides row store related checks. See SAP Note 1963791 for more information.
Due to the significant chance of false alerts it is not recommended to run this script in a regular basis.

5. Persistence checks:

Data backups (i.e. ‘complete data backup’) automatically check the persistence pages for correctness, e.g. proper checksums. If an inconsistency is recognized, the backup fails with an error. Only referenced pages are checked, corruptions in unused pages will not result in an error. This is okay, because corrupted unused pages are initialized when they are used the next time without looking at the recent corrupted content.
Backups based on storage snapshots (i.e. ‘data snapshot’) don’t provide this consistency check.
Corruptions in persistence blocks of tables are recognized when the table is loaded. A reload can be forced with the “-ub” option of uniqueChecker.py or with manual unloads / loads (SAP Note2127458). Be aware that massive unloads / loads consume significant resources and so you should use this option only in rare situations.

6. Backups: hdbbackupcheck tool

The consistency of database backups can be checked using the hdbbackupcheck tool. See SAP Note1869119 for more details.

7. Backups: hdbbackupdiag –check

The tool hdbbackupdiag can be used to check if the available backups can be used to restore the database in a consistent state (–check option). See SAP Note 1873247 for further information.

8. Existence of page dumps

The existence of page dumps can indicate page corruptions. See SAP Note 1977242 for more information.

9. Meta data: Topology consistency (SPS 08 and below)

Up to SPS 08 the SAP HANA topology is maintained by the nameserver and so it is theoretically possible that the nameserver and the indexserver have inconsistent information. You can check the consistency of the topology by using the repairTopology.py command available in folder /usr/sap/<sid>/HDB<inst>/exe/python_support:
python repairTopology. py –sqlUser=SYSTEM –sqlPassword=<password> –testRepair
If an inconsistency is reported, you can repair it using:
python repairTopology. py –sqlUser=SYSTEM –sqlPassword=<password> –execRepair
Starting with SPS 09 this check is obsolete, because the nameserver no longer maintains topology meta data.

Leave a Reply