advertisement
Login | Register   
  Include Code  Search Tips
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Download the code for this article
A Faster Disaster?
Textbooks use proverbial sales data for examples. In my own work, I've used Automatic Summary Tables to summarize cotton bale production and to collate data before replicating it over slow networks. Where have you, or would you, use ASTs? What situations and queries are giving you performance problems? Tell us in the DB2 forum.
Partners & Affiliates
advertisement
advertisement
advertisement
advertisement
Average Rating: 4.5/5 | Rate this item | 2 users have rated this item.
Tame Beastly Data with Summary Tables (cont'd)
Update on Request
Examining our queries more carefully, we might:
  • Decide that query A is acceptable without the current day's data
  • Recognize that query B doesn't need the current day's data
  • Establish that query C runs fast enough on the raw data.
advertisement

Hence, we could skip the overhead of a refresh immediate summary, and rebuild the summary each day. A refresh deferred summary table is a neat way to do this. It allows more flexible queries, but has its own limitations.

Refresh deferred summary tables are similar to refresh immediate, except they:
  • Operate asynchronously; they are refreshed only when you explicitly refresh them
  • May use scalar functions
  • May use other column functions, such as MIN and MAX
  • Do not require a COUNT(*) or COUNT_BIG(*)
  • May contain a HAVING clause
  • Cannot be used to automatically optimize static SQL queries
  • Can be used to automatically optimize dynamic SQL queries under certain circumstances (see sidebar "A Faster Disaster").

Listing 5 shows a refresh deferred definition. Remember, you can increase flexibility and reduce overhead by deferring the update.


Listing 5: Create a Deferred Summary Table
CREATE SUMMARY TABLE TEST.GOOP_DEF AS (
SELECT Machine, DateMade,
SUM(Weight) AS SumWeight,
COUNT(Weight) AS CountWeight,
COUNT(*) AS Bags,
MIN(SerialNo) as MinSerial,
MAX(SerialNo) as MaxSerial
FROM TEST.GOOP
GROUP BY Machine, DateMade
) DATA INITIALLY DEFERRED REFRESH DEFERRED @
create index TEST.GOOPDEFMDIX ON TEST.GOOP_DEF
(Machine, DateMade) @

Note that the contents of goop_def are only updated upon the command


refresh table TEST.GOOP_DEF

meaning that the contents of goop_def are not guaranteed to be current.

Refresh deferred summary tables are good when:

  • You can refresh a summary table once and query it many times, due to the timing of the transactions and queries—for example, if you run queries on historical daily summaries or the source data arrives in bursts.
  • You need the extra functions that aren't available with refresh immediate.

So it's still a balancing act, and there's no single answer to all situations, but now you have two tools to cut your query times when collating large data sets. Decide whether your summary needs to be live, or simply refreshable, and let DB2 work smart—like Eddie.

Previous Page: Immediate Results  


Greg Nash is an integration engineer who likes finding solutions to complex problems.
Page 1: IntroductionPage 3: Immediate Results
Page 2: Grouping the DataPage 4: Update on Request
Please rate this item (5=best)
 1  2  3  4  5
advertisement