性能： 遵循基本原则

Oracle 现实环境性能主管 Andrew Holdsworth 认为，在常规基础上创立的新基准记录说明了出色的数据库性能完全在于遵守基本原则。

OTN:
Oracle 最近重新夺回单系统TPC-C 基准的记录。1 这对客户意味些什么呢？

Holdsworth：
类似 TPC-C 的综合基准已成为市场营销行为。这当然是出色的公关活动，也显示了 Oracle 在性能比拼中仍处于领先地位。但真正重要的是，目前有成百上千的用户在我们的数据库上运行巨大的系统，并且一直很好地满足了他们业务需要的性能和可伸缩性。

OTN:
您们通常可以预见客户性能的前沿。但有没有过不得不对客户说“抱歉，那对我们实在是个太大的挑战”的情景呢？

Holdsworth：
在 Oracle 工作的十多年里，我一直与一些最大的客户打交道，我从来没有对 Oracle 的伸缩能力感到失望过 – 当然，
是指在硬件环境许可的情况下。就在最近，我们被调派去一个大的网站，从它上面查看到，最大负载时 1 秒钟就有几千条查询，这种情况下，他们都认为必须将其系统翻番至 64 CPU 才行。但我们发现，使用一些经过时间考验的应用调整步骤，就能将它们的系统负载减少至只要运行 16 个CPU 就行。因此，数据库储备了足够的性能来满足客户需求，并且需要的硬件比他们原本打算购买的还要便宜。

OTN:
您的性能调整原理是什么呢?

Holdsworth：
我的理念就是“遵循基本原则”。也就是专注于能获得较大性能增益的几个步骤上，在进行任何修改以前真正理解问题所在，避免盲目地因为修改而修改。我经常看到客户修改初始操作系统参数，而修改的原因往往只是因为他们比较容易触到那些按钮而已。
我们经常进行的第一步操作就是将参数都改回到它们的默认值，并且结果往往是 -瞧，我们将性能提升了 3 倍。这种情形也就说明：只要一些细微的调整，Oracle 就能灵活地处理大部分的性能需求！

OTN:
您能就如何获得系统上的较大性能增益建议客户采用一些步骤吗？

Holdsworth：
首先，确保设计合理的表格、创建良好的索引，并且编写优秀的 SQL 语句。这些步骤仍与它们在 25 年前一样重要。
低劣的数据库性能最主要的原因就是 SQL 语句编写得不成功；当您使用设计良好的应用程序时，就可以从 Oracle9i Database的许多新特性中获得其它的性能优势。使用 dbms_stats 生成良好的统计。
使用新的空间管理功能：Automatic Undo Management、Automatic Segment Space Management 以及 Temporary Tablespaces。
设计适合应用程序的数据结构：例如，在已知数据访问模式时集群表可以提高性能，但如果应用程序发生变化并且访问数据的方式也发生变化，将会出现什么情况呢？
在 DSS 系统上，使用表压缩查看 I/O 密集的查询，并不时保存 CPU 和 I/O。创建位图和位图连接索引来调整星型查询。
连接列上的散列分区表可以加速散列连接 – 使用组合的范围-散列分区来获得使用范围分区的易管理性和使用散列分区的连接优化。

OTN:
您刚才强调了良好的应用程序设计，那么，应用程序设计者在设计过程应该注意避免哪些缺陷呢？

Holdsworth：
保持设计的简单明了。这听起来很简单，但复杂的应用程序设计通常会导致低劣的性能。如果数据模式难于理解，
程序员编写的 SQL 语句就会低劣。如果 SQL 读取器不能辨别语句的业务目的，那么优化器就难于对它进行实时优化。
如果您发现自己重复索引相同的列，那么您也许应该重新访问索引模式。避免太多的提取；如果存在许多不能在应用程序逻辑和数据间提供值的软件层，您可能就要重新考虑应用程序开发方法了。

OTN:
Oracle 提升性能的方法是什么？

Holdsworth：
我曾负责创建 Oracle 性能提升方法，并且鼓励 OTN 成员参阅 Oracle9i 数据库性能规划指南巩固这方面的知识。此方法中的关键
步骤如下：

1.从用户那里获得公正的反馈，判断性能目标及进一步需求。在准确估算用户真正需要的性能基础上建立性能规划。
2.收集数据库、操作系统及硬件的统计。如果备齐了所有需要的统计，您还会得到更多方便 – 在解决性能难题的时候，
3.这些统计都将是有力的参考证据。
4.对操作系统进行全面的检查，识别那些可能是系统瓶颈的利用资源。
5.检查常见错误。
6.使用收集的数据建立系统行为的概念模型。
7.提出建议的修补操作，并独立地应用这些操作，以方便对其效果进行量化。
8.确认用户已获得他们需要的性能。如果还没有，重新优化模型并提出新的解决方案。

重复步骤 5、6 及 7，直至获得满意的性能。

OTN:
您能列举您在这方面遇到的常见性能错误吗？
Holdsworth：
当然，下面列举几项：
低劣的连接管理，应用程序为每个数据库交互建立连接或断开连接，而不是共享连接池。
重复的语句解析，因为应用程序不使用指针。
低劣的 I/O 设计；Oracle 建议 SAME （对一切进行条带化和镜像）来安装磁盘上的数据
太少和太小的重做日志
对在线操作进行长期全面的表扫描
因为 SQL 语句不合理或事务设计低劣，在磁盘上进行分类而不是在内存中
从开发至生产迁移过程中的错误，导致统计数据阵旧或索引丢失。

OTN:
经过这些年的经验积累，您已练就了“性能直觉”，将系统统计和实际结果联系起来。请再为我们讲些这方面的内容吧。
Holdsworth：
CPU 利用是用以了解和监控的最简易的系统使用统计。随时监控该统计量，您可以查看系统在工作日内的使用情况，
也可以查看它在数周内的使用情况。然而，这项统计不提供执行了多少商业事务或者每个事务中使用了哪些资源的信息。
有另外两项统计可以更好地表明实际执行的业务事务，即提交的数量和生成的重做的量。可以在 USER COMMITS 和 REDO SIZE
的 V$SYSSTAT 视图下找到这些信息。这些统计量表明了实际事务的数量和数据库中修改数据的量。
如果这些统计量随着时间而增加，并且应用程序和事务逻辑不变，那么您就能知道执行了更多的商业事务。
逻辑块读取器的数字 (V$SYSSTAT 统计‘会话逻辑读出器’) 也能指示系统上的查询工作量。要仔细解释该数字，
逻辑块读取器上数字的变化可能是执行计划改变产生的结果，而不是工作量的增加。

如果有丰富的经验，就能很容易地将数据库统计与应用程序工作量联系起来。性能数据库管理员能使用对数据库统计和
应用程序配置文件的直觉来判断系统工作量的特点。数据库管理员还必须能预料频繁执行的事务的预期性能。理解应用程序
中核心 SQL 语句对性能诊断至关重要。
该活动中的许多项都可以非正式进行。例如，假定一个核心商业事务要求在亚秒响应时间内运行。该事务的初始调查显示该事务执行 200 个逻辑读，其中 40 个是从磁盘中获取的。一次磁盘响应时间为 20 毫秒，要发生的 I/O 时间就是 40 x .02 = 0.8 秒，这可能达不到响应时间目标。数据库管理员就会要求重写该事务，并且将逻辑 I/O 的数字减到 80，从磁盘上获取的数量平均为5 个。