Kbase P152756: How to select the index that will result in the largest number of threads for a dump?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/3/2009 |
|
Status: Verified
GOAL:
How to select the index that will result in the largest number of threads for a dump?
GOAL:
How to determine the number of threads that will be used for a dump?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.1x
OpenEdge 10.x
FIX:
It is not really practical to try to figure out how many threads will be used. There are too many variables and some of them can not been seen so predictions will be unreliable.
The primary index is just like all the other indexes and does not perform any better or worse because it is the primary index. The three biggest contributors to retrieval performance through an index are:
1. How well it compresses (fewer index blocks to be read)
2. How closely the order of the index entries matches the physical storage order of the records (fewer disk seeks, more sequential reads)
3. How close the records are to each other.
In a type II area they will pack better than in a type I area and each block in a type II area will only contain records from the one table. (fewer disk seeks, more sequential reads)
Threaded dumps do not help much at all.
Sometimes what is much more important than dump speed is the /order/ in which the records are dumped.
Ideally in the load process you want to load the records to be stored in a physical order that matches the index that is used the most by the application.
So use a dump index that results in that.