Best Practices for SAP BI using DB2 9 for z/OS - IBM Redbooks

(max_size=250,000,000, and max_split_parts=40).
When the data arrives at the blade, the RFC compressed data is uncompressed.
Then gzip compression is done before writing temporary objects to GPFS, in the
form of *.tmpx files. Each blade has its own unique storage location/
subdirectories for the same cube. The next phase is to read these temporary
objects that were just written to GPFS. Initial indexing and optimizing take place.
This uncompresses the data, reorganizes it, and compresses again with a
different algorithm. Lastly, the data is written as a whole to the GPFS as final
persistent objects in the form of *.bin files.
In Appendix D, “Project Jupiter: evaluation details” on page 325, Examples D-6
through D-8 display a list of BI Accelerator indexed cubes, a cube example with
40 part horizontal partitioning, a list of all columns of an indexed cube, and their
corresponding temporary and persistent objects. They illustrate SAP BI
Accelerator horizontal partitioning, vertical decomposition, and compression.
The BI Accelerator index creation process is very I/O intensive to the GPFS
storage shared by the blades. During the test, we started with the default value of
256 K for the GPFS I/O block size. We added a second DS8300 storage system
to handle the high GPFS I/O activity. Our further investigation found that the high
GPFS I/O activity was actually due to the large block size of 256 K, so we
experimented and determined that blocksize=64K and maxblocksize=64K
yielded better GPFS performance.
The two DS8300 storage systems were configured using RAID-10 because of
the write intensity of the BI Accelerator index creation. In general, RAID-10 is
recommended for write-intensive workloads. However, it requires more disk
space.
Chapter 11. Project Jupiter: large BI Accelerator scalability evaluation 243