降低高昂交易成本四大关键第1部分.PDFVIP

降低高昂交易成本的四大关键：第 1 部 分 2011 年的黑色星期五，美国顶尖零售商如何通过 IBM DB2 for Linux、UNIX 和 Windows 每秒钟成功支持 250,000 次 SQL 查询 /2012/10/four-keys-to-reducing-high-transaction -costs-part-1/ 作者：Scott Hayes | 发布时间：2012 年 10 月 9 日 | 请耐心等待 打印 PDF 黑色星期五（美国感恩节过后的星期五）是零售商一年之中最繁忙的一天。这一 天之后紧跟着网络星期一和另外几天活动高峰期。在此期间，零售商的网站性能 对于全年盈利至关重要。几大领先零售商纷纷选用 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 时间的环节？ 应对高成本问题的关键 我曾帮助过一家顶级美国零售商降低成本，我们通过辨别以下四个领域的潜在问 题来实现此目标：  热点：这些数据库表消耗最高的读取 I/O 成本。目前面临的挑战在于， 找出这些费用代表了哪一部分的数据库读取 I/O。  痛点：要找到痛点，请寻找成本最高的 SQL 语句，在综合汇总过程中， 这会促使读取 I/O 进入热点表。  麻烦制造者：这些表已经承受了最高写入 I/O。在这些表中，每个表上哪 些是已定义的索引，哪些表拥有较低的基数？  双重麻烦：如果这些表正在遭受过度溢出访问，则需要进行重组。 通过专心处理这些领域，零售商取得了一些令人印象深刻的成果。让我们分别研 究每个领域。 热点 由于索引是在表上创建的，所以索引被设计为降低事务处理成本的主要解决方案， 您必须查看表 I/O。要确定数据库事务的平均表 I/O 成本，请用