DB2数据库性能理解的主要误区

  • 来源: 赛迪网 作者: 若水   2008-04-19/10:43
  • DB2数据库性能理解的主要误区: r"t-+CsmQ  
    逻辑设计应该总是能和物理设计完全映射 ]<>*NiQ  
    NkG F ;a  
    实际:DB2数据库设计中物理设计应该尽可能的和逻辑结构相近,但是为性能做出的物理设计改变不能被忽略,因为它们并不来自于逻辑设计。 : 62[YJ  
    -Ks.+Zlb  
    将所有东西放在一个缓冲池(BP0)中让DB2管理 Wvx!*MN@0)  
    hNUL/ 2  
    实际:就像在DB2手册和其他地方说明的一样,你只能在你的内存非常受限的情况下(10000 4k pages或者更少),你没有时间去管理它,你也没有考虑到性能的条件下,去这样做。最好这样说:不要放置除了DB2 catalog和目录以外的东西进入BP0。 ~]+yaq2y  
    %pZ0}Ka  
    DSNDB07是100%顺序的 ulA+J<|  
    F.R Ef  
    实际:DSNDB07从来就不是100%顺序的,因为有工作文件中的对页面进行的随机活动。随即活动可能高达45%,但是通常范围是3%到10%。 .<9AN L  
    e@|x:  
    VARCHAR应该总是被放置在行末 Fd4LD=u   
    `{oLO9|R  
    实际:这就是总是引发问题的话。如果表总是被读,并且非常少的更新,那么可以,这将会减少CPU负载,但是在其它情况下这样做就是最坏的,甚至如果表是被压缩的。只有在频繁更新的情况下它应该被放置在末尾,但是并不通常这样。 ;i}~JK=8  
    ~,RTH0rZ  
    程序应该以遵循逻辑过程的方式编码 D9+Izs7#  
    YtW7~?Xq  
    实际:伪代码或者一个逻辑过程图并不需要考虑性能相关的编码方式。在OLTP交易代码中这非常具有戏剧性。 Ia}_4oRRU;  
    SFE`N  
    大多数过程不在SQL中进行 ydJ s6s  
    + KsdYzRZ  
    实际:事实上,问题的反面往往是正确的。SQL是一个非常丰富的语言,能够处理大多数过程。实际上最大的困难是SQL经常被用来作为I/O处理器而不是一个集合处理器。 Zp+2Q$o  
    8NC@ue  
    代码和引用表应该和DB2声明的referential integrity(RI)一起使用 o6]nIGW$  
    3 7<&g  
    实际:RI不应该作为一个编辑有效性的快捷方式而使用,这通常属于别的什么,但是应该在真父子关系中使用。 w2IVC`1  
    D];.*dwV  
    表至多有一到两个索引  -.8$lk  
    dHT3s,$}  
    实际:表应该按照性能需求拥有多个索引。 i%;U9m"  
    FD;d zG=p  
    非分割索引(NPI)不应该被使用,尤其是不应该在大的表中使用 5!uS%`SjV  
    {VQRa{RzC  
    实际:这关系到数不清的问题,总体上这些都能被克服,但是NPI是对适当的访问和性能非常必要的。 #;HK!3|g}  
    #^N v}<<O,  
    大表应该被分割 1LU2o22.nc  
    qO+>F#D1  
    实际:因为一个表中有太多数据就意味着有性能下降,这是一个遗留的担心。当一些表中有超过60亿行数据时,这个理解已经被消除了。 -l!b<*.+D0  
    T1|s/{M@5  
    DB2缺省就是好的 I@!b-xB2  
    ^EY UqrB?  
    实际:缺省的一般不是最好的,他们因版本不同而改变。比如考虑绑定参数CURRENTDATA。 b'N{!|\am  
    UHZ8ovd~h  
    不要在SQL WHERE谓词里使用否定 "3~G3XF+  
    C?P9~! =7  
    实际:另外一个这种规则并没有被解释清楚。只有谓词是一个否定时,SQL访问路径可能使用一个不必要的表空间扫描。但是在其它的多数情况下,多余的过滤应该在DB2引擎里完成,这会较好。 t.,V:mR  
    f 5'0!=  
    我可以只依靠EXPLAIN来决定是否访问路径是好的#p#分页标题#e# ~xGL*c4^  
    _T?x*$]6  
    实际:EXPLAIN不显示执行的查询块的顺序,不会告诉你1或者2阶段的谓词,不会告诉你一个块会多长时间执行一次。基本的,EXPLAIN只是导出一些数据到一个表里,然后结合其他一些信息来进行更多的一些解释。有一些工具来帮助处理此过程(如Visual Explain),但是如果所有的事实都没有被考虑的话,这样的方式只会带来坏处。 S(dxu6C$  
    C8w$Uy1l  
    不要做EDM池太大以避免其分页 }Pnk( =L  
    4vgYHu  
    实际:EDM池通常通过分页来提升性能(这里分页是指扩展存储,而不是磁盘)而不是变得更小并且因为页面置换和其他因素持续重建内部结构。 r4L*;Z%2S  
    }vIH~(H  
    扩展不会关系其他任何东西 "RNm >$n  
    QL"71t~qM  
    实际:什么时候开始的?未来如果世界上充满了SAN或者ESS,那差不多。扩展的影响已经因为新的磁盘缓存控制器而变得很小了,但是仍然有一些额外的检查和处理需要来管理它们。 _hN=Y%  
    oKL~U"y,  
    关系的划分不会在DB2中使用 WRTGj3f}V  
    SR I"^}J  
    实际:关系的划分已经在过去的许多系统中被使用了,可以有效的通过数据库设计者和程序开发者来实现。在目前的商业智能(BI)和市场系统中,它可以被数次用在每个单个程序中。 &QFq {["3  
    =1t!Nhk  
    将所有的包绑定到两个计划中:一个批处理和一个在线的 pah7SXlH  
    mW`N?=e^M  
    实际:在介绍DB2包的时候,这是一个不好的陈述。有许多理由可以说这个理解是错误的。 iqm? LL(  
    u0B=g`qPJ)  
    未授权的读是不好的 j8`ySr?  
    实际:未授权的读并不是一个四字单词但是是一个非常好的性能增强,可以被用在比经常理解的更多的地方。 ]jAk+5o  
    V <L0@]  
    在没有超时和死锁的情况下不会有锁问题 p#hE4%P  
    K 'Xsh:z"  
    实际:事实上没有一个问题发生并不意味着没有需要关注的的性能问题。经常锁定不被认为是一个问题,因为注意力主要放在反应的调节测量(统计死锁或者超时的数量),而不是后发式的调节(监控锁等待时间)。 vq36V>  
    ~{:@v+;o}  
    ESA数据压缩总是好的 4aNvD1u*  
    T#!6AU  
    实际:当压缩能被在很多地方起作用时,有一些情况它能带来问题。每种情况都要在压缩使用前决定是否使用它。这不是可选的,而是必须要在高层决定是否使用还是不使用。

    评论 {{userinfo.comments}}

    {{money}}

    {{question.question}}

    A {{question.A}}
    B {{question.B}}
    C {{question.C}}
    D {{question.D}}
    提交

    驱动号 更多