Threaded binary dumps (-thread 1, -threadnum n) are created based on the index tree
, not on the table size.
A table’s records are divided according to the number of entries in the root block of the index used being the primary index by default or that specified by the -index
The threaded-dump algorithm splits the root block logically into up to (-threadnum
) parts, which breaks the index tree in different ranges per the keys in the root block, each thread works on a range:
- If there is only one entry in the root block, it cannot be split so a non-threaded (regular) dump will be used.
- When the root block contains more entries, more threads in binary dump may be used as the table can be divided into more subsets.
- A different index may be used to perform the dump if the root of the index contains more balanced entries, but cannot be predicted.
- Unique indexes are likely more balanced but not necessarily, it depends on the data and physical layout of the index.
- idxcompact or idxbuild may be used when the index is not well utilized to minimize threads that dump less records.
When the binary dump starts, it does not know how many records each range contains until it finishes. A better chance to perform a faster dump is to have more threads if they can be used. The maximum number of threads is limited by the number of entries in the root block that are used to divide the ranges.
DBRPR Option 13 displays contents in the root block, ih_nment
is the number of entries. To use this option, the dbkey of the root index and the index area number are needed which can be found in its _storageObject record. Refer to Article 000022089, How to find the Number of an index its Storage Area and Root Block
When records are loaded back, the physical layout of the table favors the index that was used to dump the records.