DB2调优的流程示例

简述 如何更好地诊断性能问题？我们在此可以讨论一下如何有条理的诊断数据库性能的话题，以此来协助确定数据库是否存在性能问题，并制定补救措施。 我们可以先设想一下性能问题涵盖的场景： SQL查询执行速度比预期慢--- 工作负载或批处理作业没有在预期时间内完成，或事务率和吞吐量在一段时间内逐步下降---系统整体速度下降--- 在大多数情况下，出现性能问题是因为系统资源的使用不当或 CPU、I/O或内存等资源的过度使用，这往往揭示了这些系统资源中的瓶颈。在经过适当调优的环境中，系统资源会得到最佳使用，不会过度依赖其中任何一种资源。 诊断性能问题的不妨从这里开始：识别所有资源瓶颈。为了便于练习，我们先从Windows可以找到所提供的一些可以帮助识别这些瓶颈的工具。 CPU 瓶颈 如果系统上有一个或多个 CPU 一直显示 90% 以上的利用率，这通常意味着系统存在 CPU 瓶颈。任务管理器可以帮助您找出系统是否存在 CPU 瓶颈。其他工具（如 perfmon.exe 和资源监视器）会显示 CPU 利用率，也可以帮助识别 CPU 瓶颈。 内存瓶颈 内存瓶颈并不是很常见，这主要是因为数据库的堆和参数通常是根据可用内存进行配置的。但是，如果在 perfmon 和资源监视器中看到非常低的可用内存，那么这可能表示存在内存瓶颈。有时候，在使用 STMM 时，系统上的可用内存可能会非常低，但这并不总是意味着该系统存在内存瓶颈。 网络瓶颈 如果在资源监视器中看到非常高的网络利用率，那么这可能表示存在网络瓶颈。资源监视器以百分比的形式显示网络利用率，这有助于快速识别网络瓶颈。如果资源监视器显示网络利用率在 80% 以上，这通常表示存在网络瓶颈。 I/O 瓶颈 如果系统上有一个或多个磁盘在 90% 以上的时间一直处于忙碌状态，或磁盘队列长度不断显示较高的数量，这通常意味着系统存在 I/O 磁盘瓶颈。Windows工具（如资源监视器和 perfmon）可以帮助识别 I/O 瓶颈。任务管理器确实可以显示 I/O 活动，但资源监视器和 perfmon 可以显示每个磁盘的 I/O 详细信息，还可以显示活动时间的百分比，这有助于识别任何特定的磁盘上是否存在瓶颈。 有多种 Windows工具可以帮助确定系统是否有一个或多个资源瓶颈。 步骤 1：使用 Window 工具识别瓶颈 任务管理器 任务管理器是获得有关整个系统的使用情况的信息的最快方式。例如，任务管理器的 Processes 选项卡，其中的列提供每个进程的 CPU、内存、I/O 统计信息 (View > Select Columns)。任务管理器很好地总结了 CPU、I/O、内存和网络利用率。任务管理器也提供了进程的详细信息，帮助找出哪些进程正在消耗最多的 CPU，哪些进程正在执行最多的 I/O 等。 如果任务管理器显示，整体 CPU 利用率一直超过 90%，那么这是存在 CPU 瓶颈的一种迹象。任务管理器也在 Performance 选项卡显示每个 CPU 活动。如果其中任何一个 CPU 的利用率一直接近 100%，这可能也意味着存在一个 CPU 瓶颈。通常情况下，这意味着数据库中的工作负载是单线程的，无法利用系统上的所有可用 CPU。 任务管理器还显示每一个进程从磁盘上读出/写入的数据量的详细信息。该信息本身非常有用，但它没有显示每个磁盘的利用率百分比。这使得用户很难仅通过任务管理器来断定系统是否存在 I/O 瓶颈。 perfmon 虽然任务管理器和资源监视器对于确定系统活动都是很好用的工具，但不能使用它们将系统活动记录在日志中，以供日后分析。Perfmon 工具可以将系统活动记录在日志文件中。这提供了灵活性，让管理员和 DBA 可以在一天中的不同时间收集 perfmon 数据，并在以后使用它们进行分析。Windows 附带的 perfmon 工具可用于捕获性能数据和资源使用情况的统计数据。对于许多类型的问题调查，了解如何设置和捕获 perfmon 日志都很关键。在监视 I/O 时需要注意的是：需要通过运行 diskperf -y （-ye 表示带区集）启用磁盘计数器，然后重新启动。在 Windows 2008 或 Windows 7 上，需要运行 perfmon，将活动捕获到日志文件中： 在命令提示符下运行 perfmon。 从左面的框架中选中 Performance Monitor。 右键单击它，并选择 New > Data Collector set。创建一个合适的名称，并单击 Next。 提供一个将会保存日志的目录名称。 Data Collector set 出现在左边的框架中。在左边的框架选中 Data Collector Set > User Defined，并选中您在步骤 4 所选择的名称。它的状态应该是已停止，因为我们希望在收集开始之前，先添加所需的计数器。 右键单击已定义的 Data collector set 并选择 New > Data Collector。提供一个名称，并选中 Performance counter data collector，然后单击 Next。选择采样频率并增加性能计数器。Perfmon 工具提供了很多计数器来监视多种参数，下面介绍最有用的几个计数器。这对于收集数据是一个很好的出发点。根据具体的要求和情况，用户可以收集和监视其他计数器。 选择正确的诊断工具 对于普通的监视，perfmon 是一个很好用的工具。还可以保存其日志，以便更轻松地比较系统在按预期工作时和系统有性能问题时的系统活动。这往往可以为手头上的问题提供有价值的线索。然而，快速查看任务管理器和资源监视器的数据有时也可以帮助实时查找系统中的瓶颈。一旦确定了瓶颈，就可以采取相应的措施来消除瓶颈。   步骤 2：I/O 瓶颈 — 详细研究 如果 perfmon 显示有一个或多个磁盘的磁盘时间在 80% 以上，或资源监视器显示有一个或多个磁盘上的活动时间在 80% 以上，那么这通常意味着系统中存在一个 I/O 瓶颈。可以从 perfmon 或资源监视器确定具有很高利用率的一个或多个磁盘。一旦确定了大量使用的磁盘，就可以找出放置在磁盘上的内容。 是否有任何 DB2 表空间容器放置在磁盘上？ db2 list tablespace containers for 对数据库中的所有表空间重复此命令。 或者，DB2 日志文件是否被放置在大量使用的磁盘上？ db2 get db cfg for 搜索 newlogpath 数据库配置参数。 或者，这些磁盘是否包含实用程序文件，比如备份目标或加载文件？查看已执行的备份/负载命令。根据大量使用的磁盘上的内容，解决方案也会有所不同。 表空间容器上的磁盘瓶颈 如果将大量使用的磁盘分配到表空间容器，那么请找出表空间中的对象。如果表空间对应于某个数据表空间，那么请找出在表空间中创建的表。 步骤 3：CPU 瓶颈 — 详细研究 如果 perfmon 或资源监视器显示有一个或多个 CPU 的使用率超过 90%，那么这通常意味着系统存在 CPU 瓶颈。与 I/O 瓶颈一样，第一个步骤是识别消耗大量 CPU 的数据库操作。通常情况下，已知道有一些数据库操作会消耗大量的 CPU： 语句编译 LOAD、BACKUP、runstats 等实用工具 大量排序活动 要确定在查询编译中是否花费了大量 CPU，请查询 MON_GET_WORKLOAD 表函数。 步骤 4：内存瓶颈 内存瓶颈并不是很常见，主要是因为数据库的堆和参数可以根据可用内存进行设置。大多数 DB2 堆是自动的，并基于可用内存提供分配值。STMM 在利用可用内存和将内存分配给最需要内存的堆这两方面做得很好。但是，在不使用 STMM 的情况下，有可能存在内存使用不当的情况，如果内存分配得过多（也就是说，分配值高于可用内存），则有可能导致大量分页活动。如果 Perfmon 或资源监视器显示了许多分页活动，这通常是因为分配给不同堆的内存已超过实际内存。在这种情况下，最好是打开 STMM，让 DB2 调优缓冲池、排序堆和其他堆的内存。   步骤 5：网络瓶颈 出现网络瓶颈的原因通常是存在大量四处移动的数据（比如非常大的结果集和客户端负载等），或者操纵 LOB 的应用程序位于客户端-服务器架构中。MON_DB_SUMMARY 管理视图很好地说明了等待不同的资源所花费的时间。NETWORK_WAIT_TIME_PERCENT 字段提供了等待网络响应的时间百分比。通常情况下，等待网络所花费的时间应该小于 1%。如果该值高出几个百分点，并且 perfmon 和资源监视器显示网络带宽在大量被占用，那么系统可能遇到了网络瓶颈。在这种情况下，应用程序可以将一些应用程序逻辑以存储过程或者 UDF 的形式移动到服务器。在客户端负载的情况下，可以将负载拆分为更小的部分，在不同的时间执行它们，而不是一次全部加载它们，这样做可以减少网络流量。   步骤 6：锁定问题 如果系统没有任何资源瓶颈，但性能仍然较差，这可能是因为锁定问题。MON_DB_SUMMARY 管理视图中的 LOCK_WAIT_TIME_ PERCENT 字段提供一个高层次的视图，说明了在数据库级别的锁等待上花费的时间。为了获得在锁等待中花费了时间的工作负载的详细视图，请查询 MON_GET_WORKLOAD 监视器表函数。 步骤 7：调优页面清理活动 除了检查系统资源瓶颈和锁定问题，在所有数据库环境中还有另一些重要的事项需要注意。页面清理和预取是两项重要活动，需要对它们进行适当调优来获得最佳性能。在某些情况下，如果页面清理没有得到正确的调优，则有可能出现 I/O 瓶颈。监视表 MON_GET_BUFFERPOOL 提供了一些找出页面清理和预取活动的指标。 步骤 8：调优预取活动 类似于页面清理，我们还需要调优预取活动。在一个真正的 OLTP 环境中，预取可能没有用。但在 DSS 类的工作负载中，预取发挥着重要的作用。在理想的情况下，我们希望 IO_SERVERS IO_SERVERS（预取器）负责所有读取，该操作实质上是异步进行的。下面的查询显示了由 IO_SERVERS 完成的 I/O 读取百分比。 小结 虽然这些步骤没有涵盖可能会出现的所有性能问题，但上面的方法主要侧重于解决性能问题所使用的原则和策略。遵循这些步骤会帮助您缩小问题的范围，并最终帮您解决问题。