This document was last modified on August 20, 2015

Table Consistency Check for BW Tables on HANA

(RSDU_TABLE_CONSISTENCY)

This document contains a brief description of the purpose and usage of the ABAP
report RSDU_TABLE_CONSISTENCY. Please note that checking for and repairing
inconsistencies needs constant changes and enhancements. This document is
therefore subject to frequent updates and will be delivered with note 1937062.

Table of Contents
1

Purpose.......................................................................................................................... 3

Delivery .......................................................................................................................... 3

Operation ....................................................................................................................... 3

3.1

Check tables for inconsistencies ............................................................................. 3

3.2

Repair inconsistencies ............................................................................................ 4

3.3

Restrictions ............................................................................................................. 4

How to use RSDU_TABLE_CONSISTENCY? ................................................................ 4

4.1

How to check a system for inconsistent tables? ...................................................... 4

4.1.1

Data selection .................................................................................................. 4

4.1.2

Operational modes ........................................................................................... 5

4.1.3

Available Consistency Checks ......................................................................... 5

4.2

How to obtain Consistency Check results? .............................................................. 6

4.3

How to interpret Consistency Check results? .......................................................... 8

How to repair inconsistencies? ....................................................................................... 9

Description of Check Scenarios.....................................................................................11

6.1

CL_SCEN_DEAD_TABLES ...................................................................................11

6.2

CL_SCEN_SEC_INDEX ........................................................................................11

6.3

CL_SCEN_PRIMARY_KEY ...................................................................................11

6.4

CL_SCEN_PARTITION_SPEC ..............................................................................11

6.4.1

Expected Partitioning of PSA tables ................................................................12

6.4.2

Expected Partitioning of DSO tables ...............................................................12

6.4.3

Expected Partitioning of Fact Tables ...............................................................13

6.4.4

Additional restrictions for NUMSERVERS .......................................................13

6.5

CL_SCEN_STORAGE_TYPE ................................................................................14

6.6

CL_SCEN_COMPRESSION ..................................................................................14

Frequently obtained error messages and warnings .......................................................14

Page 1 of 16

Special topics ................................................................................................................15

8.1

The Expert parameters ........................................................................................15

Page 2 of 16

Purpose
RSDU_TABLE_CONSISTENCY checks the consistency of table properties on HANA with
certain needs and restrictions defined by SAP BW application. The report should help to
ensure a consistent work of BW functionality on HANA DB and its suggested to run after
critical processes like migration, restore etc. Moreover, you can use this report during regular
operation, if error messages or slow performance are suspected to be caused by
inconsistencies of BW tables on HANA.

1 Delivery
Since RSDU_TABLE_CONSISTENCY is part of the regular SAP BW coding it is delivered
with the support packages of the releases 7.30, 731, 7.40 and above. Moreover the latest
corrections and enhancements will be available with the notes 2163258 (SAP_BASIS) and
2164519 (SAP_BW). Please note that the note numbers will change from time to time. It is
updated in each case in this document. Its important to apply the notes above in the correct
sequence: first apply SAP_BASIS followed by the note for SAP_BW! You need to apply the
latest notes only.
To avoid unnecessary problems when implementing notes, it is advisable to previously
ensure the correct operation of SNOTE with the note 1668882.
Table 1: History of notes for RSDU_TABLE_CONSISTENCY

Change No.

Note for
SAP_BASIS

Note for
SAP_BW

07

2163258

2164519

06

2093836

2099114

05

2025241

2025271

04

1953984

1953493

03

1892492

1888511

02

1814339

1814097

2 Operation
The operation of the report is strongly divided into two parts: Check and Repair, which
cant be combined in a single run!

2.1 Check tables for inconsistencies

RSDU_TABLE_CONSISTENCY reads all tables from HANA DB, filters them in order to
investigate BW relevant tables only and performs a number of well defines check scenarios.
For each table the corresponding BW objects (Cubes, DSOs etc.) are identified and
requested for the expected table properties on HANA. If a difference is detected between the
expected table property and the property of the table obtained in HANA, an issue is stored in
Page 3 of 16

an Issue Store.1 Apart from the storage of the issues, the check for inconsistencies is
pure read-only for both HANA and BW.

2.2 Repair inconsistencies

Theres no automatic check & repair option intended with this report, since any inconsistency
needs to be reviewed. Moreover, repairing HANA tables might be time/memory consuming
operations which are not suitable for automatic run in productive environments.
Therefore, a user must first select the issues to be repaired before it can start the repair
sequence. Repairing an inconsistence always performs a write action on HANA table
properties the repair will never chance any BW metadata!

