为什么DB2不使用我的MQT表?

时间:2009-12-05 23:30:05

标签: sql db2 database

我在DB2 9.7(尚未修复包1)中创建了一个用户维护的MQT(物化查询表)。这是主要事实表的简单分组。但我的查询并没有被重写以达到目的。

这是我尝试过的:

  • 使用ENABLE QUERY OPTIMIZATION创建MQT并按用户特征维护
  • 还包括REFRESH DEFERRED&数据初步推迟。 (也许我不应该?)
  • 设置注册表变量,告知DB2使用所有类型的MQT进行优化
  • “为表格X设置完整性,立即全部未检查”
  • Ran runstats
  • 刷新缓存:FLUSH PACKAGE CACHE DYNAMIC
  • 确保默认查询优化类至少在2级(它是5)
  • 将默认刷新年龄设置为0(我认为这与用户定义的MQT无关)

然后尝试确定优化器是否会使用MQT:

  • 尝试了各种我希望使用MQT的简单查询 - 或者:
    • SELECT COUNT(*)FROM fact_table
    • 或SELECT group-dimension,COUNT(*)FROM fact_table GROUP BY group-dimension。
  • 说明(使用db2expln)仅引用了事实表而不是MQT
  • 查询结果显示计数与事实表一致,而不是MQT表
  • 查询持续时间与事实表一致,而不是MQT表。

有关更简单的方法来判断查询是使用MQT还是接下来应该尝试使用它的任何建议?

2 个答案:

答案 0 :(得分:3)

2件事:

1)CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION寄存器设置为什么?它默认为DFT_MTTB_TYPES数据库配置参数的任何值 - 默认值为'SYSTEM' - 因此优化器会忽略您的MQT。

2)此外,您对DFT_REFRESH_AGE和用户MQT维护的假设是错误的。 DFT_REFRESH_AGE仍然适用 - 对于用户维护的MQT,CURRENT REFRESH AGE寄存器必须设置为ANY才能考虑刷新延迟MQT。

答案 1 :(得分:0)

要调试问题,请在查询前添加:

EXPLAIN PLAN FOR

然后运行它,然后检索诊断消息:

SELECT EXPLAIN_TIME, DIAGNOSTIC_ID, MSG
    FROM TABLE(EXPLAIN_GET_MSGS(
      CAST(NULL AS VARCHAR(128)),
      CAST(NULL AS TIMESTAMP),
      CAST(NULL AS VARCHAR(128)),
      CAST(NULL AS VARCHAR(128)),
      CAST(NULL AS VARCHAR(64)),
      CAST(NULL AS CHAR(1)),
      CAST(NULL AS INTEGER),
      CAST(NULL AS INTEGER),
      'en_US'))
    AS REGISTRYINFO
    WHERE EXPLAIN_TIME >= (CURRENT TIMESTAMP - 1 HOUR)
    ORDER BY EXPLAIN_TIME desc
;

就我而言:

EXPLAIN_TIME              DIAGNOSTIC_ID MSG                                                                                                                                                                                                                
------------------------- ------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2015-07-08 10:48:50.940231 1             EXP0053W  The materialized query table "DB2INST1"."XFACETATTR" was not considered for query matching because the isolation level of the query is higher than the isolation level of the materialized query table.