内容
简介: Optim™ Performance Manager for DB2®
for Linux®, UNIX®, and Windows® 4.1 大大改进了以前在
DB2 Performance Expert for Linux, UNIX and Windows 中提供的数据库监视功能。这个版本提供经过重新设计的基于
Web 的用户界面,提供用于快速探测问题的概况和警报指示板,为诊断指示板提供方向明确的工作流,有助于分析问题的根源。为了帮助解决
SQL 问题,通过集成 Optim Query Tuner 支持按上下文 SQL 调优。Optim Performance
Manager Extended Edition 还增加了更多性能监视功能,比如对 Java™
和 CLI 应用程序的全程数据库性能监视,以及通过集成 Tivoli® 监视提供企业范围的监视功能。Extended
Edition 还包含 DB2 Workload Manager 的配置和管理工具,可以更方便地通过设置工作负载优先级避免性能问题。本文通过一些场景讲解
Optim 性能管理解决方案如何帮助防止、识别、诊断和解决数据库性能问题。本文还概述了打包方式。
Optim Performance Manager (OPM)(以前称为 DB2 Performance
Expert)帮助组织在数据库和数据库应用程序问题影响业务之前解决它们。于 2010 年 4 月 6 日发布的
Version 4.1 是开发团队艰苦努力的成果,这个版本更容易安装、运行和使用。
Optim Performance Manager 支持监视 DB2 for Linux, UNIX,
and Windows V9 数据库,包括单分区、多分区和 pureScale 数据库。
在新产品 Optim Performance Manager Extended Edition 中还增加了重要的新功能。除了基本的
Optim Performance Manager 功能之外,这个新产品还包含用于全程数据库监视的 Extended
Insight 功能、与 Tivoli 企业监视解决方案的集成以及对配置 DB2 Workload Manager
功能的支持。
在本文中,我们介绍 Optim Performance Manager 4.1 中的新功能和改进,包括:
新的基于 Web 的用户界面消除了对工作站客户机的依赖,让获取性能信息更加方便了。(仍然可以使用 DB2
Performance Expert Client。)健康状态汇总视图根据关键性能指标以图形化方式提供监视的所有数据库的即时健康状态信息。健康状态汇总视图还为出问题的领域提供视觉警报,比如
I/O、内存、日志记录、工作负载、排序和锁。
对于任何警报,可以显示更详细的相关信息,然后向下钻取到每个领域的详细诊断指示板。这些指示板提供重要的性能指标和正在运行的
SQL 语句,有助于快速探测问题。在图 1 所示的健康状态视图示例中,应用程序长时间等待锁。(注意:锁等待警报需要
DB2 9.7 Fix Pack 1。)
图 1. Optim Performance Manager 中的健康状态视图
(查看图 1 的
大图。)
图 2 说明如何向下钻取到详细信息,了解哪些应用程序涉及锁问题以及这些应用程序正在执行哪些语句。
图 2. 锁问题的详细信息显示正在执行的 SQL 语句、锁住的对象和正在执行的应用程序
(查看图 2 的
大图。)
有时候,您收到一封电子邮件,它说数据库出现了一个问题。可以直接打开这个数据库的 Overview 指示板,查看多个问题领域的关键性能指标,然后可以向下钻取到每个领域的详细诊断指示板。例如,图
3 显示 pedemo 数据库的 Overview 指示板,它通过红色的警报图标表明 I/O、锁和系统领域出现了问题。
图 3. Optim Performance Manager 中某一数据库的
Overview 指示板
(查看图 3 的
大图。)
对于 Overview 指示板上的大多数性能指标,都可以打开相应的图形视图,显示系统行为如何随时间变化,从而发现瓶颈或高峰。可以通过详细指示板的链接进入适当的指示板,从而进一步分析问题。例如,图
4 显示从 Overview 指示板打开的缓冲区池命中率图。突出显示详细的 Buffer Pool and
I/O 指示板的链接。
图 4. 缓冲区池命中率随时间变化的图形
如果单击 Overview 中 Buffer Pool and I/O 指示板的链接,会看到与图 5
相似的内容。
图 5. Buffer Pool and I/O 诊断指示板
(查看图 5 的
大图。)
这个指示板说明缓冲区池的工作效率如何。在这个指示板上,可以选择某个缓冲区池,向下钻取到使用这个缓冲区池的表空间和表。
关于指示板的更多说明
可以通过多种方法访问详细诊断指示板,用它们帮助分析具体的性能问题。为了帮助您更好地了解可以获得哪些详细信息,表
1 总结了 Optim Performance Manager 中可用的诊断指示板:
表 1. Optim Performance Manager 诊断指示板
指示板 |
用途 |
Active SQL |
识别并分析某一时间段内长时间运行的查询。可以停止查询。如果安装了 Optim Query Tuner,可以按上下文启动它进行进一步调优。
|
Buffer pool and I/O |
在缓冲区池、表空间和表级检查并调优数据库 I/O。 |
Extended Insight(只在 Extended Edition 中) |
检查数据库应用程序的事务响应时间,判断时间花费在哪些地方及其原因。如果安装了 Optim Query
Tuner,可以按上下文启动它进行进一步调优。见 图 10。
|
Logging |
检查并调优日志性能。 |
Locking |
识别并分析死锁、超时和锁冲突。如果安装了 Optim Query Tuner,可以按上下文启动它进行进一步调优。
|
Memory |
检查 DB2 实例和数据库的内存消耗。判断是否可以减少内存,还是需要增加内存。 |
System |
检查系统资源。如果使用 Optim Performance Manager Extended
Edition,可以从这个指示板启动 Tivoli 监视(如果安装了的话),获取关于系统资源的更多详细信息。
|
Utility |
按计划执行实用程序并识别故障。 |
Workload |
获取工作负载利用率的概况。 |
在基于 Web 的用户界面的背后,Optim Performance Manager 使用一个强大的存储库服务器,它以一分钟的时间间隔(可配置的值)从监视的数据库收集性能指标并把它们存储在一个
DB2 数据库中。这支持在出现问题之后探测和解决问题(“在周末发生了什么?”),还可以查看随时间变化的趋势,有助于为未来的增长制定计划。(预定义的报告有助于这种分析。详细信息见
使用交互式报告进行趋势分析 一节。)每个诊断指示板都有直观的时间滑动条,可以用它浏览收集的性能数据,分析在发生问题的时间段发生的情况,见图
6。
图 6. 可以用滑动条查看当前或历史性能数据
(查看图 6 的
大图。)
本节讨论预定义的交互式报告,可以用它们帮助进行趋势分析。这些报告是交互式的,可以从生成的报告向下钻取到更详细的信息。可以使用以下报告:
- 前 n 个 SQL 语句
- 连接的应用程序
- 数据库和数据库管理器配置
- 表空间的磁盘空间消耗,包括增长率
图 7 显示前 n 个 SQL 语句报告的示例。
图 7. 前 n 个 SQL 语句报告的示例
(查看图 7 的
大图。)
在前 n 个 SQL 语句报告中,可以通过单击语句向下钻取到更详细的语句信息。
图 8 所示的报告示例显示表空间的磁盘空间消耗,包括增长率。
图 8. 表空间磁盘空间消耗报告的示例
(查看图 8 的
大图。)
在表空间磁盘空间消耗报告中,可以通过单击表空间向下钻取到更详细的信息。
本节讨论有助于加快安装和运行速度的改进,包括综合的安装程序和预定义的监视概要文件。
Optim Performance Manager 使用一个综合的安装程序安装 Optim Performance
Manager 的所有组件,包括应用服务器和 DB2 存储库。安装之后,可以直接启动 Web UI 并添加要监视的数据库。可以通过选择预定义的系统模板为监视的数据库添加监视设置。Optim
Performance Manager 预定义了适用于 OLTP、业务智能和 SAP 数据库的模板,见图
9。
图 9. 配置监视向导列出预定义的监视模板
单击 Finish 开始监视,还可以调整所选的模板。
在 Optim Performance Manager 4.1 中,新增了控制谁可以进行监视和谁可以进行配置的功能。没有特权的用户只能看到跨数据库的
Health Summary 和 Alert Overview 信息。具有 canMonitor
特权的用户还可以查看他们有此特权的任何数据库的详细指示板。对数据库具有 canManageAlerts
特权的用户可以修改警报设置,比如警报阈值。这个特权系统可以更方便地让比较多的用户能够监视数据库,同时只允许选定的一部分用户能够控制配置。
对性能影响最大的因素之一是性能低下的 SQL。现在,可以从 Optim Performance Manager
中分析 SQL 活动的任何指示板启动 Optim Query Tuner(如果安装了),就会在 Query
Tuner 中按上下文执行这个 SQL 语句。下面的指示板支持启动 Query Tuner:
- Active SQL 指示板,用于识别长时间运行的 SQL 语句
- Locking 指示板,用于识别造成锁问题的 SQL 语句
- Extended Insight 指示板(只在 Extended Edition 中),用于识别属于响应时间长的事务的
SQL 语句,见图 10。
图 10. 从 Extended Insight 指示板启动 Optim
Query Tuner
(查看图 10 的
大图。)
前面已经讨论的所有功能在 Optim Performance Manager 的两个版本中都可用。本节讨论只能在
Optim Performance Manager Extended Edition (OPM EE)
中使用的特性。第一个功能称为 extended insight,它可以监视和报告应用程序的数据库全程响应时间。这个版本中的关键改进包括:
扩展探查 CLI
和静态应用程序
可以用 Extended Insight 检查 SQL 语句在软件组合中经历的每个处理步骤。这有助于快速地找到造成响应时间问题的位置:在应用服务器(比如
WebSphere™)、网络还是数据库中。可以对希望的响应时间 SLA 设置阈值,如果事务的响应时间超过阈值,可以看到警报。
以前,Extended Insight 只能用于动态的 Java™ 应用程序。在这个版本中,Extended
Insight 已经扩展到更多应用程序环境,包括支持 DB2 CLI 应用程序。可以监视许多重要的业务应用程序,比如
Cognos® 或 DataStage®。可以监视任何使用 DB2 CLI 的应用程序,这意味着对于
CLI 应用程序可以看到与 Java 应用程序相同的详细信息,包括驱动程序时间、网络时间和应用程序时间,见图
11。
图 11. 现在可以扩展探查 CLI 工作负载
(查看图 11 的
大图。)
为了简化 Extended Insight 的使用,为 WebSphere Application Server、SAP、Cognos、DataStage
和 InfoSphere SQL Warehouse 任务预定义了工作负载视图。可以通过这些视图区分不同用户、应用程序、主机名、WebSphere
Application Server 和 SAP 系统的响应时间。
OPM EE 4.1 中对 Extended Insight 功能的另一个重要改进是支持静态应用程序。IBM
一直强调静态 SQL 的好处,包括:
- 提高可管理性(通过使用有区别的包名)
- 改进性能并使性能更一致(关于使用静态执行和 pureQuery 的性能结果见 参考资料
中的链接)
- 提高安全性(降低动态 SQL 注入的风险)
可以使用 OPM EE 4.1 中的 Extended Insight 功能获取使用静态 SQL 的应用程序的详细信息,包括包、节和集合信息。还可以获取关于监视数据的详细信息,见图
12。
图 12. Extended Insight 现在支持静态 SQL
(查看图 12 的
大图。)
SQL 调优的重要步骤之一是找到 SQL 的源代码以便修改它。这就像是大海捞针,尤其是在 SQL 由
Hibernate 或 JPA 等第三方软件生成的情况下。为了帮助寻找源代码,Extended Insight
指示板可以显示 pureQuery 元数据,比如 Java 类、包、应用程序名、方法名和源代码行号,见图
13。
图 13. Extended Insight 指示板显示 Java 源代码元数据
(查看图 13 的
大图。)
可以通过这个特性快速地找到 SQL 源代码,有助于数据库管理员和开发人员的协作。这个特性需要 pureQuery
Runtime 的许可证并应用特定的补丁包。另一篇文章将讨论这些需求。
Optim Performance Manager Extended Edition 把 Optim
的深入数据库性能探查与 IBM Tivoli® 提供的企业范围探查集成在一起。这个强大的组合把事务响应时间监视从数据库扩展到了整个事务处理路径。
数据库应用程序环境可能很复杂,事务常常要经过多个中间件组件,包括 Web 服务器、应用服务器、消息服务器、事务服务器和数据库服务器,见图
14。
图 14. 复杂的应用程序环境需要专门的诊断和纠正工具
IBM Tivoli Composite Application Manager (ITCAM) for
Transactions 产品可以监视整个事务处理路径,涉及其中许多组件。当 ITCAM for Transactions
探测到事务执行问题时,它可以确认问题出在事务处理路径中的哪个组件(隔离)。然后,它可以为深入检查组件内部提供一个启动点。对于
DB2 数据库组件中的任何事务问题,ITCAM for Transactions 可以在出问题的数据库事务的上下文
中启动 Optim Performance Manager Extended Edition 中的 Extended
Insight 功能。这样就可以使用 Optim 提供的深入数据库探查功能进一步隔离问题并快速地解决它。另外,Tivoli
监视产品提供更深入、更丰富的操作系统、网络和存储信息,可以在 OPM EE 的 system 指示板中访问这些信息。
下面三个场景进一步说明 Tivoli/Optim 集成的好处:
在这三个场景中,只使用 Tivoli Enterprise Portal (TEP) 控制台作为用户界面,通过它执行所有活动。
场景 1:在整个事务处理路径中感知和隔离数据库事务问题
图 15 所示的 ITCAM for Transactions 视图显示一个(简化的)事务路径的拓扑,在这里事务要经过三个组件:WebSphere
Application Server 实例、JDBC 驱动程序和 DB2 数据库。连接组件的箭头显示事务流逝时间。
图 15. Tivoli 拓扑视图
事务路径的这种图形化表示让操作人员可以更方便地研究整个事务路径,识别和隔离任何问题。注意,尽管 图
15 显示的事务拓扑非常简单,但是可以使用 TEP 中的拓扑导航功能研究更复杂的拓扑。另外,可以使用
ITCAM 警报、通知和状态以自动化方式捕捉潜在的问题。
场景 2:向下钻取数据库事务问题的详细信息
如果在事务拓扑中发现了数据库事务问题,可以使用 OPM EE 的 Extended Insight 功能按上下文轻松地向下钻取,进一步隔离数据库组件中的问题,从而尽可能快地找到解决方法。
图 16 说明这种向下钻取功能。
图 16. Tivoli 拓扑视图显示数据库上引发的警报
在这个示例中,WebSphere Application Server 上正在运行几个 JSP,它们都通过
JDBC 驱动程序对 DB2 for Linux, UNIX, and Windows 数据库(名为 GSDB)执行
SQL。注意,事务从 JDBC 驱动程序到数据库花费的平均执行时间是 40ms,这导致数据库上出现警报(由数据库图标右下部的红色箭头表示)。这提醒操作人员他们需要向下钻取这个数据库以研究这个警报。向下钻取的方法是单击数据库图标,然后单击
Database Diagnostics,见图 17。
图 17. 启动 Optim Performance Manager
在 TEP 中的一个新视图中启动 Optim Performance Manager Extended
Edition 的 Extended Insight 指示板并保持相同的事务上下文,这样就可以研究这个数据库的事务,见图
18。
图 18. 在 Tivoli Enterprise Portal (TEP)
中显示的 Optim Extended Insight 指示板
(查看图 18 的
大图。)
数据库管理员可以使用 OPM EE 提供的领域专家功能从这里开始进一步研究这些事务以隔离问题。可以从
TEP 使用 OPM EE 界面的所有功能。
场景 3:使用
Tivoli 监视从 Optim Performance Manager 向上钻取以研究潜在的系统问题
第三个场景也是按上下文启动,但是方向与第二个场景相反。在这里,您仍然在 TEP 中,但是在 OPM EE
中研究潜在的数据库问题。在研究期间,在 OPM EE system 指示板上发现了潜在的系统问题。为了获取更多信息,单击图标启动
OPM system 指示板正在显示的系统的详细 Tivoli 系统信息视图(仍然在 TEP 中),见图
19。
图 19. 从 OPM 启动 Tivoli 系统信息视图
(查看图 19 的
大图。)
尽管这里通过三个单独的场景介绍集成点,但是典型的问题隔离过程往往以各种组合方式把这三个场景无缝地融合在一起。
在 DB2 for Linux, UNIX, and Windows 中,管理工作负载优先次序和资源利用率的关键功能是
DB2 Workload Manager (WLM)。DB2 Workload Manager 是 DB2
Performance Optimization Feature (POF) 的组成部分,它根据优先级自动地管理工作负载。这有助于提高资源利用率,尤其是在工作负载差异很大的情况下。例如,可以让执行速度很快的操作性工作负载优先于审计或特殊报告等特殊活动。可以直接给工作负载分配服务子类(比如
CEO 和价格查询工作负载),也可以让 DB2 WLM 根据工作负载的估计成本给工作负载分配子类,见图
20。工作负载的成本基于优化器成本,计算中包含 CPU 时间和流逝时间。
图 20. 直接或按估计成本把工作负载映射到服务子类
使用 DB2 Workload Manager 的明显好处是,防止低优先级的工作负载或次要的查询占用系统资源,导致高优先级的工作负载无法获得满足服务水平协议所需的资源。(关于
DB2 WLM 功能的更多信息见 参考资料。)Optim
Performance Manager Extended Edition 4.1 包含配置 DB2 Workload
Manager 的工具。按上下文提供对于工作负载管理非常重要的监视信息,让用户可以在一个工具内执行相关的配置和检查。现有的
WLM 工具包含在 InfoSphere™ Warehouse 9.7 中,作为管理控制台的组成部分。DB2
Performance Optimization Feature 在同一个包中包含 DB2 WLM 和
OPM EE。
另外,业务过程允许先在比工作负载或用户更高的级别上划分资源。在做出配置决策时,也可以按上下文看到所需的信息。下面几节详细讨论这些功能,然后给出两个从
OPM EE 使用 WLM 配置工具的场景。
按业务过程划分资源
在 OPM EE 4.1 中,可以创建业务过程,可以把用户或应用程序分组到业务过程中。这样就可以使用并发度限制粗略地划分系统资源。还可以对不同的组或应用程序应用不同的策略。
可以配置各个业务过程的资源划分,见图 21。
图 21. 在业务过程之间划分活动
可以看到三个不同的业务过程如何粗略地划分 160 个并发活动。还可以看到百分比图形。在这个示例中,销售业务过程获得的资源最多,因为它是对于业务最重要的过程。
按上下文显示信息
OPM EE 4.1 中 WLM 工具的重要功能之一是,它可以突出显示对于配置最有用的指标并按上下文显示需要的信息。在定义工作负载时,要使用应用程序名、用户名、组名或其他配置标记等连接属性。在以前,为了寻找这些连接属性,管理员必须离开配置工具。现在,可以在配置界面中直接看到当前正在运行的所有活动和它们当前所属的工作负载的连接属性,见图
22。
图 22. 按上下文显示配置 WLM 所需的信息
(查看图 22 的
大图。)
下面几节讨论两个示例配置场景:
场景
1:减少长时间运行的查询的影响
这个场景把大的查询放在它们自己的服务类中,然后限制同时运行这些查询的数量。这个示例还添加了阈值限制,可以自动地取消超过阈值的查询。
OPM EE 4.1 自动地创建一个模板配置,其中包含一个用于长时间运行的查询的服务子类(名为 DS_LOW_CONC_SUBCLASS)。您只需指定适合您企业的估计成本,超过这个值的查询就定义为大
查询。然后,可以为这个服务子类指定并发度限制,从而限制可以同时运行的大查询数量。图 23 表明,对于这个示例,用来定义大查询的最小成本是
100000 timerons,没有设置上限。这个服务子类的并发度限制是 8 个并发活动。
图 23. 低优先级服务子类的模板配置
可以通过创建更多服务子类实现粒度更细的控制和监视。
既然已经把长时间运行的查询放在它们自己的服务类中了,就可以通过设置阈值进一步减少它们的影响。可以启用阈值来监视超过限制的活动和/或停止活动。图
24 所示的示例对这个服务子类中的查询施加 60 分钟的限制。
图 24. 为查询定义阈值限制
场景
2:确保高优先级应用程序的响应时间更一致
限制低业务优先级的服务子类的并发度会让重要应用程序的响应时间更一致。可以使用报告帮助了解特定时间段内(用滑动条指定时间段)某一服务子类的响应时间的一致程度。图
25 和图 26 分别显示在使用 WLM 限制不重要的服务子类的并发度之前和之后 price_lookup
应用程序中活动流逝时间的视图。尽管大多数活动只花费 .0025 秒就完成了,但是有几个活动运行了 .305
秒,见图 25。
图 25. 启用并发度设置之前的流逝时间视图
图 26 显示限制活动的并发度之后同一个应用程序的情况。
图 26. 启用并发度设置之后的流逝时间视图
限制并发度之后,没有任何活动花费的时间超过 0.0855 秒。这比最差情况性能好了三倍。在这两种情况下,最常见的响应时间都是
0.004 秒。但是,在修改设置之前,有差不多 10% 的活动花费 0.0155 秒或更长时间;而限制并发度之后,只有不到
5% 的活动花费这么长时间。换句话说,总体响应时间更短了,活动更稳定了。
还可以使用柱状图。通过把修改之前和之后的柱状图并列显示,可以明显地看出差异。
前面几节描述了关键功能以及使用这些功能的场景。表 2 说明提供这些功能的方式。Optim Performance
Manager 提供一套有用的基本功能,包括所有基于 Web 的用户界面和报告功能。Extended Edition
包提供并扩展了所有基本功能,还包含 WLM 工具、Tivoli 集成和 Extended Insight。为了完整,这个表还显示
DB2 Performance Optimization Feature,它不但包含完整的 Optim
Performance Manager Extended Edition,还包含 DB2 WLM 服务器端特性。
表 2. Optim Performance Manager
包
特性 |
Optim
Performance Manager |
Optim
Performance Manager Extended Edition |
DB2
Performance Optimization Feature |
警报和通知 |
X |
X |
X |
概况健康状态汇总 |
X |
X |
X |
诊断指示板 |
X |
X |
X |
标准报告 |
X |
X |
X |
OPM 特权 |
X |
X |
X |
Extended Insight(对 Java 和 CLI
的数据库全程响应时间监视) |
|
X |
X |
Tivoli ITCAM 集成 |
|
X |
X |
DB2 WLM 管理工具 |
|
X |
X |
DB2 WLM 特性 |
|
|
X |
Query patroller |
|
|
X |
本文介绍了 Optim Performance Manager Extended Edition 4.1
在 DB2 性能监视方面提供的关键改进。下面总结一下这个新版本中提供的功能:
- 前瞻性性能管理
- DB2 WLM (Workload Manager) 解决方案,可以把资源分配给高优先级的应用程序(在
DB2 POF 中可以使用完整的解决方案)
- 趋势报告,有助于为未来的容量制定前瞻性的计划
- 警报和系统概况指示板,可以快速地识别问题
- 方向明确的问题解决方式
- 从识别问题到诊断问题,再到解决问题
- 与 Tivoli 集成,可以把总体健康状态监视和数据库向下钻取融合在一起
- 与 Optim 解决方案集成,有助于解决 SQL 问题
- 总体健康状态监视
- 用 Optim Performance Manager 进行引擎监视,用 Optim Performance
Manager Extended Edition 进行应用程序监视
- 为 SAP、Cognos、DataStage、Java (WebSphere) 和 CLI
应用程序提供开箱即用的应用程序监视
- 减少产生价值所需的时间
- 简化了安装和配置
- 简化了问题解决过程
- 为健康状态报告和趋势分析提供报告功能
Optim Performance Manager Extended Edition 在性能管理解决方案中扮演核心角色,它把问题的防止、识别、诊断
和解决 结合在一起。图 27 说明这个解决方案提供的集成,说明解决方案的各个部分如何协同工作。
图 27. Optim 性能管理解决方案可以防止、识别、诊断和解决数据库性能问题
Optim Performance Manager Extended Edition 为 DB2 Workload
Manager 提供配置辅助工具,DB2 Workload Manager 有助于防止
由于失控的查询造成的问题或把资源分配给不重要的工作负载。Tivoli ITCAM 和 OPM Health
Summary 中的警报有助于快速地识别 问题。详细指示板带领您透过问题的表象找到问题的根源,帮助诊断
问题。最后,对于出问题的查询,Optim 集成可以按上下文调整查询,提供修改建议(比如是否需要修改数据库、是否需要重写或替换查询),提供应用程序源代码中需要修改的准确位置,从而帮助解决
问题。
这是一个令人兴奋的版本。它在性能管理方面提供了许多新的可能性。更多信息见 参考资料
中的链接。
学习
获得产品和技术
讨论
|