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

Objectives
The goal for the multi-user query scenarios is to measure the following KPIs for
5 TB on 27 blades, 15 TB on 81 blades, and 25 TB on 135 blades,
► Query throughput rate in terms of business reports per hour and InfoCube
queries per hour
► Average number of records touched per query in the BI Accelerator
► Average report response time
► CPU consumption on blades and BI server
Description
When a query is issued by a user, SAP BI on System p checks whether the data
to be queried has been BI Accelerator indexed. If it has, query processing is
directed to SAP BI Accelerator. Then if the data is not in BI Accelerator blade
memory, it must be read from GPFS into blade memory. In preparation for query
processing, all cube data can be pre-loaded from GPFS into blade memory
during index creation or off-shift hours. This speeds up the query processing by
eliminating I/O during production.
For our query measurements, all BI Accelerator indexes were pre-loaded into
memory.
Of all the records in the InfoCubes, only selected rows (QDBSEL) are relevant to
the query. As with RDBMS, filtering of all records in the InfoCube is done to
identify the ones relevant to the query for further processing. Typically, indexes
are used to do this. In this case, BI Accelerator column-based processing and
compression have a clear advantage over an RDBMS in identifying and
processing the relevant records. The selected records are summarized or
aggregated concurrently by a number of blades, then the records are transferred
to an OLAP engine in an SAP BI appserver residing on System p. The number of
records transferred is referred to as QDBTRANS. At the SAP BI appServer,
server rendering is performed before sending the query report to users.
Note that the queries that we designed for this study had high selectivity, with an
average QDBSEL of 26–46 million records per query, for our 25 TB tests. Still,
the BI Accelerator does tremendously well with an average response time of less
than 20 seconds.
Measurement results
One benefit to using BI Accelerator is that no explicit tuning for the cubes is
required to prepare for query processing. So there are no aggregates to be
defined and no additional secondary indexes are needed.
Chapter 11. Project Jupiter: large BI Accelerator scalability evaluation 247