This document was last modified on May 20, 2014

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.

Contents
1

Purpose.......................................................................................................................... 2

Delivery .......................................................................................................................... 2

Operation ....................................................................................................................... 2

3.1

Check tables for inconsistencies ............................................................................. 2

3.2

Repair inconsistencies ............................................................................................ 2

3.3

Restrictions ............................................................................................................. 3

How to use RSDU_TABLE_CONSISTENCY? ................................................................ 3

4.1

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

4.1.1

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

4.1.2

Operational modes ........................................................................................... 4

4.1.3

Available Consistency Checks ......................................................................... 4

4.2

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

4.3

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

How to repair inconsistencies? ....................................................................................... 8

Description of Check Scenarios.....................................................................................10

Frequently obtained error messages and warnings .......................................................10

Special topics ................................................................................................................11

8.1

The Expert parameters ........................................................................................11

Page 1 of 11

1 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.

2 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 1953984 (SAP_BASIS) and
1953493 (SAP_BW). Please note that the note numbers will change from time to time. It is
updated in each case in this document.

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

3.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
an Issue Store.1
Apart from the storage of the issues, the check for inconsistencies is pure read-only for
both HANA and BW.

3.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.

Technically this is the table SHDB_CLUSTER

Page 2 of 11

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!

3.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.

4 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.

4.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:

Figure 1: Initial selection screen of the report RSDU_TABLE_CONSISTENCY

Page 3 of 11

4.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
4.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.
4.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 6 (on page 10).
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!

4.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.
2

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.

Page 4 of 11

In the Example which is marked in

Figure 2 (on page 5) 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 6) named Issues from previous checks.

Page 5 of 11

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 6). 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 7) the corresponding
Example of the detailed view is shown.

Page 6 of 11

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

4.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 the 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
REP. FAILED: an inconsistency, in which a repair attempt failed. Refer the
entry in column Reason.
Page 7 of 11

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 7 (Frequently obtained error messages and
warnings at page 10).
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.

5 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 4.1. at page 3).
First, the issues that are to be repaired must be selected. The steps to view the issues are as
described in section 4.2 .

Page 8 of 11

Figure 6: Issues selected for repair

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.
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.

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 11

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

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.

6 Description of Check Scenarios

To be done

7 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.
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.
Page 10 of 11

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_REPO.TABLE_PLACEMENT. Please refer note 1908075 (BW on HANA SP6:
Landscape Redistribution) and grant the required permissions in HANA Studio.

8 Special topics
8.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 an scale-out system.
Force NUM_SERVERS check is a special check for HASH partitions of ODS 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_REPO.TABLE_PLACEMENT. Please dont use this parameter without explicit
suggestion by SAP support.
Check all tables (storage type only) enables (in contrast to section 3.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 Reorg cant for some
reasons not be processed. It 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 11 of 11