Oracle中的中间件体系结构多层调整

核心提示： 科学的方法 Edwards 强调的调整的另一个方面是采用科学的方法，他说：“您必须拥有评估性能问题并对其进行量化的经验化科学方法学，Oracle中的中间件体系结构多层调整(4)，而不是基于假设或直觉而采取行动，所包含的部分原因是确保您得益于历史方面的性能情况：工作流状况如何、已

科学的方法

Edwards 强调的调整的另一个方面是采用科学的方法。他说：“您必须拥有评估性能问题并对其进行量化的经验化科学方法学，而不是基于假设或直觉而采取行动。所包含的部分原因是确保您得益于历史方面的性能情况：工作流状况如何、已经完成了多少工作、资源消耗程度有多大。如果您没有应用程序的历史资料，您就不了解如今情况的相对优劣，以及它们与以前的情况有多少差别。”

在查看历史数据时，Edwards 建议在具有工作流时应该主要关注工作流的模式。“您需要建立使工作流可预测并具有一致性的方法。是否每天都有非常相似类型的指令事务，或者事务是高度即席的查询，其工作流的复杂性变化很大？在我的经历中，J2EE 和多层应用程序可能有一定程度的可预测性、指示性，并且它们经常在本质上是事务型的，因此研究历史数据很有用处，用于建立将会洞察调整过程和容量计划的模式。”

SQL 居先的策略

在开始进行调整过程的实际步骤时，Edwards 坚决主张从 SQL 开始。他承认：“要调整环境，您总有事可做。如更改 I/O 规划、更改高速缓存的内存结构等等。但是当您更改 SQL 时，可以显著影响工作负载，如果您用相反方式来做，结果将完全相反。90％ 的时间里，您只需通过调整 SQL 本身，即可显著减少资源的消耗，从而改变资源需求的情况（内存、cpu 和 I/O）。”Edwards 解释说，从数据库端来看，多层体系结构中调整 SQL 的基本目标和方法与客户/服务器方式没有显著差别。

他指出：“在这种情况下，客户端不是 SQL 形式的应用程序或者 Visual Basic 应用程序和 C 程序，而恰恰是应用服务器本身。但是它仍在进行 SQL 调用，或者通过 SQL*Net 或者通过 JDBC 瘦客户端。我们需要在数据库端使用的方法学与此很相似。我们需要监视正在运行什么语句，并查看哪些语句成本最高（资源密集）。我们需要查看总计的资源消耗，查看我们是否当时被限制在某些点 — 内存、CPU、磁盘或网络 — 以及是否发生争用。”