创新性应用-王涛 （关于db2）转载

原文：

http://blog.csdn.net/best_dba/archive/2006/07/21/952837.aspx

（颜色为我加，为看起来更醒目）

创新性应用：
对于如今日渐成熟的数据库家族，真正能够在数据库引擎做到创新已经不是一件简单的事情。三大主流数据库oracle, db2和sqlserver真正在每个版本之间提供的不过是对于更多的接口的支持，让数据库能够更有效地做到性能自我调整，支持更多的数据类型，修复过去的bug或者对内存磁盘结构作一些优化调整。真正能够喊出创新这个口号的我想近期也只有DB2对于XML的支持了。
基于早先IBM提出的关系型数据库的架构，所有的主流数据库都逃脱不了类似的架构，每一个表之间的关系被各种各样的constraint所限定，当需要查询一些信息的时候需要对这些表之间做出复杂的join运算得到最终的结果。同时，所有的信息都被分割到一块块小的表中，这样的架构对于如今流行的跨平台跨应用程序之间的数据交换格式XML来说就显得相当不灵活。
XML叫做Extensible Markup Language, 是一种灵活的语言。在其中用户可以标记自己的tag来定义其数据类型。在这些tag中用户可以自己定义elements或者attributes的名称，这样的话只要得到了XML文件即使另一个对此系统毫不知情的用户也可以很轻易地读懂这些数据。
这样的话，当不同的用户或者应用程序在交换数据的时候，只要遵循XML标准，每一个应用程序可以针对自己所使用的数据类型编写XML解释器，将XML文件中的数据轻易地转化成自己使用的数据类型，这样就可以保证在不同的应用程序之间数据得以快速地交流。
但是作为存储数据的数据库，以往的基于关系的表并不能够很好地适应这种新的需求。用户仍然需要花费大量时间将XML数据转化到关系类型然后输入数据库，或者根据需要编写复杂的查询再将这些数据读取出来。这种方法虽然可行但是对开发者来说无疑于添加了很大的难度，同时从效率上来看，原本的XML文件会被重新解析到各个表中，这个过程对于复杂或者有着大数据量的系统来说是相当消耗资源的。因而，对XML从底层上的支持使得IBM DB2数据库相对于其他数据库管理系统来说有了大幅度的创新。
实际上，DB2 v9对于XML的支持不仅仅体现在XML类型的数据上。一些用关系模型难以解决的问题也可以使用XML模型得以比较轻易地解决。
首先一些以往基于继承类型的数据尽管可以使用关系模型解决，但是需要用到一些递归SQL。但是如果使用XML模型则可以从根本上模拟实现出这种逻辑上的关系。
还有一些极端的数据类型假如使用通常的星型拓扑逻辑可能会产生大量几乎无法管理的小表，尽管每个表中可能只有几条数据，并且某些数据之间的join在理论上是可行的，但是在实际的业务逻辑中却是完全不make sense的，在这种情况下维护以往的关系型数据就会对管理员造成不便，因为同时处理大量表的join会使得性能显著下降（大量的CPU，磁盘操作与内存分配）。但是假如我们将这种数据类型带入XML，很多在关系模型中非常难以处理的问题就会随着结构的不同迎刃而解。
不过计算机技术中没有完全的好与坏，XML在赋予用户另一种存储结构的同时也有着一些值得考虑的因素。
XML的灵活性使得存储数据的单元必须能够接受不同格式的数据，这样就会造成检索的时候为了能够处理各种格式而造成CPU和内存的开销。但是这并不是绝对的。假如一个数据类型需要被分隔在很多表中，对于表的join数据库必须要生成临时表，大量临时表的生成和操作同样会降低性能，而这种开销我们知道在XML模型中可能就是可以完全避免的。所以在选择XML模型和关系模型的时候需要针对具体的业务进行具体分析。
但是db2 v9还没有经历过市场的检验，所以对于XML是否能真正得到用户的认可还是一个未知数。不过从对XML与经典的关系数据模型相比其具有的优势还是不可忽略的。



