如何通过IBMDB2forLinux、UNIX和Windows支持250000次SQL查询

2011 年的黑色星期五，美国顶尖零售商如何通过 IBM DB2 for Linux、UNIX 和 Windows 每秒钟成功支持 250,000 次 SQL 查询。 黑色星期五（美国感恩节过后的星期五）是零售商一年之中最繁忙的一天。这一天之后紧跟着网络星期一和另外几天活动高峰期。在此期间

2011 年的黑色星期五，美国顶尖零售商如何通过 IBM DB2 for Linux、UNIX 和 Windows 每秒钟成功支持 250,000 次 SQL 查询。

黑色星期五（美国感恩节过后的星期五）是零售商一年之中最繁忙的一天。这一天之后紧跟着网络星期一和另外几天活动高峰期。在此期间，零售商的网站性能对于全年盈利至关重要。几大领先零售商纷纷选用 IBM® Commerce Server、IBM DB2® for Linux、UNIX and Windows (LUW) 为其电子商务引擎提供技术支持，能够为他们服务我感到非常幸运。

提供卓越的交易性能至关重要，但由于很多零售商明白高性能可能意味着需要支付高费用。零售商如何在降低潜在高交易费用的同时，最大限度地提高性能？

有一种方法能够辨别成本削减领域，我已经为这些杰出企业提供指导和支持长达数年之久。采用这项建议的公司纷纷获得了巨大的成功，而这里的重点是电子商务，原则具有普遍适用性，适用于所有在线事务处理 (OLTP) ，包括 SAP、Siebel、PeopleSoft 和 Manhattan Associates，另外还适用于自主开发应用程序以及其他许多应用程序。

按照自己的方式操作

您的 DB2 LUW 具有一定的处理能力，或许这很像您的个人预算。您必须按照自己的方式生活，您的必须在能力范围内运行。为了在有限的能力范围内兴旺发展，您必须控制自己的成本。很显然，您无法印刷钞票，这种做法不合法，并且我也不主张投入更多资金购买更多的硬件，因为性能问题不可能通过购买额外的硬件得到彻底解决（至少需要控制在合理的费用范围内）。

降低成本 = 提高利润

这将会得出一个最基本的道理：您需要重点控制 DB2 的内部执行成本。许多用户希望采用 db2top、db2pd 或其他产品并考察价格。价格可能非常有趣，但却并不十分有用，因为价格可能会因为用户数量、时间段或业务周期而存在很大的差异。

另一方面，在未进行重大调整的情况下，费用相对恒定。无论是 100 名用户还是 10,000 名用户都没有关系，产品查询事务将会执行一定数量的 SQL 语句，这些 SQL 语句将带动一定数量的逻辑和物理 I/O 操作，同时消耗 CPU 周期。虽然您可以通过扩大缓冲池和 SORTHEAP 内存来避免 I/O 操作，但内存中的页面逻辑 I/O 仍会消耗宝贵的 CPU 周期。

那么，如何才能降低 CPU 成本呢？

发现问题只是成功的一半

中国古语有云，“一旦明确说明了问题，问题也就解决了一半。”如果您希望 OLTP 电子商务应用程序能够以最快的速度运行，那么您需要准确回答下面这项紧要问题“哪项开支最大？”只有了解最高执行成本出现在哪儿，您才能采取一些措施来降低这些成本。

无可逃避

降低成本包括进行物理设计调整。具体而言，必须根据事务工作负载需求来创建、调整或放弃索引。不要试图将索引设计问题隐藏在巨大的缓冲池背后，这种做法只会耗尽您的 CPU 容量，而锁定遗留问题仍然存在。随着服务器 CPU 利用率开始超过 90%，事务响应时间可能会十分迅速地下降。CPU 利用率需要得到妥善管理，因此问题就变成了：您应当尽量避免哪些会消耗 CPU 时间的环节？

应对高成本问题的关键

我曾帮助过一家顶级美国零售商降低成本，我们通过辨别以下四个领域的潜在问题来实现此目标：
&＃61623; 热点：这些数据库表消耗最高的读取 I/O 成本。目前面临的挑战在于，找出这些费用代表了哪一部分的数据库读取 I/O。
&＃61623; 痛点：要找到痛点，请寻找成本最高的 SQL 语句，在综合汇总过程中，这会促使读取 I/O 进入热点表。
&＃61623; 麻烦制造者：这些表已经承受了最高写入 I/O。在这些表中，每个表上哪些是已定义的索引，哪些表拥有较低的基数？
&＃61623; 双重麻烦：如果这些表正在遭受过度溢出访问，则需要进行重组。
通过专心处理这些领域，零售商取得了一些令人印象深刻的成果。让我们分别研究每个领域。

热点

由于索引是在表上创建的，所以索引被设计为降低事务处理成本的主要解决方案，您必须查看表 I/O。要确定数据库事务的平均表 I/O 成本，请用每个表的 ROWS_READ 除以 (COMMITS_ATTEMPTED + ROLLBACKS_ATTEMPTED)。您的电子商务网站必须在高峰期提供出色的性能，每个表的读取 I/O 成本应当小于 10。如果成本不小于 10，那么要么会遗漏索引，要么需要改进索引。您还可以计算每个表的读取行数比例，只需用 ROWS_READ 除以所有表的全部 ROWS_READ 的总和，然后用得出的数值乘以 100。如果任何表出现高比例且 I/O 成本大于 10，那么说明您已经“明确说明了问题”，问题也就解决了一半。

但是，痛点、麻烦制造者和双重麻烦又分别代表着什么？本文的第 2 部分将对影响成本的其他三个关键领域进行探讨。