Kbase 21005: Performance of Binary Dump/Load versus Bulkload
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  9/26/2006 |
|
Status: Verified
GOAL:
Performance assessment of Binary Dump/Load versus Bulkload.
GOAL:
Performance assessment of Binary Dump versus Bulkload
GOAL:
Performance assessment of Binary Load versus Bulkload
FIX:
Binary dump will always be faster than Data Dictionary dump.
Binary load can be tuned to be faster than a bulkload.
You can try 4 threads per CPU to keep system utilization high.
Before starting, run a dbanalys, sorting tables by size descending, start one parallel proutil -C dump for the number of selected threads -1, then dump the rest of the tables one at a time.
proutil dbname -C dump largetable1 &
proutil dbname -C dump largetable2 &
.. repeat that for threads -1
then proutil dbname -C dump smalltable1
proutil dbname -C dump smalltable2, etc.
Bulkload doesn't write to the bi file, so it can be faster than a binary load, but you can tune the binary load to run just as fast.
Use a 16K blocksize for the BI file, 128K cluster size, set -G to zero to prevent the bi file from growing & run with the -i parameter. If the system allows it, run a ramdisk. Even without a ramdisk, the -G 0 keeps the bi small.
The 128K cluster size may seem too small, but the expense of switching clusters does not apply when using the -i parameter. Even if we need to grow more clusters in the BI file, the overhead is small because the BI file is opened non-raw.
WHEN RUNNING WITH THE -i PARAMETER, IF THE LOAD FAILS, YOU MUST GO TO BACKUP!
Prior to version 9.1B, it is necessary to do an Idxbuild after performing a binary load. In Version 9.1B, the "build index" option was added to the binary load command.