析DB2性能调优方面的12个疑难问题的全面解析

以下的文章主要描述的是全面解析DB2性能调优方面的12个疑难问题，假如你在实际操作中遇到相似的情况，但是你却不知道对其如何正确的解决，那么以下的文章对你而言一定是良师益友。

1、逻辑设计应该总是能和物理设计完全映射

实际：DB2数据库设计中物理设计应该尽可能的和逻辑结构相近，但是为性能做出的物理设计改变不能被忽略，因为它们并不来自于逻辑设计。

2、将所有东西放在一个缓冲池(BP0)中让DB2管理

实际：就像在DB2手册和其他地方说明的一样，你只能在你的内存非常受限的情况下(10000 4k pages或者更少)，你没有时间去管理它，你也没有考虑到性能的条件下，去这样做。***这样说：不要放置除了DB2 catalog和目录以外的东西进入BP0。

3、DSNDB07是100%顺序的

实际：DSNDB07从来就不是100%顺序的，因为有工作文件中的对页面进行的随机活动。随即活动可能高达45%，但是通常范围是3%到10%。

4、VARCHAR应该总是被放置在行末

实际：这就是总是引发问题的话。如果表总是被读，并且非常少的更新，那么可以，这将会减少CPU负载，但是在其它情况下这样做就是最坏的，甚至如果表是被压缩的。只有在频繁更新的情况下它应该被放置在末尾，但是并不通常这样。

5、程序应该以遵循逻辑过程的方式编码

实际：伪代码或者一个逻辑过程图并不需要考虑DB2性能调优相关的编码方式。在OLTP交易代码中这非常具有戏剧性。

6、大多数过程不在SQL中进行

实际：事实上，问题的反面往往是正确的。SQL是一个非常丰富的语言，能够处理大多数过程。实际上***的困难是SQL经常被用来作为I/O处理器而不是一个集合处理器。

7、代码和引用表应该和DB2声明的referential integrity(RI)一起使用

实际：RI不应该作为一个编辑有效性的快捷方式而使用，这通常属于别的什么，但是应该在真父子关系中使用。

8、表至多有一到两个索引

实际：表应该按照性能需求拥有多个索引。

9、非分割索引(NPI)不应该被使用，尤其是不应该在大的表中使用

实际：这关系到数不清的问题，总体上这些都能被克服，但是NPI是对适当的访问和性能非常必要的。

10、大表应该被分割

实际：因为一个表中有太多数据就意味着有性能下降，这是一个遗留的担心。当一些表中有超过60亿行数据时，这个理解已经被消除了。

11、DB2缺省就是好的

实际：缺省的一般不是***的，他们因版本不同而改变。比如考虑绑定参数CURRENTDATA。

12、不要在SQL WHERE谓词里使用否定

实际：另外一个这种规则并没有被解释清楚。只有谓词是一个否定时，SQL访问路径可能使用一个不必要的表空间扫描。但是在其它的多数情况下，多余的过滤应该在DB2引擎里完成，这会较好。以上的相关内容就是对全面解析DB2性能调优方面的二十个疑难问题的介绍，望你能有所收获。

【编辑推荐】

文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/239319.html<