IT分销/经销数据库

select syscat.tables 很慢的一个摄取量

dblook 导出表结构很慢,很慢查看了 执行了的sql,这个sql执行了  几百次,感觉上 导出一张表,就执行下面的sql一次怀疑是下面这个sql执行的:DECLARE THIS_TABLE_ALIAS CURSOR FOR            with iv (tabname, tabschema, b...显示全部
dblook 导出表结构很慢,很慢
查看了 执行了的sql,这个sql执行了  几百次,感觉上 导出一张表,就执行下面的sql一次
怀疑是下面这个sql执行的:
DECLARE THIS_TABLE_ALIAS CURSOR FOR            
with iv (tabname, tabschema, base_tabname, base_tabschema, remarks,create_time, definer) as
     ((SELECT  tabname, tabschema, base_tabname, base_tabschema, remarks,create_time, definer
                   FROM    SYSCAT.TABLES              
                   WHERE   type = 'A' and   base_tabname = :H00005   
                   and                      base_tabschema = :H00007 )      
     union all              
     (select st.tabname, st.tabschema, st.base_tabname, st.base_tabschema, st.remarks,st.create_time, st.definer
                   from iv,  SYSCAT.TABLES st              
                   where iv.tabname = st.base_tabname and  iv.tabschema = st.base_tabschema and  st.type = 'A'))        
select tabname,
tabschema,
base_tabname,
base_tabschema,
remarks,
create_time,
definer
from iv
ORDER BY tabschema, tabname FOR READ ONLY



我执行了一下这个sql的部分
Statement:
  DECLARE C1 CURSOR
  FOR
     SELECT tabname, tabschema, base_tabname, base_tabschema, remarks,
             create_time, definer
     FROM SYSCAT.TABLES
     WHERE type ='A' and base_tabname ='a' and base_tabschema ='a'

Section Code Page = 1208
Estimated Cost = 56141.507812              --这么高的cost
Estimated Cardinality = 0.000000
(    2) Access Table Name = SYSIBM.SYSTABLES  ID = 0,5
        |  Index Scan:  Name = SYSIBM.INDTABLES09  ID = 9
        |  |  Regular Index (Not Clustered)
        |  |  Index Columns:
        |  |  |  1: AUDITPOLICYID (Ascending)
        |  #Columns = 7
        |  Evaluate Block/Data Predicates Before Locking Committed Row
        |  Evaluate Predicates Before Locking for Committed Key
        |  #Key Columns = 0
        |  |  Start Key: Beginning of Index
        |  |  Stop Key: End of Index
        |  Data Prefetch: Eligible 3506
        |  Index Prefetch: Eligible 3506
        |  Lock Intents
        |  |  Table: Intent Share
        |  |  Row  : Next Key Share
        |  Sargable Predicate(s)
        |  |  #Predicates = 3
(    1) |  |  Return Data to Application
        |  |  |  #Columns = 7
(    1) Return Data Completion
End of section

Optimizer Plan:
            Rows   
          Operator
            (ID)   
            Cost   
                    
        3.27867e-10
            n/a     
          RETURN   
           ( 1)     
          56141.5   
            |      
        3.27867e-10
            n/a     
           FETCH   
           ( 2)     
          56141.5   
       /           
    55226       55226   
     n/a         n/a   
   IXSCAN     Table:   
    ( 3)      SYSIBM   
   395.307    SYSTABLES
     |      
      1      
Index:      
SYSIBM      
INDTABLES09


导出很慢很慢,想这个sql 这么优化呢?

附件:

附件图标db2trc.part01.rar (8.58 MB)

附件图标db2trc.part02.rar (8.58 MB)

附件图标db2trc.part02.rar (8.58 MB)

附件图标db2trc.part03.rar (5.65 MB)

附件图标db2support.zip (1.4 MB)

附件图标db2batch.sql (88.24 KB)

附件图标db2support.zip (1.36 MB)

收起
参与87

查看其它 85 个回答wangzhonnew的回答

wangzhonnewwangzhonnew软件工程师IBM Canada Ltd.
没有明确business case,只是理论上存在的性能问题是不会被作为APAR处理的。
除非有明确的business case证明这部分的设计对业务造成重要影响,并且没有workaround(就算加大bufferpool也不能满足性能需求)才值得考虑是否应当建立新的索引(或者重新设计这部分的查询)。至少到现在我没有见到有用户说要经常运行db2look,然后这部分的性能达不到需求的。一般来说db2look就跑一次,快点慢点不是很重要,不值得为这个部分单独创建一个索引
IT分销/经销 · 2011-07-06
浏览1777

回答者

wangzhonnew
软件工程师IBM Canada Ltd.
擅长领域: 数据库

wangzhonnew 最近回答过的问题

回答状态

  • 发布时间:2011-07-06
  • 关注会员:1 人
  • 回答浏览:1777
  • X社区推广