诊断应用数据库的性能瓶颈
J2EE的崛起
J2EE作为Web应用开发的标准企业计算平台面世，其实力越来越强大，日益普及。J2EE支持遗留应用程序和接口、多种操作系统、分布式和群集式环境，以及高量关键任务应用程序，同时支持安全和管理与监控。
通过提供一种开发分布式、可伸缩应用程序的框架和蓝图，J2EE使公司及其开发者能够集中注意力去编写模块化的定制应用程序代码，并且不必担心安全、资源管理和可伸缩性的细节。
行业领先的应用程序服务器，例如BEA WebLogic Server，能提供许多功能和服务。多个WebLogic服务器实例的群集和故障恢复功能提供了可靠性、可用性和可伸缩性。它们也提供诸如安全和资源管理之类的其他服务，例如执行线程池、EJB高速缓存和JDBC池。第三方所写的Java数据库连接（Java Database Connectivity，JDBC）驱动程序进一步抽象和简化不同数据库管理系统（DBMS）间数据存取的编码。
这就是一个强大的平台，该平台能够大大简化并且抽象开发分布式、高量企业应用程序的低层细节。
J2EE性能的挑战
听上去没有什么会出问题，是吗？的确如此，除了应用程序不能达到最终用户或者服务级协定所要求的性能标准之外。一个开发项目和商业创新是否成功要视其迅速检测、诊断和解决这些性能问题的能力而定。
由于它们的复杂性日益增加，与早期的僵硬应用程序环境相比，在这些多层的、分布式J2EE应用程序中的性能瓶颈更难以诊断。J2EE环境包含多层相互连接的软件和硬件组件，它们相互作用，满足任何既定的最终用户请求。性能团队的成员——设计师、开发者、应用服务器管理员和数据库专家——他们有自己对系统的见解，而且可能拥有他们自己的经验仓库或者“设备中心”的诊断工具。但是这个团队的成员怎样一同工作将问题分离出来呢？如果没有对J2EE系统所有组件的全面广泛的了解，如果他们不能相互交互，那么一位性能专家怎样找出哪台服务器速度慢？哪个组件速度慢？哪种资源不足？数据库引擎是主要瓶颈，还仅仅是一个次要因素呢？
这种挑战可能会使无准备的人或装备不良的人畏缩不前。这种困惑可能使团队的成员焦头烂额，或者更严重时，他们会任意指责过失。
“是应用程序，还是数据库？”
公司里最常见的挫折就是面对表现不佳的分布式J2EE应用程序感到困惑：“它是应用程序，还是数据库？我们应该从哪里开始修理？”通常情况下，会有人斗胆作出一种推测，不再继续在浩繁的代码寻找错误的或者低效率的算法，或者放弃彻底搜寻SQL语句和数据库表格的作法。换句话说，他们挑出应用程序或者数据库（或者在最坏情况下，两个都选），并努力将从谜团中分离出来的片断最优化。
令人遗憾的是，这种解决问题的观点经常是过度简化的，这是因为应用程序、数据库、WebLogic Server都不是在孤立地运转。对这个问题的一种综合解决方法需要提高对这个相互联系的系统内所有三个部分的能见度：WebLogic资源利用和配置、应用程序架构以及数据库查询的执行，而且包括基本的硬件基础设施性能。
有了对这些子系统相互作用的了解，性能团队的成员就能有效地分离有问题的组件，并将问题交给正确的职能专家进行处理。
对相互之间关系的了解是关键
在此，了解和相互关系是两个关键词。没有这两个关键词，检测和根除的要求就使诊断极其艰难。
我们需要了解WebLogic服务器运行时JMX的性能度量。我们需要了解SQL查询的计时和结构，以及数据库引擎所运行的存储过程。而且最重要的是，我们需要了解最终用户发出的请求在跨越整个分布式系统时的端到端计时，而且所有的组件要与JDBC连接池交互，DBMS的调用要以显式的基于单个请求的方式来制定。
