Pre-Migration Check Tool SMIGR_CHECK_DB6: Be Bette...

Thomas_Matthä · ‎10-02-2022

With this blog post, I’d like to introduce you to the new SAP pre-migration check tool SMIGR_CHECK_DB6. It’s very helpful in the following cases:

You want to perform an SAP system copy using the R3load method, for example, to the cloud and keep Db2 for Linux, UNIX, and Windows (LUW) as your database system.

You’re using range partitioning for tables in your SAP system running on a Db2 for Linux, UNIX, and Windows database.

You have customized LOB inline settings for special columns on binary column types.

You have user-defined data classes in your SAP system.

There are several table types in your system: row-organized, column-organized, multidimensional clustering (MDC) tables, and insert time clustering (ITC) tables

With the SMIGR_CHECK_DB6 tool, you get a good overview of the source system’s specifics that need to be considered when migrating.

Overview

To get started, call transaction SE38 in your SAP system and execute the program SMIGR_CHECK_DB6.

The start screen of the SMIGR_CHECK_DB6 tool looks like this:

Start Screen of SMIGR_CHECK_DB6 in SAP GUI

The “General System Information” section displays the system’s table types and number of tables, that is, how many column-organized, multidimensional clustering (MDC), and insert time clustering (ITC) tables there are.

In addition, the concurrency threshold setting of the workload management (WLM) is displayed.

The other sections on the start screen provide you with information about the following:

Range-partitioned tables

Tables with user-defined LOB inline length

User-defined data classes

Tables with a mismatch between data class assignment and physical table location

Procedure

Let’s go into more details and learn how to interpret the information in the different sections of the SMIGR_CHECK_DB6 main screen.

Tables With Range Partitioning

This section shows all range-partitioned tables together with the number of partitions.
To see the partitioning part of the DDL, choose the Show DDL button in the Details column.

Example of "Partitioning Part of the DDL" Popup for Table CDHDR

NOTE: We recommend that you use extra tablespaces for range-partitioned tables that are different from the tablespaces defined in the SAP data classes.

Example:

Let’s say table CDHDR is range-partitioned with three partitions. As recommended, you should use separate tablespaces for the partitions with tablespace names derived from the table names:

 	data: CDHDR_1D, index: CDHDR_1I, long: CDHDR_1L

 	data: CDHDR_2D, index: CDHDR_2I, long: CDHDR_2L

 	data: CDHDR_3D, index: CDHDR_3I, long: CDHDR_3L

The column “As recommended” indicates whether the partition-specific tablespaces follow this recommendation or not:

Tables With Modified LOB Inline Length

Here, all database tables with user-defined LOB inline sizes are listed together with their columns. This section also shows the default LOB inline length that is set by the DBSL for the respective column dependent on your SAP and Db2 release, the data type, and length of the column. If this default value was changed by a customer, the table and column show up in this list.

User-Defined Data Classes

In this section, all user-defined data classes are listed together with the number of tables that are assigned to these data classes.

Mismatch Between Data Class Assignment and Physical Table Location

In this area of the screen, you get a list of tables with tablespace inconsistencies.

Background: What’s the story behind this mismatch/deviation?

On the one hand, in the SAP ABAP Dictionary, each table is assigned to a data class. This means that each table belongs to exactly one data class. The data classes in an SAP system then map to a specific data tablespace, index tablespace, and long tablespace or tablespace pool.

On the other hand, each database table resides in a specific tablespace on the database. Ideally, these two definitions should match, that is, the assigned data class of a table should map to exactly the tablespaces where the table really resides.

But for several reasons, tables might have been moved to different tablespaces in the past without adaptation of the data class assignment in the ABAP Dictionary’s metadata. Therefore, the tablespace definitions for the physical location of the table and the data class mapping might not match any more.

Example:

Table /BIC/ADSO100 is assigned to data class DODS. This data class maps to D01#ODSD as data tablespace, and D01#ODSI as index tablespace. While table /BIC/ADSO100 resides on the data tablespace D01#ODSD, the index tablespace of the table is D01#ODS2 and not D01#ODSI.
Because of this deviation, the index tablespace D01#ODS2 is highlighted and shown as inconsistent. Another deviation occurs for the data tablespace of table /BIC/ADSO140.

So, based on your findings using the SMIGR_CHECK_DB6 tool, you can consider next steps on your source system, such as, for example, moving tables to other tablespaces with the help of the DB6CONV tool, or adapting data classes to eliminate inconsistencies that might impact the migration.

Conclusion

The program SMIGR_CHECK_DB6 is a tool for migration experts. It gives you an overview of special table types and your system setup. It also helps you identify areas that might lead to problems during the migration of an SAP system.

Before a Db2 LUW system migration, you can use this tool to identify inconsistencies on the source system in an early phase of your migration project and therefore well prepare your system for the migration (for example, to the cloud).

I’d like to thank everyone who contributed to this blogpost, especially my colleagues from IBM & SAP Dirk.Nakott and Karen.Kuck.

Feel free to provide feedback in the comment section.
Also check out our community page for more information on SAP on Db2 for LUW.