Performance Notes

Index rows are ordered for fast access to a table’s data row. Index rows that contain row identifiers are treated as binary to achieve fast access to the user table.

Within the same architecture platform, the order of index rows remains valid, and search order for a selection criteria takes its normal path. However, when index rows are translated across different architectures, the order in which optimization was performed is invalidated, resulting in an invalid index on user tables in a cross-platform dump and load.

A database dump from a different architecture, such as big-endian to little-endian, is loaded, certain indexes are marked as suspect:

Nonclustered index on APL table
Clustered index on DOL table
Nonclustered index on DOL table

To fix indexes on the target system, after loading from a different architecture dump, you can either:

Drop and re-create all of the indexes, or
Use sp_post_xpload.

In general, it requires planning to re-create indexes on large tables, and it can be a lengthy process.

sp_post_xpload validates indexes, drops invalid indexes, and re-creates dropped indexes in a single command on databases. Because sp_post_xpload performs many operations, it can take longer dropping and re-creating indexes. Use sp_post_xpload for databases smaller than 10G. For databases larger than 10G, SAP recommends that you drop and re-create indexes.