19.06.2013 Views

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

05 SERIAL-NUMBER PIC S9(9) COMP-4 OCCURS 10 TIMES.<br />

Tip: Verify that the PTFs <strong>for</strong> APARs PQ91898, PQ93620, PQ89181, and PQ87969 are<br />

applied:<br />

► PTF UQ92546 <strong>for</strong> per<strong>for</strong>mance APAR PQ91898 reduces excessive lock and getpage<br />

requests in multi-row insert.<br />

► PTF UQ96567 <strong>for</strong> per<strong>for</strong>mance APAR PQ93620 reduces CPU overhead during<br />

multi-row cursor delete.<br />

► PTFs UQ90464 and UQ92692, respectively <strong>for</strong> APAR PQ89181 and PQ87969, reduce<br />

CPU usage by providing improved lock management.<br />

PTF UK06848 <strong>for</strong> APAR PQ99482 provides QMF <strong>for</strong> TSO/CICS 8.1 with the optional<br />

support of multi-row fetch and insert.<br />

3.2 Materialized query table<br />

For many years, the optimization <strong>for</strong> decision-support queries has been a difficult task,<br />

because such queries typically operate over huge amounts of data (1 to 10 terabytes),<br />

per<strong>for</strong>ming multiple joins and complex aggregation.<br />

When working with the per<strong>for</strong>mance of a long running query executed via dynamic SQL,<br />

especially in Data Warehousing, involving joins of many tables, DBAs often created summary<br />

tables manually in order to:<br />

► Improve the response time<br />

► Avoid the redundant work of scanning (sometimes in the <strong>DB2</strong> work file), aggregation and<br />

joins of the detailed base tables (history)<br />

► Simplify SQL to be coded<br />

However, you need to be aware of the existence of the DBA’s summary tables and make a<br />

decision whether to use them or the base tables depending on the query. Another issue is<br />

setting up the synchronization of these summary tables with base tables.<br />

A materialized query table (MQT) is a table containing materialized data derived from one or<br />

more source tables specified by a fullselect to satisfy long running queries requiring good<br />

response time (minutes or even seconds).<br />

The characteristics of MQTs are:<br />

► Source tables <strong>for</strong> MQTs can be base tables, views, table expressions or user-defined table<br />

expressions.<br />

► MQTs can be chosen by the optimizer to satisfy dynamic query (through automatic query<br />

rewrite) when a base table or view is referenced. No query rewrite is done <strong>for</strong> static SQL,<br />

you need to address the MQT directly.<br />

► MQTs are used to precompute once expensive joins, sorts or aggregations. They can be<br />

reused many times to improve query per<strong>for</strong>mance.<br />

► MQTs can be accessed directly by static and dynamic SQL.<br />

Materialized query tables are also known as automatic summary tables in other plat<strong>for</strong>ms.<br />

Chapter 3. SQL per<strong>for</strong>mance 39

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

Saved successfully!

Ooh no, something went wrong!