Have you looked at vmo parameters that affect page stealing. I have mine set to: vmo -p -o minperm%=5 # Was 20 vmo -p -o maxclient%=10 # Was 80 vmo -p -o maxperm%=10 # Was 80 This alone is the first place I would start. >>> "Stuart Clowes" <stuart.clowes@xxxxxxxxx> 06/28/06 4:06 PM >>> We bit the bullet and implemented concurrent I/O (AIX 5.2 ML6, 126.96.36.199, JFS2, ESS storage). It seemed to make operations doing table scans slower (exports in particular took 50% longer). We have 8K block size, DB_FILE_MULTIBLOCK_READ_COUNT=8. I suspect that not having the benefit of JFS2 readahead may be hurting us here. There was no noticable difference on operations performing random IO. We did this because of a perceived problem with I/O (intermittent periods of high wait I/O with apparently low actual physical I/O; variations in response time of standard queries, even at apparently 'quiet' times). An IBM guru told us that the wait I/O may be due to the stresses of managing page replacement in the JFS2 cache, rather than problems at the disk layer. Howerver, moving to CIO made no obvious difference to our wait I/O or disk throughput.. I'd be interested in the experiences of others who have moved from JFS2 cached I/O to concurrent I/O. Did you have a positve, negative, or mixed experience?