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

新的体系结构带来新的挑战

dwards 认为，从客户/服务器向多层体系结构的改变影响了数据库性能优化和调整的几个重要方面 — 两个最重要的方面是资源管理以及数据库工作负载的跟踪。

暗藏的资源泄漏

Edwards 解释说：“在拥有专用 Oracle 服务器进程的传统客户/服务器环境中，保护资源的方法完全不同。Oracle 会话启动和停止过程所在的应用程序连接具有非常有限的生命期。因此，如果存在一些效率较低和较差的资源管理，比如应用程序无法关闭游标或应用程序有内存泄漏 — 那么，当连接断开时，这些都被自动清除，泄漏及低效率的影响和持续时间不太明显。在多层世界里，您倾向于拥有一个由应用服务器多次重复启动和使用的连接池。因此，如果有游标或内存泄漏，则它们会增加和持续存在，并不会消失。资源泄漏 — 如连接泄漏、内存泄漏和游标泄漏 — 具有明显的影响，并可能最终导致产品应用程序或环境发生故障。”

Edwards 经常被召来，尝试解决非常重要的硬件服务器、数据库或应用程序由于这种泄漏而无法正常工作的情况。他回忆道：“有一次，一个大型的产品级硬件服务器 — 它支持多个全天候工作的 oracle 数据库 — 由于 PGA 内存泄漏而反复崩溃。数据库应用程序和配置导致操作系统耗尽了可用的虚拟内存（物理内存和交换空间） — 我们在一个 oracle 实例中发现了内存泄漏，大小总计超过 45 吉字节！在另一个案例中，连接的泄漏使应用服务器的连接池不可用；应用程序中不良的连接管理导致应用服务器的多个实例被制约并挂起。而在另一个案例中，应用程序在不经常执行的代码体中具有大量游标泄漏。这些泄漏的最常见结果是单个连接数超出游标的最大数量 — 但有时整个 Oracle 实例会有危险。”

Edwards 认为，资源泄漏的潜在影响非常严重。“使其具有潜在危险的部分原因是，在测试或监视过程中很难发现它们，特别是在它们与容量相关的情况下。它们往往会令人难以觉察地潜伏着，缓慢地侵蚀系统的宝贵资源，直到它们突然膨胀堵塞，造成灾难性后果。”

跟踪损伤

跟踪和配置是调整的另外方面，Edwards 认为它们已受到体系结构变化的巨大影响。他指出：“在客户服务器体系结构中（尤其是 Oracle 专用的服务器环境），会话与专用服务器进程具有独占的、一对一的关系。因此您可以打开跟踪功能，操作工作负载，关闭跟踪功能，然后从一个进程的一个跟踪文件中查看步骤的顺序 — SQL。您可以实际查看语句所执行的顺序。您知道该跟踪文件中只有您的语句，并且不必通过多个跟踪文件来重建您的会话。识别要跟踪的会话也更容易，因为能够以特定的、可识别的 Oracle 用户名来执行每个用户的会话。”

他提示说：“在具有连接池的多层世界里，情况完全不同。应用程序本身并不总是明确地控制工作单元或者管理其自身的连接。应用程序端很少关注会话 — 因此，当您要进行跟踪时，您不知道是什么服务器进程将会获取该跟踪的输出。您不知道在哪个跟踪文件中 — 经常有很多跟踪文件 — 获取您的应用程序线程。此外，在一个进程的跟踪文件中，您可能拥有来自多个用户会话的步骤。因此，很难辨别哪些语句来自您自己的应用程序以及它们以何种顺序执行。更糟的是，所有的连接 — 有时同时有数百个连接 — 可能是以相同的 Oracle 用户（应用服务器用户）来执行 — 而不是以真实的、可识别的最终用户来执行每个连接。因此，您不能简单地识别和区分出需要检查的会话。”

Edwards 指出，这些复杂性给预见性的应用程序监视和容量计划造成了困难，并影响对已发现性能问题的处理。“如果您的最终用户说：‘咦，我的某些特定功能好象运行很慢。’假如没有数据库以外的补充信息，很难进行调查，并且很难了解该功能当前正在哪个连接上执行和涉及到多少个语句 — 而且难以判断问题的根源。SQL 效率不高？数据库或应用服务器有问题？如果偶尔有争用和某种类型的等待事件，则可能很难进行识别和归类。判断性能为何没有达到最佳的原因已经成为复杂、曲折的过程，并且您必须使用更多的手段。”

调整的提示和技巧

Edwards 认为，有效调整多层体系结构的关键是以下三项策略：采取全局的观点、使用科学的方法论、采用从 SQL 开始工作的调整策略。