跨越开发人员和 DBA 之间的鸿沟

作者：Mike Cuppett

为什么有了耐心、信息共享和协作就能够更快速、更全面地提高性能

2012 年 3 月发布

许多开发人员和 DBA 都会下决心设定应用程序性能基准，然后力求不断提高响应速度。但在太多的 IT 组织中，开发团队和 DBA 团队很少花时间来共同探讨应对应用程序性能挑战。此外，相互指责常常阻碍了每个团队，削弱了他们为客户（即应用程序用户）提供最佳结果的能力。

兵分两路的联合进攻是更有效的作战方式，并已被证明可缩短技术问题的解决时间。如果开发人员和 DBA 认定联合作战是更好的选择而不再相互指责，情况会怎样？如果数据库和代码调优工作并非各不相干地独立进行，情况会怎样？这些能否提高改善客户体验的成功几率？根据我的经验，肯定会提高成功几率。

如何实现改善客户体验这一目标？首先，开发团队和 DBA 团队需要达成以下共识：在衡量应用程序的性能表现时，客户使用应用程序的体验必须成为最关键的性能指标。其次，这两个团队必须达成协作而不相互猛烈指责的共识，以便发现和提供最佳性能调优机会，从而提高整体客户满意度。

为了说明，我首先从客户的角度定义应用程序性能，然后举例说明为什么 IT 团队成员需要以更宽阔的视野来考虑应用程序交付方面的问题，而非只是确保各个技术孤岛的工作表现尚可接受。了解客户的期望和观点之后，我们将探究开发人员和 DBA 常常互不理解的三种场景，了解耐心、信息共享和协作如何能够更快速、更全面地提高性能。

了解客户观点

我们在衡量应用程序的性能时，确实只应从经常使用应用程序的用户的角度出发来衡量。令人遗憾而又有些好笑的是，以前的判定方法是如果应用程序用户对着您大声喊叫，则表明存在问题；而完全沉默，就当您不存在一样，则意味着性能可接受或者用户只是被迫接受了应用程序始终存在性能问题这一事实。

我将应用程序性能 定义为一种综合量度，它包括数据库响应速度、代码效率和基础架构交付能力。发出请求之后应用程序响应速度如何？每位客户对此都有自己独特的个人满意度，他们以自己的满意度来衡量应用程序的性能。

现在，让我们从整体上探究客户观点，以便更好地了解我们如何影响其满意度。

衡量客户体验

多年来，我一直使用术语 PACE（客户体验性能保证）来努力让同事相信，从 IT 角度来看，各个技术孤岛（服务器、数据库、应用程序代码、网络、桌面）可能表现良好或可接受（例如可能达到 99% 的成功交付率或正常运行时间），但光是这种情况，绝不 意味着客户也认为应用程序性能良好并高度可用。

下面这个示例启示我们存在这样的情况：最终结果不一定与各个单独的结果相符。这种情况是我在培训过程中遇到的，从中产生的观念让我改变了对以下问题的看法：为客户提供服务时使用的每种技术如何影响整体客户体验。

应用程序性能与客户满意度的对应关系

注意，尽管交付给客户的应用程序所涉及的每个技术孤岛在 IT 组织中被视为“良好”，但客户可能不一定赞同。对于上述示例，如果客户和 IT 之间的 SLA 要求全部事务中 98% 的事务必须在不到 2 秒的响应时间完成，则此示例中显示的指标不可接受，因为成功率仅略高于 93%。当此指标出现在 CIO 的月度信息板报表中时，看起来不是太美妙。

IT 对性能的看法与客户对性能的看法之间存在着这种差距，这让许多业务团队认为 IT 不了解业务，IT 不愿意承担起作为真正业务参与者的责任。业务团队持这种意见并不仅仅是因为存在这种差距。我很高兴地看到，行业内进行了更多的探讨以消除“使 IT 与业务保持一致”的说法，因为这句话鼓励人们将 IT 视为一个由非业务人员组成的团队，必须以不同方式对待他们。（您最后一次听到有人说“使市场营销与业务保持一致”或“使 HR 与业务保持一致”是什么时候？）

