Kbase P114946: How big to create empty database when doing a dump & reload
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/07/2007 |
|
Status: Unverified
GOAL:
How big to create empty database when doing a dump & reload
GOAL:
Why does the database structure needs to be bigger than the data loaded
FIX:
The reasons for needing to dump and load vary. Nevertheless, the ultimate objective should always be to obtain the best data compaction and eliminate space wastage. It often happens that the anticipated space created in the database structure was based purely on the physical record sizes of the data (as reported in dbanalys) or the size of the dumped tables, as opposed to the the real occupation on disk (which includes the "wasted space").
The culprit involved, is the records per block allocation (rpb) per storage area. Progress Solution P7561, "How to calculate the best number of records per block for storage areas." discusses this further. In other words, when planning the structure file - although we need the dbanalys to calculate the optimal rpb and group tables to Storage Areas by this definition - don't use the space used in the tabanalys section of the dbanalys.
A better /*estimation*/ for the .st file calculation would be:
To account for the data occupation:
Storage Area size = (number of records in area/rpb)*blocksize
Where rpb is calculated by: (Blocksize - 100B)/(mean_rec_size +2)
To account for the index occupation:
Since records per block do not factor into index occupation, the size can be the space used in the idxanalys section of the dbanalys
Please bear in mind that these are estimates. It is not possible to get exact dimensions because:
a.) rpb will hardly ever be an exact power of 2, so we have to make adjustments
b.) We traditionally use the mean record size, this doesn't account for population variance. A better figure would perhaps be the 10 percentile