DB2_PARALLEL_IO

Question

Hello
In our environment we have one RAID10 volume builded on 16 disks (IBM EXP810 enclosoure) and 3 logical drives on this volume for our databases.
The defaul SAP installation is created all tablespaces with 4 containers per tablespace.
Also, for all tablespaces PAGESIZE=16384, EXTENTSIZE = 2,  PREFETCHSIZE=8 and the segment size on RAID10 volume is 128K.
Do i need to enable DB2 profile variable DB2_PARALLEL_IO=* or in my case this is not optimal for disks read/write perfomance ??
DB2 9.1.2 on AIX5.3 TL4
Thanks
With best regards, Dmitry

Answer 1

Thanks for the information, Dmitry.  In this case, you are correct - having a RAID stripe size equal to 4 extents on a single disk is not optimal.
DB2 will stripe extents across the 4 sapdata containers, and each raid segment is 4 extents large.  Also, since you have 4 database containers all sharing all 16 RAID disks, each container will start writing to the same disk, as follows:
extent 1 -> sapdata1 on disk 1 of the raid LUN
extent 2 -> sapdata2 on disk 1 of the raid LUN
extent 3 -> sapdata3 on disk 1 of the raid LUN
extent 4 -> sapdata4 on disk 1 of the raid LUN
extent 5 -> sapdata1 on disk 1 of the raid LUN
extent 6 -> sapdata2 on disk 1 of the raid LUN
... all the way to:
extent 15 -> sapdata3 on disk 1 of the raid LUN
extent 16 -> sapdata4 on disk 1 of the raid LUN
... then we finally switch to a second disk:
extent 17 -> sapdata 1 on disk 2 of the raid LUN
Therefore, in order to drive all 16 disks with prefetch requests, you would need a prefetch size of 16 * 16 = 256 extents.  However, I might not recommend this.  A prefetch size this large may flood your bufferpool with a bunch of data pages that are not needed by your queries, which may lower buffer hit ratios.
This distribution of extents is really poor for sequential access to data.  In your case, since prefetch size is 8 extents, reading extents 1-8 involves reading all 8 extents from the same disk, and these extents are written to 4 very different spots on this disk, so the disk head must also move around a lot to read them.
This may, however, be ok for your ERP system.  ERP mainly involves random access to single rows, and uses list prefetching to access non-contiguous pages of data, so each random access may read a page from a different segment of 16 extents, which would allow multiple simultaneous requests to access different disks in parallel.
However, for the sequental nature of SAP BI, the above storage structure would definitely limit the performance of your system, because each sequential prefetch request would involve limited parallelization across at most 2 of your available 16 disks.
DB2_PARALLEL_IO will likely not benefit your BI install, because you are already sending 4 prefetch requests for data that resides on at most 2 physical disks.  It may, however, help your ERP system, because setting it will increase the number of prefetchers and page cleaners in your system (if NUM_IOCLEANERS and NUM_IOSERVERS = AUTOMATIC in your CFG).  Therefore, setting DB2_PARALLEL_IO=,4 ( = all tablespaces, 4 = multiple of IO requests) may improve the list prefetching and the page cleaning for your ERP system.
Another thing worth mentioning, is that we generally recommend that your ERP and BI systems operate on separate sets of physical disks, to avoid disk contention between these two systems.  This would likely improve the performance of both systems if you can do this.
Also, would you be able to adjust the raid segment size to be either equal to, or half of, the 32K extent size?  If your segment size is 1/2 of an extent (1 page of data), then this provides the best parallelization for list prefetching in ERP.  Also, using all 16 disks for BI, this would allow sequential prefetching of 8 consecutive extents across all 16 disks.  If you are able to split ERP and BI on 8 disks each, then having a segment size equal to the extent size would allow a prefetch of 8 to read an extent from each of these 8 disks in parallel.  In this scenario, since you have 4 prefetchers, setting DB2_PARALLEL_IO=*,2 would send 4 * 2 = 8 IO requests for those 8 extents, maximizing your sequential prefetching IO for your BI system.
I'm not sure how much flexibility you have at this point in the system's life cycle, so here are a few general recommendations:
1.  extent size equal to, or a multiple of, your RAID segment size
2.  SAP BI and ERP should not share physical disks
3.  separate disks for each DB2 container in ERP.
4.  DB2 logs on different physical disks than the containers for ERP
If you have only one file system spanning a small number of disks for the DB2 containers, you may want to try creating only one container and then using DB2_PARALLEL_IO to increase the number of page cleaners and prefetchers operating in your system.  For the sequential queries in SAP BI, this will avoid having consecutive extents striped into different locations on the same physical disk (and thus, reduce disk head movement to access consecutive extents).
I must appologize for the excessive amount of information in this post.  However, I hope this gives you enough information to evaluate the options available to you and make the correct decisions.
Best regards,
Jeremy.