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

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

跟踪损伤

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

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