在运行于WebSphere 7和DB2的Java应用程序上进行性能分析后，我们发现大部分时间都花费在com.ibm.ws.rsadapter.jdbc包中处理与数据库之间的连接。
我们如何调整JDBC性能？
当数据库性能成为瓶颈时，还有哪些策略可供选择？
谢谢。
4个回答
3
- stacker
2
谢谢提供链接，我们有一个连接池，但我不确定如何在DB2端进行测量。 - user271858
两个链接现在都失效了 :( - t3b4n
2
慢连接时间的一个原因是数据库未被激活，直到第一个应用程序尝试连接它时才打开其文件并分配其内存缓冲区和堆。在运行测试之前，请请求DBA确认数据库已经启动。运行LIST ACTIVE DATABASES命令（从本地DB2服务器或远程连接上运行）应该显示你的数据库在输出中。如果数据库未激活，请请DBA使用ACTIVATE DATABASE yourDBname显式激活它。这将确保即使最后一个用户断开与数据库的连接，数据库文件和内存结构也保持可用。
使用GET MONITOR SWITCHES确保所有监视器开关都针对你的数据库启用，否则你将错过一些可能揭示性能细节的重要信息。跟踪与这些监视器开关相关的数据的额外开销是很小的，而性能数据的价值是显著的。
如果数据库始终处于活动状态但仍然感觉很缓慢，则存在称为事件监视器的详细的DB2跟踪，它们将遇到的所有内容记录到文件、管道或DB2表中。语句事件监视器是我经常使用的一种，用于分析SQL语句效率和UOW卫生情况。我还更喜欢承担额外的代价将事件监视器记录到表而不是文件中，这样我就可以使用SQL搜索各种模式的数据。db2evtbl实用程序使得相当容易定义你想要的事件监视器并创建用于存储其输出的表。使用SET EVENT MONITOR STATE命令启动和停止你创建的事件监视器。
使用GET MONITOR SWITCHES确保所有监视器开关都针对你的数据库启用，否则你将错过一些可能揭示性能细节的重要信息。跟踪与这些监视器开关相关的数据的额外开销是很小的，而性能数据的价值是显著的。
如果数据库始终处于活动状态但仍然感觉很缓慢，则存在称为事件监视器的详细的DB2跟踪，它们将遇到的所有内容记录到文件、管道或DB2表中。语句事件监视器是我经常使用的一种，用于分析SQL语句效率和UOW卫生情况。我还更喜欢承担额外的代价将事件监视器记录到表而不是文件中，这样我就可以使用SQL搜索各种模式的数据。db2evtbl实用程序使得相当容易定义你想要的事件监视器并创建用于存储其输出的表。使用SET EVENT MONITOR STATE命令启动和停止你创建的事件监视器。
- Fred Sobotka
1
谢谢，这些也适用于iseries DB2吗？ - user271858
1
根据我的经验，您所看到的情况非常普遍。要问的问题是DB2连接究竟在做什么...
首先要做的是尝试将性能问题隔离到网站的某个部分-即应用程序的一个部分是否存在性能差的情况，当您找到它时，可以增加跟踪日志以查看是否可以看到导致问题的查询。
此外，如果您与DBA交谈，他们可能能够对数据库进行一些分析，告诉您哪些查询需要花费时间返回值，这也可能有助于您的故障排除。
祝你好运！
首先要做的是尝试将性能问题隔离到网站的某个部分-即应用程序的一个部分是否存在性能差的情况，当您找到它时，可以增加跟踪日志以查看是否可以看到导致问题的查询。
此外，如果您与DBA交谈，他们可能能够对数据库进行一些分析，告诉您哪些查询需要花费时间返回值，这也可能有助于您的故障排除。
祝你好运！
- mransley
0
- 连接池
- 缓存
- 数据库管理员
- Ken Liu
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接