2.3 Restrictions
RSDU_TABLE_CONSISTENCY will work with HANA DB only. It will not regard a HANA DB
at secondary DB connections.
The report can analyze only tables of BW objects which are activated and consistent within
their BW metadata.

3 How to use RSDU_TABLE_CONSISTENCY?

The report is available in any SAP BW systems of Release 7.30, 7.31, 7.40 and above. It
can be launched from the transaction SE38.

3.1 How to check a system for inconsistent tables?

In Figure 1 the selection screen of the report is shown, if no previous checks are stored. Here
the consistency check can be configured within three sections:
3.1.1

Data selection

By default the Table names field remains empty. In this case all tables found on HANA DB
will be checked, if they are relevant for BW2. Alternatively a selection of tables can be
provided by including or excluding (multiple) table names and/or ranges. Also the use of
wildcards (*) is supported.

Example: select all E- and F-fact-tables in HANA:

Choice the multiple selection button

Enter /BI*/E* and /BI*/F* in the first two lines of tabulator Select Single Values

Technically this is the table SHDB_CLUSTER

Relevant for BW are HANA tables of InfoCubes (E- and F-fact-tables, dimension tables, validity
tables), DSOs (active data, activation queue, change log), PSA tables (including error stacks, fast
store) and InfoObjects.
2

Page 4 of 16

Figure 1: Initial selection screen of the report RSDU_TABLE_CONSISTENCY

3.1.2

Operational modes

If there are no stored issues, only two possible modes are displayed in this section:
Show issues in GUI will perform the consistency check and display the found issues on
screen only. This is intended to get a quick view of the consistency for only few tables, if no
repair is wanted and no storage of the result is needed. Please note: the results are lost,
after leaving the report.
Store issues will perform the consistency check like above but the results are stored in the
issues store. You can review the issues later, since they are persistent. This is the
prerequisite to repair the found issues later.
3.1.3

Available Consistency Checks

In the 3th section you can enable several check scenarios where the selected tables are
checked for certain properties. Not all scenarios are relevant for any type of tables. However
in most cases its recommended to select all available scenarios. Please refer a description
of the available consistency check scenarios in section 5 (on page 11).
As usual with ABAP reports, the consistency check is started with the F8 key resp. icon .
Since the report may need a long runtime if lots of tables are checked, its reasonable to run
this report in background via menu Program -> Execute in Background. Please note: if you
run the program in background, any results will be available only with usage of the
operational mode Store issues!

Page 5 of 16

3.2 How to obtain Consistency Check results?

The access to the results of the consistency check depends from the operational mode
selected by the user:
If Show issues in GUI was selected, the results are available only within the currently
loaded report by double-click the issue in the log screen as shown in Among lots of
messages informing about status or errors occurred during the runtime, the message issue
found (double click for details) indicates that inconsistencies in check given the right column
(Context of message) were found.

In the Example which is marked in

Figure 2 (on page 6) a double-click on the line 749 will access the found issues of the
scenario CL_SCEN_PARTITION_SPEC.

Please note: After the report is closed, the results are not available anymore!

Figure 2: Log screen with link to found issues

If the mode Store issues was selected, the log screen is displayed too (in case of online
processing), but all found issues are additionally stored in the issue store and youll find an
additional section in the initial screen as shown in
Figure 3 (on page 7) named Issues from previous checks.

Page 6 of 16

Figure 3: Initial screen after issues are stored

Here youll find the overall number of found issues as well as the number of already selected
issues. Using the button
an overview of issues found in the various check scenarios
will be displayed as shown in Figure 4 (on page 7). In this example some check scenarios
results numerous inconsistencies.
This screen provides an overview at an overview of when and by whom any missing
references were found. Whenever the consistency check is performed again and
inconsistencies are found, they are added here.

In the Example (as shown in Figure 4) 31 issues found during the partition check
scenario is marked among lots of other results.

Figure 4: Overview about found issues by check scenario

A detailed view of the found inconsistencies of a particular check scenario will be displayed
when you double-click on the relevant line. In Figure 5 (on page 8) the corresponding
Example of the detailed view is shown.

Page 7 of 16

Figure 5: Detailed view of found issues of the partition spec scenario

3.3 How to interpret Consistency Check results?

Please keep I mind, that the displayed columns in the table at different check-scenarios
differ. Usually following information will be provided with all scenarios:

