07.02.2013 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

If your query has long run times that are unacceptable to the user, and if the<br />

query summarizes many rows, then <strong>using</strong> aggregates is often the most effective<br />

way to speed up the query. To determine whether your query would benefit from<br />

aggregates, you can look at the detailed breakdown of the response time on<br />

ST03.<br />

QDBSEL/QDBTRANS<br />

If the QDBTIME component of the response time is very high, examine the fields<br />

QDBSEL/QDBTRANS to determine whether the query is reading too many<br />

records from the cube in relation to the amount of rows that are transferred back<br />

to the OLAP engine.<br />

The field QDBSEL is the number of rows that satisfied the predicates. The field<br />

QDBTRANS tells you how many records were transferred from the database to<br />

the application server after the GROUP BY statement in the SQL.<br />

As a rule of thumb (RoT), if the ratio between QDBSEL/QDBTRANS is > 10, then<br />

you may be able to get larger improvements in per<strong>for</strong>mance though the use of<br />

aggregates than through other database or SQL tuning. However, this does not<br />

mean that you should ignore other methods <strong>for</strong> further improving per<strong>for</strong>mance by<br />

analyzing the SQL used by the query.<br />

QDBSEL/QDBTRANS is the number of rows selected <strong>for</strong> each row returned to<br />

the query user. When this is high, it means that <strong>DB2</strong> must summarize many<br />

selected rows into each result row, so an <strong>SAP</strong> aggregate table would probably<br />

help per<strong>for</strong>mance, since the aggregate table would contain pre-summarized<br />

data. After the E- fact table is summarized into an aggregate table, the query will<br />

retrieve fewer rows to create the result.<br />

The <strong>SAP</strong> rule of thumb is that when this ratio is greater than 10, an aggregate<br />

may be appropriate. Use the frequency of query execution, the importance of<br />

per<strong>for</strong>mance <strong>for</strong> the query, and the time available <strong>for</strong> aggregate roll-ups in<br />

conjunction with this rule of thumb when evaluating the need <strong>for</strong> new aggregate<br />

tables.<br />

For instance, if an aggregate is not frequently used, and if the query is very slow<br />

but time and CPU are available in the aggregate roll-up window, then creating an<br />

aggregate is a way to move part of the report generation time to the nighttime.<br />

If the ratio QDBSEL/QDBTRANS is low (which indicates that aggregates may not<br />

help) and the QDBTIME is still very high, then you should look at the relationship<br />

of the fields QDBSEL/QTIMEDB. This is a measure of how fast (rows per<br />

second) the rows are retrieved from the database. As a rule of thumb, if the<br />

figure is 300–400 or lower, then you should further analyze the database to<br />

evaluate the way the SQL is executing. Continue down the database leg of our<br />

162 <strong>Best</strong> <strong>Practices</strong> <strong>for</strong> <strong>SAP</strong> <strong>BI</strong> <strong>using</strong> <strong>DB2</strong> 9 <strong>for</strong> z/<strong>OS</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!