人们已经习惯于认为 IT 与业务战略很不相符并且是与“传统的”业务部门相分离的。随着 IT 开始采用不同的沟通方式 — 使用业务语言和业务指标以便能够以业务人员了解的术语证明 IT 为业务提供的价值 — 开发人员和 DBA 便有机会：利用对客户满意度的全新理解大力“促进”这种模式转变，开始提供以业务为中心的性能改进，最后但同样重要的一点，传达这些改进以便业务将 IT 视为致力于提供持续业务改进的面向业务、结果驱动的团队。

业务对服务器正常运行时间、网络带宽利用率和数据库可用性等指标不感兴趣。因此，现在开始，开发人员和 DBA 需要在性能改进规划过程中提出以下问题：

• “这种改变会对整体客户体验产生怎样的影响？”

• “我们应该让其他团队参与验证基础架构交付能力吗？”

• “需要更改哪些优先级来确保我们所做的努力让客户有目共睹？”

开始提出不同以往的问题之后，开发人员和 DBA 能够更全面地了解 IT 供应链 — 用于为客户提供数据的基础架构和流程，这样既发展和加深了团队友谊，又提高了团队的成功率。

现在我们更好地了解了客户观点，下面我们来看看三个这样的示例：开发团队和 DBA 团队决定通过协作、相互尊重的方法对性能低下的应用程序和不稳定的数据库进行改进。

数据库缓冲区缓存和查询结果集：并不互斥

大多数人都同意这样的观点：管理数据库缓冲区缓存对于实现可接受的应用程序和数据库性能至关重要。对此基本上有两种方法：一种方法是扩展缓存，这通常是 DBA 的任务；另一种方法是减少读取到缓存中的数据量，这自然是开发人员的任务。但是，各自独立地解决缓冲区缓存性能问题和查询结果集大小问题不太可能产生最佳的性能解决方案。相反，通过协同工作实现这两种改进，DBA 和开发人员可以显著提升应用程序的响应性能。在 DBA 团队囿于硬件限制的情况下，这种协作会变得更加重要。

例如，DBA 自己就可以轻松地检查数据库缓冲区效率并实施更改以扩展缓冲区，从而获得更好的性能。但是，还应努力减少读取到缓冲区缓存中的数据量，这需要一种更具协作性的调优方法，而许多 DBA 未考虑采用这种方法。反之，我的个人体会是开发人员很少从数据库缓冲区缓存性能的角度来考虑查询结果集的大小。因此，DBA 需要负责主动向开发人员讲解大型结果集可对整体应用程序和数据库性能产生怎样的负面影响。另一方面，开发人员需要帮助 DBA 了解数据要求以及数据使用和数据量的趋势，从而协助制定系统容量规划。

比方说，在请教了数据库缓冲区缓存顾问之后，确定缓冲区缓存需要增加 10GB；但是，目前服务器只有 8GB 的可用空闲内存，其他内存要直到下一个资产购买周期或下一年才能购买。此时 DBA 团队可能会确定安全的做法是扩展 4GB 的缓冲区缓存 — 这将会提高性能，尽管不是以最佳方式。

如果 DBA 团队到此为止就停止调优工作，那么将会错过性能改进的大好良机。为了保持改进势头，DBA 接下来要了解开发团队是否能够一直避免将 6GB 的数据读取到缓存中。数据读取量的减少将有效地“扩展”缓冲区缓存，因为降低了需求。

探究应用程序锁定

即使大家承诺以相互尊重的方式进行协作，但在有些情况下，DBA 和开发人员之间的“语言障碍”也会产生问题。

例如，我们假设 DBA 迅速通知开发人员应用程序因锁定而变慢，但是不知道开发人员可能不完全了解 DBA 试图传达的信息。或者，开发人员可能告诉 DBA 应用程序因为数据库存在某种问题而一直“冻结”。那么，实际问题是什么？

