Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025

 


Article

How to estimate the number of binary dump threads?

« Go Back

Information

 
Article Number000061242
EnvironmentProduct: OpenEdge
Version: 10.1x, 10.2x, 11.x
OS: All supported platforms
Other: Binary Dump, PROUTIL
Question/Problem Description
How to estimate the number of binary dump threads used?
When binary dump runs in threaded mode, the last dump thread takes longer to complete after the other threads have finished dumping data.
Can a threaded binary dump be better distributed amoung the threads used
Why do some binary dump threads dump more data than others
Steps to Reproduce
Clarifying Information


 
Error Message
Defect/Enhancement Number
Cause
Resolution
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 parameter.  
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.
Workaround
Notes
Attachment 
Last Modified Date6/8/2017 10:27 AM