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

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

3 Operation ....................................................................................................................... 2

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

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

3.3 Restrictions ............................................................................................................. 3

4 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

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

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

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

8 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 it’s 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 can’t 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

There’s 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.

1

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 it’s 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, it’s 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 you’ll 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 you’ll 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 can’t 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

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.

3

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.

Figure 6: Issues selected for repair

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 it’s 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 doesn’t 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 can’t determine the RANGE partitioning. Please refer transaction RSRV for checking the relevant cubes.

• Dimension table <tab> doesn’t exist: The report is unable to read the package dimensions due to the dimension table doesn’t exists – and subsequently can’t 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 can’t 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 doesn’t release their lock for some reasons (e.g. RSMIGRHANADB raised an error like “flatten scenario failed ...” Please be careful! Don’t 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. It’s 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 doesn’t 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 don’t 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 can’t 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