1. Exception: Provides information on the severity of the issue.

Red: Inconsistency found or error occurred. There is a need of repair, or
failure must be eliminated with further tools
Yellow: Warning of unexpected results, but there's no immediate action
needed
Green: additional info no action required
2. Status: indicates the current state of the issue regarding a possible repair action.
OK: no error or inconsistency just info
REPAIRABLE: this inconsistency should be repairable within
RSDU_TABLE_CONSISTENCY
IRREPARABLE: an inconsistency or an error occurred during the check which
cant be solved within the report. Additional actions or analysis needed to
solve this issue
Page 8 of 16

REP. FAILED: an inconsistency, in which a repair attempt failed. Refer the

entry in column Reason.
REPAIRED: indicates that the issue was successfully repaired.
3. Type: shows the type of table like Fact tables, PSA etc.
4. Reason: This describes the reason why a table is classified as inconsistent. For
errors that have occurred during the check, the error text is shown. Some frequently
occurring errors are described in section 6 (Frequently obtained error messages and
warnings at page 14).
5. Table: shown the table name
6. BW Object: shows the BW Object (InfoCube name, DSO name etc.) the table is liked
with.
Depending on the check scenario, additional columns are displayed. In most cases the table
property as expected by BW application is compared with the same property as obtained on
HANA.

In the Example marked in Figure 5, a fact table is classified to be inconsistent

because of the BW expects another partition spec (column expected spec.) than it
was found in HANA (column obtained spec). This issue is marked to be repairable
since RSDU_TABLE_CONSISTENCY should be able to repair the inconsistency by
changing the table into the expected partition spec on HANA.

4 How to repair inconsistencies?

Using the report RSDU_TABLE_CONSISTENCY you can repair inconsistencies that were
previously found and stored by the various check scenarios (see section 3.1. at page 4).
First, the issues that are to be repaired must be selected. The steps to view the issues are as
described in section 3.2 .
In Figure 6 an example of multiple selected issues from partition spec scenario regarding
ODS tables is shown. The entire functionality of common ALV table views is supported. So
you can sort, filter and select3 the issues as needed.
Before you leave this screen (via
button), please ensure that you save your selection
using the button . You can select issues from multiple check runs or check scenarios, if
you leave the detailed view and choice another one from the overview screen (Figure 4). All
selected issues will be added to the work pool of tables selected for repair.

Please use the first (selection-) column and the [Ctrl]-Key in order to select multiple ranges of issues.
If you want to select all issues, use the
button above.

Page 9 of 16

Figure 6: Issues selected for repair

After selecting the issues for repair go back to the initial screen. Here a third operational
mode Repair is available. If this mode is selected the scenario list vanishes, since check
scenarios are irrelevant in this mode. As shown in Figure 7 a number of issues is selected
now.
Starting the report with the button
will repair the selected issues. However, since any
repair contains write processes on HANA the runtime might be quite long. Therefore its
recommended to run RSDU_TABLE_CONSISTENCY in repair mode always in background
in order to avoid timeout errors.

Page 10 of 16

Figure 7: Operational mode "Repair" with 17 issues selected for repair

5 Description of Check Scenarios

5.1 CL_SCEN_DEAD_TABLES
This scenario checks all fact tables (/BI*/E* and /BI*/F*) which are found in HANA DB and
which are known in SAP system (via table DD02L). The check is fulfilled, if the table is known
in any InfoCube found in the system.
This issue will be repaired by deleting the table from HANA DB as well as from DDIC.

5.2 CL_SCEN_SEC_INDEX
Fact tables should have no secondary indices, neither on HANA DB nor in the data
dictionary. This scenario checks all fact tables for secondary indexes and proposed them to
delete the secondary indexes from HANA DB as well as from DDIC if found any.

5.3 CL_SCEN_PRIMARY_KEY
In SAP BW all fact tables, PSA tables as well as tables of Write Optimized DSOs should not
have primary keys. The primary key scenario checks this tables for primary key on HANA DB
and proposed the table to delete the primary key from HANA DB if found one.

5.4 CL_SCEN_PARTITION_SPEC
This scenario reads the partition specs of BW tables from HANA DB and compares them
with the partitioning expected by BW application. Due to the increased importance of table
partitioning in HANA, it may be the most frequent used check scenario in this consistency
check report. This check is relevant for tables maintained by PSA-service (PSA-Tables), the
Page 11 of 16