行业借鉴经验：
在DB2技术支持小组中的每一个case都很值得IBM以外的DBA借鉴。
但是我们很少涉及对于客户项目大框架的问题，所作的工作完全是基于一个个错误信息，unexpected behavior以及性能/内存泄路等细致问题。
在defect support小组中一年以来的经验使我认识到深入了解DB2的内存结构对一个合格的DBA甚至开发员来说都是必不可少的。
我们经常可以见到32位系统中stack与data冲撞的问题，就是说原本只有256MB的私有寻址空间被占满，并且用户没有合理地设置ulimit造成数据库系统crash。
或者经常客户在32位系统中使用大量的bufferpool造成内存耗尽。可是有的人还抱怨“我们操作系统有16G的内存并且只有2个副本，为什么这个数据库分配2G的bufferpool就完蛋了？vmstat还显示我们有很多内存呢！”假如他们能够理解32位应用程序的寻址方法，db2在各个系统下内存的分配模型他们就不会产生这种问题了。
同样开发员也应该理解内存模型。很多人编写的过于复杂的SQL会消耗大量的statement heap，甚至在优化器部分都不能够很好地优化重写原本的语句，这样可能就会造成不必要的NLJOIN或者temp table，对于几个有着几千万行的表查询多使用一个temp table结果绝对是灾难性的。
不过上面的那些东西需要至少一年以上的经验和摸索才能够基本掌握，下面有一些比较有效的寻找问题的方法。
首先当系统出现问题的时候一定不要惊慌失措，以平常心慢慢地narrow down问题才能够最快地找到答案。
一般管理员遇到的问题不外乎几种：
1） 错误信息，可以重现或者不可重现
2） unexpected behavior，比如db2move当force之后向默认数据库继续load数据
3） 性能问题，分为两大模块
A） 整机性能下降
B） 单独查询性能下降
这些问题每一个类型都有自己的特征，也需要有针对性地进行分析。
在论坛上与DBA讨论的时候经常会发现有很多DBA对于问题分析的过程还是一团迷糊，实际上其根本原因还是在于对DB2的底层架构理解的不够深入和对各种各样的工具(db2batch, db2exfmt)不能够灵活运用。
比如以上提到的错误信息，基本大部分的错误信息都可以从提示中获取解决方案，但是有一些复杂的问题也许甚至db2diag.log里面都不能给出明确的信息，这个时候db2trace就是最有效的武器。Db2trace可以对db2进行内部函数调用级别的追踪，同时还能够监测一些重要变量的变化。当然大部分时候需要对照源程序才能够有所收获，但是我也见过很多trace不需要对照程序就能够理解其流程。而那些重要的内存变量可以很清晰地告诉我们问题发生的那一刻一些参数的变化，很多情况下比如里面出现一个奇怪的路径或者数值，我们就可以查找和那些东西是否有关。
对于unexpected behavior，仔细地阅读文档并且理解相应模块的运作才是根本的解决之道。除此之外也许db2trace是唯一可行的方法了吧。
而性能问题是对所有的DBA来说都是头疼的。其中对于DB2参数的优化并不是很复杂，需要的是对DB2内存模型和运作机制的深入理解，但是对于3-B才是最为复杂的。因为一个查询的性能取决于太多的方面，包括bufferpool hit ratio, 访问计划，执行计划，分区键的设置等等。经常可以见到一个搞DB2很多年的专家也不见得能在这方面有所建树。需要大量的练习并且阅读很多文章才可以理解优化器编译器这部分东西。


应用难点技巧：
与其他两款主流数据库管理系统比起来，DB2有其优势也有自己的不足。
在处理datawarehouse系统上DB2的性能应该是非常优秀的，同时DB2对优化器做的相当完美，对于大部分复杂查询可以有效地将其重写为最优语句，并且分配合理的执行计划。
但是DB2在concurrency control上与locking mechanism上有一定的不足。但是这与DB2的设计框架相关，内存锁的使用在提升效率的同时也对系统的优化要求提到了最高。一个没有得到良好优化的数据库和应用程序经常会出现锁等待的结果，很多人将这方面归结于db2的问题，实际上我们遇到的大部分问题都是客户自己对应用程序与优化做的不足所导致的。
并且DB2在API与function/procedure的提供上还不完善。但是多伦多实验室的人正在尽力完善这个模块，在V9中我们期待看到更多更为强大的函数。
因而我认为在DB2的管理上真正的难点就是在于优化。也许完整地介绍优化需要800页的教材加上一星期的课时，因此在这里就不多说了。
同时对于所有的数据库系统高可用性也是一个比较令人头疼的问题。在DB2种的高可用性对于普通用户来说可能比较复杂，但是我们有一些经典的技术文档可以用来参照自己设置。
对于管理多分区系统的DBA来说，怎样对各分区协调，如何合理地设置分区键是最为重要的。但是作为我们技术支持小组的人，真正深入理解各分区之间的通讯与工作机制才是最重要的。
我记得以前看过一篇文章有个人在口口声声说db2的share nothing架构是骗人的东西，那绝对是因为他对db2多分区理论只是做了一些文字上的理解，但是对于其中的内存，CPU，磁盘资源的分配却根本没有理解。
也许很多人都认为DB2比起其他的数据库系统要复杂很多，但是我个人认为那是由于这些人对其底层的架构和模型不了解所导致的。真正意义上的理解DB2以后就会发现其中的每一个模块都是经过精心设计的。只要完整地优化系统一般来说就不会出现很多朋友所遇到的问题。 

======全面深入的了解db2，然后精心，完整的优化自己的系统。