本文的目的就是告诉应用程序开发人员关于向 DBA 阐述问题的一些技巧，或者至少提供一种阐述情况的方式，减少 DBA 在告诉您如何做时引起的嘲笑。

处境
作为一名应用程序开发人员，除了超过 10 年的 DB2 应用程序支持经验以外，可以说我没有什么真正的证书，但是我认为我完全有资格讨论应用程序开发人员所经历的痛苦。您也许会问痛苦来自哪里？就是那些似乎超出了应用程序开发人员控制之外的神秘的 DB2 问题。事实上，我确实通过了 IBM DB2 V7.1 Family Application Development Certification 考试，因此可以宣称有正式的“IBM 认证的解决方案专家（IBM Certified Solutions Expert）”头衔。但是，我可以肯定地说，这并没有使我比参加考试之前更聪明。（有时候我甚至怀疑除了能够在你的卧室里悬挂上一个证书，认证的整个过程是否有更多的意义。当然这有点离题了。）

我知道，走到附近的非常友好的技术支持区是一件多么心惊胆颤的事，步履沉重地走到数据库管理部门中间，冒冒失失地（也许是装的）宣称，“DB2 有一个问题，因为我的程序不能工作！”绝对不会是我的程序代码有问题！我完全相信，如果 DBA 每次在听到“DB2 有问题”时都能得到一枚硬币，那他们早就可以退休到坎昆（Cancun）岛上去养老，再也不用担心类似 DB2 这样遥远的什么事情了。

与任何事情一样，阐述问题情况的方式也有正确和错误之分。本文的目的就是要告诉应用程序开发人员关于向 DBA 阐述问题的一些技巧，或者至少提供一种阐述情况的方式，减少 DBA 在告诉您如何做时引起的笑话。我经常看到应用程序开发人员在做好准备之前，就急匆匆地跑到 DBA 那儿寻求帮助，不一会儿又愠怒而局促地回到他们的格子间。要记住，您——应用程序开发人员——如果没有做任何准备就把问题带给 DBA，您就不会赢得他们的合作和尊重。

定义问题
要保证您的问题经过很好的定义。DB2 是软件和硬件的复杂组合。尽管 DB2 作为一个关系数据库可能不是完美的，但应用程序代码中的问题和 bug 远远超过 DB2 RDBMS 中的问题。找到 DBA 并告诉他们，您的 DB2 程序“不能工作”、“没有得到正确的结果”或者“异常终止”，并不能向他们提供处理所需要的真正信息。多数 DBA 和其他每个人一样时间宝贵，因此他们没有时间从头到尾调试您的应用程序。我们至少可以对有问题的应用程序或者令人不快的 SQL 语句（这二者都可能深藏在程序的调用链中）作零点调整的基础工作。既然我们日复一日地提供应用程序支持，那么谁又能比应用程序开发人员更适合深入分析应用程序并找到问题的根源呢？在调查问题的来源时，踏入 DBA 的门槛报告问题之前程序员收集的信息（比如 SQLCA 诊断信息）越多，当 DBA 确实参与解决问题时，他们就越能更快更容易地帮助解决问题。

通常，如果我们能识别出令人不快的程序或 SQL 语句，我们可能就会发现什么地方错了而不必去找 DBA。但是当您确实需要 DBA 的帮助时，如果我们能指出“当游标 ABC 打开时问题出在包 XYZ”或者“当试图提取数据时得到 SQL 错误码 -000”，那么就比只是笼统的一句“DB2 不能工作”好得多。如果能够隔离导致问题的 SQL 语句，那么它在 QMF 或者 SPUFI 中能否执行？如果程序运行很长时间，这能否说明问题？程序期望的结果是什么？这里的要点是，拥有详细的信息以支持我们阐述问题，这对于我们瓜分到 DBA 的一点时间来解决问题大有裨益。从我们所说的这一点出发，很容易引入困扰应用程序开发人员的下一个技巧。

坚持参与
不要只是把问题扔到 DBA 的面前并期望能够解决。在这个语音邮件、电子邮件和传真满天飞的时代，发送一个消息到 DBA 领地，并指望不需要提出问题的程序员的参与就能神奇地得到解决，真是太容易了。不论我们将一封电子邮件抄送给了多少个人，除非应用程序开发人员参与到问题的解决中来，否则问题就不可能得到解决。DBA 可以提出建议，提供代码或者 SQL，并且拥有非常棒的工具。尽管如此，除非我们表现出对修正应用程序中的问题的主动性，否则 DBA 何必关心我们是否起床了并重新运行了应用程序？仅仅说“我告诉 DBA 了”并期望某种真正的解决是不够的。我们越表现出参与的愿望，其他人就越愿意帮助我们。