Active Tables and Activation Queues of DSOs as well as the E- and F-Fact Tables of
Infocubes.
5.4.1

Expected Partitioning of PSA tables

Tables using the BW naming conventions /BI*/B* (e.g. ErrorStacks, ChangeLogs, FastStore
etc.) are expected to have a HASH partitioning in first level and may have a RANGE
partitioning in second level. The HASH partitioning contains the technical key of the DSO:
HASH <NumServers> REQUEST, DATAPAKID, RECORD
where <NumServers> is the number of servers to which the table is distributed. Whether a
RANGE partitioning is expected or not, depends on certain factors:

The field PARTNO in table RSTSODS contains a value of 2 or larger

The table is already RANGE partitioned on HANA DB

The RANGE partitioning on HANA DB doesnt contain a zero value

Therefore RSDU_TABLE_CONSISTENCY will accept PSA tables without RANGE

partitioning as consistent. If RANGE partitioning is expected, the partition spec should look
like this:
RANGE PARTNO <val1>,<val2>, , <valN>
where <val1> to <valN> are integer values. The largest value <valN> corresponds to the
value of the field PARTNO in table RSTSODS by: <valN> = RSTSODS-PARTNO - 1
5.4.2

Expected Partitioning of DSO tables

RSDU_TABLE_CONSISTENCY regards tables with naming convention /BI*/A*00 as DSO

Active Tables and with /BI*/A*00 as DSO Activation Queues. The expected partitioning
depends from the type of DSO: Standard or Write-Optimized DSO.
In case of Standard DSO two levels of partitioning are expected. First is a HASH partitioning
containing the semantical key of the DSO:
HASH <NumServers> <SemKey1>, <SemKey2>, , <SemKeyN>
with <NumServers> the number of servers to which the table is distributed. The second level
partitioning are RANGE partitions containing the values of a time-defined field (like
CALMONTH or FICALYEAR):
RANGE <TimeField> <T1>, <T2>, ..., <TN>
The partition spec of Write-Optimized DSOs depends from the usage of Unique Key4 and
explicit partitioning as configured for the DSO:

The property Unique Key corresponds to the attribute "Allow Duplicate Data Records, which can
be maintained for a DSO e.g. via TA RSA1.

Page 12 of 16

If Unique Key is used, the First level HASH partitioning is expected to contain the semantical
key of the DSO
HASH <NumServers> <SemKey1>, <SemKey2>, , <SemKeyN>
Otherwise the first level HASH partitioning will be checked to contain the technical key, like:
HASH <NumServers> REQUEST, DATAPAKID, RECORD
Please note: Since there no significant performance impact as well as no functional gap,
missing semantical keys in the HASH partition specification will be tolerated and not marked
to be inconsistent.
The Active Table and the Activation Queue of Write-Optimized DSOs may be RANGE
partitioned at second level via PSA service. If so, for the second level partitioning the same
rules and limitations as described for PSA tables are expected:
RANGE PARTNO <val1>,<val2>, , <valN>.
5.4.3

Expected Partitioning of Fact Tables

Fact tables of infocubes with the naming convention /BI*/E* and /BI*/F* are expected to have
a two level partitioning: First level a ROUNDROBIN partitioning is expected:
ROUNDROBIN <NumServers>
with <NumServers> describing the number of indexservers the table is distributed. The
second level RANGE partitioning is built by the Package Dimension as stored in the PDimension-Table /BI*/D*P.
In a Classical Cube the F-Fact-Table the packages for normal values and reference points
are represented in the range partition specification together with a rest partition *
RANGE <PackageDimension> <normal>, <refpoint>, *
The E-Fact-Table additionally expects a range for the historic values:
RANGE <PackageDimension> <normal>, <refpoint>, <historic>, *
In a Flat Cube the E-Table doesnt exists. The Check expects following RANGEPARTITIONING for the F-Table:
RANGE <PackageDimension> <normal>, <refpoint>, <historic>, *
5.4.4

Additional restrictions for NUMSERVERS

Corresponding tables like Active Table and Activation Queue of DSOs or E- and F-Fact
tables in classical cubes are expected to have the same number of first level partitions. This
restriction is essential for a number of important processes in SAP BW (e.g. Conversion of
Infocubes to Flat Cubes). Therefore an Expert-Option (See section 7.1) Force
NUM_SERVERS check enables an additional check, expecting the HASH- and RANGEPartitioning has the same values of <NumServers> for the corresponding tables on HANA
DB.

Page 13 of 16

