DB2 LOAD: Poor performance while loading table with large BLOBs I need help regarding LOAD-command with BLOBs.

I notice very poor performance while loading a table which contains large BLOBs.
While tracing the OS, I only have about 15MB/sec I/O-speed.
But in other cases I have normal I/O-rates > 200MB/sec. (e.g. creating DB-backups, creating tablespaces, copy files etc.).

I already tried to use different extent-sizes, page-sizes and some LOAD-parameters like "DISK_PARALLELISM", "SORT BUFFER", "DATA BUFFER", "SAVECOUNT" etc. to improve LOAD-performance but I was not able to speed up the LOAD. 
The target table is empty and has no indices defined.
Source and target are located on separate RAID-volumes with dedicated physical drives.

Any hints to improve LOAD performance or to further investigate the problem are very welcome.

Thank you in advance.

Ronny

My setup:
- SLES 11 SP2
- DB2 9.7 FP8
- Raid: 
    Source: 2 dedicated Disks, Raid-0 (Striping) with 64 KB stripe-size
    Target: 2 dedicated Disks, Raid-0 (Striping) with 64 KB stripe-size
- File-System: EXT3
- Tablespace-Definition:
    CREATE LARGE TABLESPACE LOB IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY DATABASE USING (FILE 'xxx' 20000000) PREFETCHSIZE AUTOMATIC BUFFERPOOL IBMDEFAULTBP DROPPED TABLE RECOVERY OFF;

- LOAD-Definition:
    LOAD FROM xxx OF IXF LOBS FROM xxx MODIFIED BY lobsinfile METHOD N (ID, CONTENT, SEGMENTGROUPID, SEGMENTNUMBER) SAVECOUNT 1 ROWCOUNT 250 MESSAGES /xxx/CONTENT.log REPLACE INTO CONTENT (ID, CONTENT, SEGMENTGROUPID, SEGMENTNUMBER) NONRECOVERABLE;
As Chris already mentioned LOAD is a utility and therefore the UTIL_HEAP_SZ must be set high enough (but don't ask too much, always monitor the memory free space with top). You need a lot of memory for a fast load (see DATA BUFFER below).

Here are things that speed up the load:


More containers for the tablespace where the table is (best on separate luns / disks)
DATA BUFFER parameter (default 25% of UTIL_HEAP_SZ), make it bigger 400-800 (4K) per CPU core available.
ANYORDER (allows LOAD to abandon the input order, bad if you load in clustering order) can give 30% boost
FASTPARSE (use only if data is clean e.g. unloaded from other table) can give 15% boost
SAVECOUNT - the higher the better I use #input records/10, so for 100M records the savecount is 10000000 - in your case 1 the LOAD has to update the restart data with every record = SLOW!


Note: always collect statistics with STATISTICS YES during load. It is faster than LOAD + RUNSTATS

Good luck and let us know your improvements!