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 个回答nowhill的回答

nowhillnowhill系统工程师
把我之前发过的两个合在一起,基本就是问题的症结所在了;
内存不够: 排序换页,逻辑读不够,等..  所以IO ...
Shane.Qian 发表于 2011-7-1 14:39



你说的这些问题都存在,但是看问题也可以独立的看
你想,我别的什么都不跑,就跑一个db2look 导出数据,慢成这样?
是内存不够,io不够,排序换页

我觉得都不是

问题就是 查询sysibm.tables 采取了 全表扫描,如果是索引扫描,那么 会很快很快
但数据库 有问题时,不能 把 责任 推给系统,推给内存,io之类

首先要问问,你数据库本身 是不是 已经优化了

SELECT  tabname, tabschema, base_tabname, base_tabschema, remarks,create_time, definer
                   FROM    SYSCAT.TABLES              
                   WHERE   type = 'A'
这样的sql,这样错误的执行计划才是 关键 所在
IT分销/经销 · 2011-07-01
浏览518

回答者

nowhill
系统工程师

nowhill 最近回答过的问题

回答状态

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