5.5 CL_SCEN_STORAGE_TYPE
To Be Done!

5.6 CL_SCEN_COMPRESSION
To Be Done!

6 Frequently obtained error messages and warnings

Table class BW_AGGR not expected on HANA DB:

This is a warning, only: BW on HANA doesnt use BW aggregates anymore.
However, it may happen that aggregates still exist in the system after a migration, but
their existence is not critical. Since RSDU_TABLE_CONSISTENCY should not
change BW metadata, this issue is marked to be IRREPARABLE. Usually BW
aggregates will be removed using the report RS_BW_POST_MIGRATION (see note
2017638).

ERROR (3) at table <tab>: Number range for package dimension is inconsistent:

The report is unable to read the package dimensions due to an inconsistency within
the InfoCube metadata and subsequently cant determine the RANGE partitioning.
Please refer transaction RSRV for checking the relevant cubes.

Dimension table <tab> doesnt exist:

The report is unable to read the package dimensions due to the dimension table
doesnt exists and subsequently cant determine the RANGE partitioning. Please
refer transaction RSRV for checking the relevant cubes.

ODS object is not active:

Only active ODS objects can be checked for consistent table properties. This
message points to the fact, that the related ODS object was not activated. Use
transaction RSA1 to activate it.

Unable to create ODS object:

The report cant create an ODS object in order to determine expected table
properties. Please refer transaction RSRV for checking the intrinsic consistence of the
concerning DSO.

Authorization error in SHDB_TABLE_PLACEMENT expected:

This error occurs during the table classification scenario, if there is no access granted
for the tables _SYS_REPO.SCHEMAVERSION or _SYS_RT.TABLE_PLACEMENT.
Please refer note 1908075 (BW on HANA SP6: Landscape Redistribution) and grant
the required permissions in HANA Studio.
Page 14 of 16

Table Placement expected but not maintained:

This error occurs during the table classification scenario, if the HANA DB expects to
find table placement rules in the table _SYS_RT.TABLE_PLACEMENT but this table
is empty. For details please refer note 1908075 (BW on HANA SP6: Landscape
Redistribution).

Unable to determine CalcViews:

There was an error in ABAP coding, generating an incorrect SQL statement for
determining Calculation Views on HANA DB. This error message can be ignored,
since the requested objects are actually not used for any check scenarios.

7 Special topics
7.1 The Expert parameters
Due to some unexpected problems with inconsistencies concerning HANA DB, the report
RSDU_TABLE_CONSISTENCY was extended with some additional functions. They are
accessible by typing the word expert in the command line of the initial screen.
Please note: The use of this expert-parameters should not be needed in regular
work. But it will help in situations to detect and correct certain error conditions.

Ignore BW locks is only relevant for repairing issues. This forces the repair process
not to regard locks on BW objects. It can be needed, if BW processes results errors
due to inconsistent HANA tables but doesnt release their lock for some reasons (e.g.
RSMIGRHANADB raised an error like flatten scenario failed
Please be careful! Dont use it for repairing large number of tables, because of
competing write access to the tables can lead to further inconsistencies!

Parallel repair runs the repair actions on multiple HANA servers simultaneously. Its
reasonable, if a large number of tables need to be repaired on a scale-out system.

Force NUM_SERVERS check is a special check for HASH partitions of DSO- and
Fact-Tables. Usually RSDU_TABLE_CONSISTENCY doesnt check the number of
servers in HASH partitions. But in certain cases it needed to check, if the number of
HASH partitions of the active table and the activation queue is the same.

Force table classification allows checking the classification of HANA tables without
regarding if Table Placement is active or not. This might be reasonable in case of
authorization problems with the table _SYS_REPO.SCHEMAVERSION or
_SYS_RT.TABLE_PLACEMENT. Please dont use this parameter without explicit
suggestion by SAP support.

Page 15 of 16

Check all tables (storage type only) enables (in contrast to section 2.1) to check all
SAP tables found on HANA for the correct storage type (row store or column store).

Enable table location check might be needed if Landscape Redistribution cant be

processed for some reasons. It enables the scenario CL_SCEN_TAB_LOCATION,
which checks and repairs the location of partitions of corresponding tables (e.g.
partitions of E- and F-fact tables located on the expected slaves in order to process
the Cube Conversion successfully).
But be carefully: this ensures the consistency of table locations regarding minimal
requirements of BW only! It is not an optimal distribution of tables as Landscape
Reorg provides for performance reasons!

Page 16 of 16