新体系结构带来新挑战
　　Edwards 认为从客户/服务器向多层体系结构改变影响了数据库性能优化和调整几个重要方面 — 两个最重要方面是资源管理以及数据库工作负载跟踪
　　
　　暗藏资源泄漏
　　Edwards 解释说:“在拥有专用 Oracle 服务器进程传统客户/服务器环境中保护资源思路方法完全区别Oracle 会话启动和停止过程所在应用连接具有非常有限生命期因此如果存在些效率较低和较差资源管理比如应用无法关闭游标或应用有内存泄漏 — 那么当连接断开时这些都被自动清除泄漏及低效率影响和持续时间不太明显在多层世界里您倾向于拥有个由应用服务器多次重复启动和使用连接池因此如果有游标或内存泄漏则它们会增加和持续存在并不会消失资源泄漏 — 如连接泄漏、内存泄漏和游标泄漏 — 具有明显影响并可能最终导致产品应用或环境发生故障”
　　
　　Edwards 经常被召来尝试解决非常重要硬件服务器、数据库或应用由于这种泄漏而无法正常工作情况他回忆道:“有次个大型产品级硬件服务器 — 它支持多个全天候工作 oracle 数据库 — 由于 PGA 内存泄漏而反复崩溃数据库应用和配置导致操作系统耗尽了可用虚拟内存(物理内存和交换空间) — 我们在个 oracle 例子中发现了内存泄漏大小总计超过 45 吉字节！在另个案例中连接泄漏使应用服务器连接池不可用；应用中不良连接管理导致应用服务器多个例子被制约并挂起而在另个案例中应用在不经常执行代码体中具有大量游标泄漏这些泄漏最常见结果是单个连接数超出游标最大数量 — 但有时整个 Oracle 例子会有危险”
　　
　　Edwards 认为资源泄漏潜在影响非常严重“使其具有潜在危险部分原因是在测试或监视过程中很难发现它们特别是在它们和容量相关情况下它们往往会令人难以觉察地潜伏着缓慢地侵蚀系统宝贵资源直到它们突然膨胀堵塞造成灾难性后果”
　　
　　跟踪损伤
　　跟踪和配置是调整另外方面Edwards 认为它们已受到体系结构变化巨大影响
　　
　　他指出:“在客户服务器体系结构中(尤其是 Oracle 专用服务器环境)会话和专用服务器进程具有独占、对关系因此您可以打开跟踪功能操作工作负载关闭跟踪功能然后从个进程个跟踪文件中查看步骤顺序 — SQL您可以实际查看语句所执行顺序您知道该跟踪文件中只有您语句并且不必通过多个跟踪文件来重建您会话识别要跟踪会话也更容易能够以特定、可识别 Oracle 用户名来执行每个用户会话”
　　
　　他提示说:“在具有连接池多层世界里情况完全区别应用本身并不总是明确地控制工作单元或者管理其自身连接应用端很少关注会话 — 因此当您要进行跟踪时您不知道是什么服务器进程将会获取该跟踪输出您不知道在哪个跟踪文件中 — 经常有很多跟踪文件 — 获取您应用线程此外在个进程跟踪文件中您可能拥有来自多个用户会话步骤因此很难辨别哪些语句来自您自己应用以及它们以何种顺序执行更糟是所有连接 — 有时同时有数百个连接 — 可能是以相同 Oracle 用户(应用服务器用户)来执行 — 而不是以真实、可识别最终用户来执行每个连接因此您不能简单地识别和区分出需要检查会话”
　　
　　Edwards 指出这些复杂性给预见性应用监视和容量计划造成了困难并影响对已发现性能问题处理“如果您最终用户说:‘咦我某些特定功能好象运行很慢’假如没有数据库以外补充信息很难进行调查并且很难了解该功能当前正在哪个连接上执行和涉及到多少个语句 — 而且难以判断问题根源SQL 效率不高？数据库或应用服务器有问题？如果偶尔有争用和某种类型等待事件则可能很难进行识别和归类判断性能为何没有达到最佳原因已经成为复杂、曲折过程并且您必须使用更多手段”
　　
　　调整提示和窍门技巧
　　Edwards 认为有效调整多层体系结构关键是以下 3项策略:采取全局观点、使用科学思路方法论、采用从 SQL 开始工作调整策略
　　
　　全局思路方法
　　Edwards 说由于多层体系结构中有许多级常见调整是每次只关注级而忽视了全局“您需要具有更普遍、更全面观点您需要能够解释最终用户操作时间各层间通信等待时间经常成为问题并且这种问题不容易测量、隔离或再现我们可以独立查看每层 — 应用服务器层、RDBMS 层、客户端层 — 而且可能每层在其自身范围中都表现得很高效但最终用户体验仍然很糟因此您必须能够在所有区别层中以及在层间通信方面监视和估计时间”
　　
　　查看全局可能需要将区别小组人们集合在起以便他们能够增加相互了解
　　
　　Edwards 说:“在大多数机构中可能出现情况是DBA、UNIX 或系统管理员团队(Team)和网络团队(Team)都属于区别组他们没有必要了解其他人事操作系统工作人员不了解数据库工作负载而数据库工作人员不了解操作系统资源网络团队(Team)也有自己单独领域我认为您确实需要全面了解 I/O、内存、CPU 以及网络情况您需要能够解释所有这些信息了解它们知道何时饱合或何时出故障并知道选择什么思路方法来增加资源或减少问题您越是能够使区别团队(Team)在这方面协同工作并相互了解效果就越好”
　　
　　科学思路方法
　　Edwards 强调调整另个方面是采用科学思路方法
　　
　　他说:“您必须拥有评估性能问题并对其进行量化经验化科学思路方法学而不是基于假设或直觉而采取行动所包含部分原因是确保您得益于历史方面性能情况:工作流状况如何、已经完成了多少工作、资源消耗程度有多大如果您没有应用历史资料您就不了解如今情况相对优劣以及它们和以前情况有多少差别”
　　
　　在查看历史数据时Edwards 建议在具有工作流时应该主要关注工作流模式“您需要建立使工作流可预测并具有致性思路方法是否每天都有非常相似类型指令事务或者事务是高度即席查询其工作流复杂性变化很大？在我经历中J2EE 和多层应用可能有定程度可预测性、指示性并且它们经常在本质上是事务型因此研究历史数据很有用处用于建立将会洞察调整过程和容量计划模式”


　　
　　SQL 居先策略
　　在开始进行调整过程实际步骤时Edwards 坚决主张从 SQL 开始
　　
　　他承认:“要调整环境您总有事可做如更改 I/O 规划、更改高速缓存Cache内存结构等等但是当您更改 SQL 时可以显著影响工作负载如果您用相反方式来做结果将完全相反90％ 时间里您只需通过调整 SQL 本身即可显著减少资源消耗从而改变资源需求情况(内存、cpu 和 I/O)”
　　
　　Edwards 解释说从数据库端来看多层体系结构中调整 SQL 基本目标和思路方法和客户/服务器方式没有显著差别
　　
　　他指出:“在这种情况下客户端不是 SQL 形式应用或者 Visual Basic 应用和 C 而恰恰是应用服务器本身但是它仍在进行 SQL 或者通过 SQL*Net 或者通过 JDBC 瘦客户端我们需要在数据库端使用思路方法学和此很相似我们需要监视正在运行什么语句并查看哪些语句成本最高(资源密集)我们需要查看总计资源消耗查看我们是否当时被限制在某些点 — 内存、CPU、磁盘或网络 — 以及是否发生争用”
　　
　　为找出正在运行成本最高 SQLEdward 从语句级数据收集开始
　　
　　他说:“完成这项工作有许多思路方法或者通过手工创建查询或者使用 STATSPACK 或那些收集当前所执行 SQL 统计信息第 3方实用工具您可以根据逻辑 I/O、物理 I/O、分析和执行比率和计数以及其他数值找出成本最高 SQL您可以查看 I/O 大小和数量、读写比率以及内存数量但是如果有个我可以看作 SQL 成本代理原因那么我查看它执行逻辑 I/O 数量 — 对我来说这是可以用于了解特定语句相关影响最有指导意义单个量度”
　　
　　Edwards 说在识别出哪些 SQL 语句成本最高以后就应该设置调整目标优势级“我们看着条语句并提问:它是每月运行次还是每年运行次或是每天运行数百次？您必须提供某种加权原因以评判需要满足哪些语句 — 这些语句在形成历史观点方面很有用处”
　　
　　Edward 建议在找到需要调整 SQL 语句后在可能情况下应手动调整这些语句 — 这可能意味着完全优化它们“经常出现情况是您需要退回去并且说:‘好吧现在总体业务目标是什么？’如果您正在调整个包括十步过程中某个步骤而您实际上可以将它压缩为包括两步过程则全局观点会为您节省很多时间和精力”尽管调整高成本 SQL 是 Edwards 最优先考虑但他提示并不是所有高成本 SQL 都可以更改“不能更改 SQL 可能是硬编码应用中 SQL 或者是由 EJB 容器或类似工具生成 SQL在这种情况下您可能希望更改数据或创建其他结构这些结构能够导致执行计划更改并具有更高效率”
　　
　　其他调整策略
　　Edwards 调整策略超越了 SQL 调整他认为这时候“无法再进步实质性地调整 SQL 工作负载 — 意味着应用工作负载已经稳定这是服务器环境调整 — 数据库、硬件和操作系统 — 最有效时候了”
　　
　　在这种情况下进行索引似乎是显而易见选择但 Edwards 建议仔细研究进行索引是否是对所怀疑问题正确选择“Oracle 已经提供了很好 JOIN 策略减少了对索引依赖创建索引对根据所涉及结构进行所有访问都产生巨大影响您可能正在以条 SQL 语句代价从另条语句中获益并且在每次输入、更新和删除数据时增加了开销我不是说索引没有用 — 索引绝对有用 — 但它们不是调整圣杯有时它们造成性能降低可能和性能提高程度相当”
　　
　　Edwards 重点强调另个性能优化特性是明智数据高速缓存Cache管理和使用“为了验证特定数据高速缓存Cache正确性您需要确保数据引用模式是将会重复使用数据模式；否则您不需要高速缓存Cache将数据置于共享任务结构中需要开销您需要为自己验证:这种思路方法对于您具体情况有意义它是正确选择”
　　
　　某些其他性能 — Edwards 推荐更加全面地用于多层环境优化技术包括动态连接池 — “供应用服务器使用预先建立连接池可以随着应用服务器工作负载而伸缩” — 以及对所有使用显式 SQL 应用有以下建议:“使用绑定变量以及能够进行分析并被重新使用致性 SQL 语句 — 并尽可能多地使用处理以尽量减少进程间通信”
　　
　　他还建议在多层环境特定层中使用以下技术来定位不良性能:“将应用多个层次分隔开并独立测试这些层例如在多层 Web 应用中我们支持客户在网上定购和配置产品我们预见性地监视那些执行举例工作负载进程 — 它们是我们预期在应用中看到举例查询、举例语句 — 这些进程针对数据库并不传输到应用服务器层然后在个单独线程中我们也通过应用服务器来运行它们这样我们就能够找出差异以验证是应用服务器还是数据库运行缓慢”
　　
　　调优策略
　　尽管多层体系结构调整无疑是比客户/服务器环境调整更复杂业务但 Edwards 所使用策略可以帮助您显著简化调整过程并使调整过程更高效Edwards 建议简单地浏览全局并且使负责区别层次团队(Team)相互进行对话这是良好第步而使用科学思路方法学进行调整可以使整个过程更加高效
　　
　　在理想情况下对当今调整所面临挑战更好认识也会造成应用设计过程改变这种改变使得调整和管理更易于进行Edwards 指出:“通过在体系结构设计阶段考虑调整和监视问题在应用实施以后您可以最大限度地获得可用于调整应用信息” — 这样就实现了重要步其目标可能是 DBA 真正圣杯:自调整多层应用