对于 DBA，一种方法是与应用程序团队的主要成员坐在一起，向他们解释当 DBA 表明此行为的罪魁祸首是应用程序锁定时意味着什么。开发人员更好地了解此概念之后，该轮到他们为 DBA 团队进行讲解。

仅仅知道发生锁定远不足以识别问题。开发人员需要 DBA 团队指出所涉及的会话，并提供有关每个会话试图在应用程序中做些什么的详细信息。通过提取出阻塞会话（锁持有者）和被阻塞会话（锁请求者）的当前 SQL 语句，开发团队可以开始研究导致应用程序锁的代码段。

注意，很多时候，阻塞会话没有当前的 SQL 语句，因为所有事务工作均已执行，但尚未进行提交或回滚。这在下面的示例中显而易见。

显示阻塞者和等待者的查询结果：

614

    589859    9688777          6          0 TX        Blocker

 321

    589859    9688777          0          6 TX        Waiter

SQL> @show_blocker

Enter value for sid: 614

762549800 SELECT ID , LAST , FIRST , MI , NICKNAME , GENERATION , CMP_ID ,

762549800 SVCBR_ID , ADDR1 , ADDR2 , CITY , STATE , ZIP1 , ZIP2 , COUNTY

...Session has moved on without a commit or rollback

SQL> @show_blocked

Enter value for sid: 321

1472019480 UPDATE TABLE SET SHIPPER_METHOD = '01' WHERE ID =

1472019480 :B1 AND SHIPPER = 'UPS' AND SHIPPER_METHOD = '10'

...Session is waiting on a commit or rollback from the above session.

根据上面的示例，团队会发现外键索引缺失导致引用完整性 (RI) 检查变慢，这转而会导致下列情况：RI 检查期间在引用的表上产生全表锁，更新主键导致不需要的 RI 查找，错过提交机会，多个流程序列（A-B-C、A-C-B 和 B-A-C）导致用户工作与其他用户工作发生不必要冲突等。

总的说来，当 DBA 不断提供此类信息时，DBA 以及开发团队便会开始注意到一种模式，此模式可引导他们找出问题的根本原因并进行代码修复。

作业运行速度慢

以下是另一个常见的示例：开发人员经常告诉 DBA 团队“数据库速度慢”，因为作业的运行时间超出预期。DBA 非常普遍地会做出防御性反应，这通常反映出他们完全误解了开发人员所模糊传达的信息，开发人员并非是在推诿责任。

在此示例中，DBA 需要知道作业时间改变了多少以及作业持续时间何时开始增加。经验丰富的 DBA 可以快速区分出是要处理的数据量增加的问题（因此需要作业运行更长时间来完成），还是需要考虑硬件故障或类似事件。作业时间在一个月内增加 5%，完全不同于作业的运行时间自昨晚以来增加 400%。因此，清楚、准确的沟通大大改善了两个团队对情况的了解，从而最有可能更快地为客户解决问题 — 这是最终目标。

总结

如您所知，开发人员和 DBA 之间的合作能够对客户体验产生正面影响，现在我们对此有了更全面的了解。当然，DBA 团队或开发团队可以各自独立工作以提高数据库性能或代码效率，各自逐步改善应用程序。但我的经验是协作式的方法可以更好地决定加快改进速度的优先事项和“最划算的”机会，这无疑会使 IT 团队赢得应用程序用户的赞赏。

实际来说，开发人员不必知道数据库调优的每个方面，DBA 也无需全面了解调优代码的每个最佳实践。但当每个团队都了解改善客户体验的好处和途径时，他们可以利用其技能来快速产生和实施必要的性能改进变化。

Mike Cuppett 目前在一家财富 50 强医疗保健机构担任数据库团队经理。Mike 专注于创立和领导团队来提高基础架构稳定性和可用性，同时提供性能改进以满足业务需求。Mike 在 Oracle 数据库管理方面具有最强的实用技术技能。