DMO: table comparison and migration tools
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 to 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 |
|---|---|---|
| Use case |
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 |
| Focus |
Same for both: Tables for which the content shall be compared: either you list specific tables, or a percentage of all tables |
|
| Integration |
Yes: option is part of DMO |
No: not part of DMO; manually execution required for use in classical migration |
| Drill down possible |
Yes: if difference appears, drill down is done to identify the row with different content |
No: only tables are listed that show a difference |
| Documentation |
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:
https://blogs.sap.com/2016/12/30/dmo-handling-table-comparison-checksum-errors/
Thank your Boris. It helps . In case the customer would like to enable table content comparision - assuming they want to be sure that DMO is doing everything correct - but at the same time they want to keep the downtime short.
1) Running the SWPM table comparision - so you confirm there is no TOC file that will get created -( not even dynamically and TOC getting deleted at the end of checksum comparision?)
2) would running this table comparision using SWPM standalone give a measure / approximate of the table comparision with SUM during DMO - provided we give the same set of tables for both?
Hi Chandrakanth,
I have updated this blog now to sharpen the distinction between the table comparison standalone (as part of SUM) versus the "old" table checker. The "old" table checker works with TOC files, and the table comparison standalone does not work with TOC files, but it generates CRC files containing the checksum results.
So my recommendation is to avoid the phrase "SWPM table comparison".
Running the table comparison standalone is based on SUM, like the DMO table comparison is. But of course these two scenarios compare the table results for different migration techniques. So I do not see that the one gives a helpful approximate for the other.
Kind regards, Boris
Hello Boris,
Is it possible to skip the Row count in downtime.? and can run manually in parallel.
It's common source DB row count take very long time for big tables because of which the downtime increases.
Thanks,
Bhushan
Hello Bhushan,
it is not possible to skip the row count.
Kind regards, Boris
Hello Boris,
The Count* run took 13 Hrs for me out of which only for 8 tables it has taken 8.30 Hr. I believe if I skip the 8 tables with igncount and run them manually after the table data migration it will help in downtime management.
Thanks,
Bhushan
Hello Bhushan,
the igncount will ignore the count results, but not skip the count.
Kind regards, Boris
Is there an XML file or report I can provide, for example, to auditors, with the output of count* ?
Will post the answer here if I find it.
Found this article so getting closer to an answer, just need to find the master log here that we can provide, but this is talking about the "table checker" and not count*:
https://wiki.scn.sap.com/wiki/display/SL/Table-Content+Checks+in+SUM
Hello Derek. SAP KBA 2348804: DMO Count* replaces Table Checker and how to use it for Audit purposes will be released in the comming days which addresses this specific topic.
Excellent, thanks so much Neil for your efforts on this one ! Looking forward to the KBA.
Hi Boris,
Thank you for nice blog and explanation. We recently did DMO run on ECC EHP6 on SQL database with target as ECC EHP8 on hana. The source database size is approx . 11 TB with 8.2 TB application table data. We are using latest SUM tool and kernel executables. We choose no table comparison option.
We are concerned about row count time, which was 29.5 hours. 99% row count finished in 20 minutes and next 1% ( 2 buckets with set of 500 tables each) took 29 hours.
As row count is still part of downtime, we need to understand why it took such a long time?
What can be done to avoid this long run time? Please note that there were no errors during row count or bucket failures.
We completed application table data migration in 34 hours with approx 200 GB/hour speed.
As per our previous experience, DMO row count for similar size "oracle" DB finished in less than an hour.
Thanks,
Ambarish