下面的检查表列出了应用程序开发人员可以做的一些事情，以搜集有助于 DBA 的信息：

   隔离问题。这可能需要彻底分析程序中某个长长的调用链。这种费时的工作更适合程序员而不是 DBA 来做。

   识别出令人不快的SQL。如果可能，这个 SQL 语句能在 SPUFI 或 QMF 中执行吗？（问题：在 SPUFI 或 QMF 中执行一个语句与识别有问题的 SQL 语句这个紧急的任务有什么关系? ）

   提供尽可能多的 SQLCA。尽管 SQLCODE 或 SQLSTATE 不错，但是拥有所有的 SQLCA 诊断信息更好。

   执行一个解释（explain）。 在包或者计划（plan）上执行一个解释。DBA 可以帮助您解释结果。（问题：尝试可视化的解释和您自己对结果的理解有什么错误？）

   对于期望的结果有一定的概念。如果不知道您要什么，又怎么知道问题什么时候解决了？

   知道问题存在了多长时间。这个问题已经存在一段时间了，还是刚刚出现呢？

   环境有什么变化吗？应用程序是否作了某些可能导致问题的修改？比如：应用程序重新编译或者重新绑定过（rebound），最近执行过 RUNSTATS，等等。

   处理的数据是否比平常多？ （问题：什么是“平常”？）是否有活动峰值可能造成应用程序问题？

   如果问题出现在产品环境中，能在测试环境中重建吗？尝试让它在测试环境中发生。

博闻多识
我的下一个要点可以说是痛苦的显然（obvious），或者像我的同事们常常说的“痛苦的遗忘（oblivious）”[译者注：这里作者使用了两个形似字，使用一门技术需要了解其基本知识是显然的（obvious），但又常常被人们遗忘（oblivious）]，不管哪一种说法吧，我都要说一说。当使用 DB2 时，最好是学习一下 DB2 的基础知识。如果我们不知道做的是什么，怎么能够处理实际的问题呢？这是一个相关的例子：多年以前我还是一个刚入门的 DB2 程序员，我正在做我的第一个 DB2 应用程序，到半夜的时候我的应用程序作业遇到了一个 SQL 错误码 -904。当时我只知道这是一个 DB2 应用程序，因此一定是 DB2 的问题，是不是？错了。因为不知道到哪里寻求帮助，我首先把电话打给了一个 DBA。这位 DBA 问了一系列的问题，我所有的回答都是“不知道”，之后，他正确地假定他是在跟一位完全没有任何 DB2 知识的人打交道，在这种情况下他完全没有用武之地。查问了一会儿后，这位 DBA 能够推断出我的一个表处于 Copy Pending 状态，我需要对这个表执行一个映像复制（image copy）。多么美妙的回答！什么是映像复制呀？

这个小故事的寓意在于，如果我们在支持 DB2 应用程序，具有一些 DB2 知识是很好的。尽管应用程序人员不需要理解 DB2 的内部工作，我们的确需要了解一些基础知识，以便能够有效地与给我们提供支持的技术领域交流。如果当时我知道 -904 是什么，Copy Pending 状态的含义是什么以及映像复制是做什么的，毫无疑问我就不需要在午夜叫醒那位 DBA 了。随着公司不断地缩小、调整和增大，没有 DB2 背景的应用程序开发人员可能很快发现他们需要支持一个或更多的 DB2 应用程序。我们需要主动学习能够学习的关于 DB2 以及所支持的应用程序的一切知识。相信我，这样可以使每个人的生活更容易一些。

仍然有一个困难的问题，保证 DB2 应用程序具有足够的支持水平应该由谁负责？是公司管理者还是应用程序开发人员？实际上两者都是。如果公司在 DB2 技术上投资，投资的一部分包括确保系统和应用程序开发人员受到适当水平的培训，以及通向成功的适当工具。如果试图节省培训的费用，当出现问题而人员又没有接受足够的培训时，公司就会付出更沉重的代价。但是不能指望公司提供一切东西。程序员需要主动学习一些参考资料，使自己成为更强的 DB2 专业人员。投资可以仅仅是购买一些 DB2 手册，或者从 IBM 网站上阅读 DB2 的白皮书。在 Amazon.com 以及其他网站上可以找到许多很好的手册。

让您的技能跟上潮流
我的最后一点忠告是对所有 DB2 应用程序支持战友而言的：从生疏的新手到经验丰富的老手——一定要多磨炼那些 DB2 技能。DB2 的知识和其他知识一样容易陈旧。DB2 世界总是从一个版本到另一个版本不停地变化，我们必须不断更新和精炼我们的技能。因为现在可能运行着无数种 DB2 平台，指望一个 DBA 提供我们需要的所有知识是不公正的。作为应用程序开发人员，通过自学、课堂也许还有认证，继续 DB2 教育是我们的责任。在这个繁忙的世界中，我们不能把所有的 DB2 需要都依靠 DBA，我们能做得越多，越能自己应付 DB2，我们就越能成为更好的应用程序支持专业人员。一个好的信息源是 DB2 行业杂志，通常不用花钱就能得到，或者花很少的费用参加当地的 DB2 用户组织。如果能说服管理者认为值得投资，那么还有 DB2 技术大会和 IDUG Conferences。通过参加这类活动，应用程序开发人员和系统程序员都可以从中受益。

总之，我想强调指出我并不是说应用程序支持专业人员应该避开 DBA。相反，对于 DB2 而言，DBA 是所有活动都围绕着他转的核心人物。我们需要把 DBA 看成是很有价值的 DB2 资源。关键是我们需要确保我们尽一切努力成为更强大的 DB2 专业人员，这反过来又使我们成为更强大的应用程序开发人员，也不那么依赖于过度操劳的 DBA。

应用程序开发人员应该对他们使用的高级编程语言、JCL、ISPF 等了解很多，而且现在还要对数据库管理系统也了解这么多，这是以专业的态度完成他们的工作的基础。