This blog discusses the table comparison and the migration tools of Software Update Manager (SUM) and database migration option (DMO). As a prerequisite, you should read the introduction document about DMO: Database Migration Option (DMO) of SUM – Introduction
Explanation of terms
SUM and DMO
Software Update Manager (SUM) has several use cases, one of these is database migration option (DMO). DMO combines the update/upgrade of the SAP software with the database migration to SAP HANA database.
❗ Note: DMO is not a tool, it is one of several use cases for SUM.
DMO compares number of table rows
DMO will in any case compare the number of rows for each table before and after the migration – we call this count*.
DMO may compare content of table rows
As part of the DMO migration, you can optionally switch on the table comparison of DMO. This will – in addition to count* – compare the content of table rows before and after the migration. Comparing the table content will extend the downtime, so it is not recommended to enable table comparison for a DMO run on a productive system.
Note: You may consider enable the table comparison in a productive run as well i.e. for certain tables only, if it is required to prove that the content is identical.
SUM may compare content of table rows for classical migration
The SUM offers the new use case “table comparison standalone” that can be used as an optional step for a classical migration.
The classical migration is the heterogeneous system copy offered by the Software Provisioning Manager (SWPM). So for the classical migration as such, the SUM is not used, as for a migration to SAP HANA, you can decide to either go for the classical migration using the SWPM, or go for the DMO using the SUM.
For more information on this topic, see Migration of SAP Systems to SAP HANA.
In former times, you could only use the table checker tool to ensure that all tables were completely copied as part of a classical migration (for more information, see SAP Note 2009651). Now, you also have the option to use the table comparision for the classical migration as well, for which you may use the SUM in a specific mode (called migtool, explained below). This is called table comparison standalone – standalone as it is not part of the DMO run.
Introducing the migtools of SUM
The Migration Tools (migtools) in this context are simply two SUM use cases that are bundled separately, and which are neither part of a standard SUM maintenance nor of a standard DMO migration.
Migtools of SUM are:
- benchmarking tool, see separate blog DMO: introducing the benchmarking tool
- table comparison standalone, see this blog 🙂
Both options will not be used as part of a DMO run itself; but the benchmarking should be used before starting the DMO run.
❗ Note: the migtools are not really tools, but use cases for SUM.
❗ Note: For classical migrations using the Software Provisioning Manager, there are also migration tools (such as Migration Monitor, splitter tools – and Table Checker, as mentioned above), which you must not confuse with the migtools of SUM with. For more information about the migration tools of the classical migration, see SAP Note 784118.
“Compare” <table comparison with DMO> versus <table comparison standalone>
Now let us compare the two compare options – still with me? 😉
|Aspect||table comparison of DMO||table comparison standalone|
Table comparison during migration run using DMO of SUM; the dialog “Database Migration Option” offers to enable and configure the table comparison
Table comparison during classical migration run using SWPM: SUM has to be started separately as migtool
Same for both:
Tables for which the content shall be compared: either you list specific tables, or a percentage of all tables
Yes: option is part of DMO
No: not part of DMO; manually execution required for use in classical migration
Yes: if difference appears, drill down is done to identify the row with different content
No: only tables are listed that show a difference
Part of DMO guide (section 7.2)
Part of System copy guide (section Table Comparison with Software Update Manager)
❗ Note: both use cases to not export the table content to disk. A checksum is created for each table, these checksums are persisted.
Note: there may be scenarios for which only the “old” table checker tool (described in SAP note 2009651) can be used, e.g. access to source database is no longer possible to generate CRC files with SUM table, but the export files with TOC are still available.
Check out the following blog on Handling table comparison checksum errors as well: