Be careful when using the R3load table splitter from the Software Provisioning Manager screens.
You are asked to supply your table split file, in the install guide, in the format “<TABLE>%<# SPLITS>”.
However, this does not supply the table column to split by.
When splitting large tables, during the Table Splitting preparation phase (before you even start exports), R3ta can run for quite a while whilst is performs scans of the available INDEXES and then COUNTs the number of rows in the table(s) to be split.
It’s trying to define the most apt column(s) to use for generating the WHR files which contain the query predicates.
I tried adding a specific column during the initial table splitter screens, where you can specify the column to use. However, this seems to be completely ignored.
The best advice, is to prepare your table split during your proof phase in the sandbox environment, then potentially manually adjust the final WHR file to account for any additional rows in the table(s) to be split.
This will save a lot of time and effort in the true production conversion run.
Also, ensure that the indexes on those tables, especially the ones that the WHR predicates refer to, are rebuilt if possible.
