DB2数据库深度优化的五个最佳实践

结构化查询语言（SQL）对于关系数据库管理系统来说是一把双刃剑，既有优点也有缺点。 由于从关系数据库检索任何数据都需要 SQL，因此本文将探讨最终用户、开发人员和数据库管理员 (DBA) 如何访问关系数据库。 当使用高效的SQL时，系统变得易于升级、灵活且易于管理。 当使用低效的SQL时，响应时间和程序运行时间都会延长，还会出现应用系统中断的情况。 鉴于典型的数据库系统通常花费 90% 的处理时间从数据库检索数据，因此确保 SQL 尽可能高效是多么重要。 检查诸如“*FROM”之类的常见 SQL 语句问题只是冰山一角。 在本文中，我们将探讨其他容易识别的常见问题。 需要记住的是，检索相同数据的 SQL 语句有很多种编写方式，因此没有好的查询语句或坏的查询语句，而只有满足适当要求的查询语句。 每个关系数据库都有自己的优化和执行查询的方式。 因此，每个 DBMS 都有自己的查询技术来实现最佳性能。 本文将使用 Quest 软件中的示例和概述重点介绍 /390 和 z/0S。

十七年前，这份提示表会更长，并且会包含对最小化场景的更正。 DB2 的每个新版本都添加了数千行新代码来扩展智能优化、查询重写和执行。 例如，多年来，一个称为数据管理器的组件经常被提供作为“第一阶段处理”，以将其过滤能力提高一百倍。 另一个组件是关系数据服务器，它通常作为“第二阶段处理”提供，以执行查询重写和其主要功能的优化。 另一个关键组件是 DB2 优化器，它根据当前的 SQL 使用访问路径来确定要检索的数据。 DB2 优化器在每个 DB2 版本中都得到了改进，考虑了其他 DB2 目录中的统计信息并提供了新的和改进的访问路径。 图 1 显示了这些组件以及更多组件，并描述了 DB2 如何处理数据或 SQL 请求。 这就是以下性能技巧的用武之地。

在这篇文章中，我们将回顾一些比较有代表性的 SQL 问题。 还有更多 SQL 性能技术超出了本文的范围。 与所有指南一样，所有这些提示都会有一些例外。

提示 1：验证是否提供了适当的统计信息：

对于 DB2 优化器来说，除了语句本身之外，最重要的资源是在 DB2 目录中创建的统计信息。 优化器根据众多选择来使用这些统计数据。 DB2 优化器为查询选择非最佳访问路径的主要原因是统计信息无效或丢失。 DB2 优化器使用以下目录统计信息：

定期执行“”命令来更新 DB2 目录统计信息，以便您能够在特别繁忙的生产环境中全面了解情况。 为了最大限度地减少执行“”命令的影响，请考虑使用采样技术。 即使 10% 的采样也足够了。 另外，“”命令可以更新统计信息。 DB2 使您能够更新额外的 1,000 个条目以获取不均匀的分类统计信息。 当每个条目递增时，请注意对所有引用的绑定时间的影响。

您如何知道何时缺少统计数据？ 当目录或工具不提供此功能时，您可以手动执行查询。 目前，DB2 优化器无法针对缺失的统计信息提供特定警告。

提示 2：尽可能使用阶段 1 和阶段 2 谓词：

第一阶段数据管理器或第二阶段关系数据服务器将处理每个查询。 当您处理查询时，使用第 1 阶段将比使用第 2 阶段具有巨大的性能优势。虽然谓词确定第 1 阶段可以处理它，但通常谓词会将您限制为第 1 阶段查询。 此外，每个谓词都经过测试，以评估它是否比另一个谓词更有资格作为索引路径。 某些谓词无法作为第 1 阶段进行处理或不符合索引条件。 了解您的查询是否可以在阶段 1 中建立索引和处理非常重要。以下是已记录的阶段 1 或（+-able 谓词是可以由数据管理器评估的谓词）谓词：

还有一些谓词无法记录为阶段 1，因为它们不可能始终处于阶段 1。连接表序列和查询重写也会影响谓词被过滤掉的阶段。 让我们使用一个示例查询来展示重写 SQL 的影响。

示例 1：COL1 和 COL1 之间的值：

阶段 1 无法识别的任何类型的谓词都是阶段 2。以下是阶段 2 谓词。 但是，重写可能有助于可索引阶段 1:Value>=:VALUE 的查询

提示 5：如果值在未来 3 年内不会更改，请使用常量和文字（对于静态查询）：

DB2 优化器充分利用所有不均匀分类统计信息，并为任何列统计信息提供一系列值，特别是当谓词中没有找到主变量时（>'X'）。 主机变量的目的是使事务能够容纳可变变量； 当用户请求输入值时最常使用它。 主机变量不需要在每次变量更改时由程序重新绑定。 优化器准确地考虑了这种可扩展的性能。 当首次发现主变量 (>:hv5) 时，优化器使用以下图表来评估过滤器元素，而不是使用目录统计信息。

列的基数越高，谓词的过滤元素越低（保留某些行的预测）。 大多数时候，这种评估可以帮助优化器选择合适的访问路径。 然而，有时谓词的过滤元素与实际的过滤元素相差甚远。 这时通常需要调整访问路径。

解决方案

它是一个集成控制台，提供 DBA（数据库管理员）执行日常数据库管理任务、空间管理、SQL 调优和分析所需的核心功能，并且可以执行性能诊断监控。 它由 DB2 软件专家编写，提供功能丰富的可视化用户界面，并支持在 Unix、Linux 和大型机上运行 DB2 数据库。 DB2 客户不再需要使用单独的工具来维护和使用他们的大型机和分布式 DB2 系统。

SQL调优组件提供了完整的SQL调优环境。 它是唯一可用于 DB2 并提供完整 SQL 调优环境的产品。 该环境包括以下几个部分：

1.调优实验室：通过使用场景，可以对单个SQL语句进行多次改进。 然后可以立即比较这些场景，以确定哪个 SQL 语句提供最有效的访问路径。

2、对比：可以立即看到SQL语句修改后的性能变化效果。 通过比较多个场景，您可以看到对 CPU、花费的时间、I/O 和更多统计数据的影响。 此外，数据比较将确保您的 SQL 语句返回相同的数据子集。

3. 建议：SQL调优组件提供的建议会找到白皮书等中指定的所有条件。此外，如果出现新的场景，SQL调优组件甚至会重写SQL并合并选定的建议。

4. 访问路径和相应的统计信息：在 SQL 上下文中，对于 DB2 访问路径，应显示所有适当的统计信息。 尝试理解为什么选择特定访问计划时无需进行猜测。

强大的功能演示了上述 SQL 调优技术等等。 本文的其余部分将被证明是由更丰富、更透彻的知识组成的。 它不仅可以提高您的SQL语句的效率，还可以帮助您全面提高数据库的性能。 包括上述各种调整技术。

解决方案提示 1：验证具体提供的统计数据：

一旦在“建议”列中描述了 SQL 语句，就会提供一整套建议，包括发现何时没有可用建议的能力。 对于这些建议，我们始终坚定不移地予以落实。 每个建议都有相应的“建议操作”。 此建议的操作提供了有关如何纠正该建议所确定的问题的指导。 这将打开一个由重写的 SQL 或脚本组成的新场景，以方便对象分析。 在此示例中，显示了建议，但缺少统计信息，并且将在脚本中设置相应的建议操作，该脚本包含用于在建议操作窗口中选择任何对象的命令。

并且可以生成必要的命令来更新所有选定对象的统计数据。

另外，管理人员可以自动收集、维护和验证表空间中的统计信息以及表和索引级别。 以下示例显示了数据库中所有表空间的统计测试报告。

解决方案提示2：尽可能改进第2阶段和第1阶段的谓词：

SQL 调优组件将列出所有谓词并指示这些谓词是“”还是“非”。 此外，还将检查每个谓词以确定它是否有资格进行索引访问。 这个单独的建议可以解决响应时间问题，并在谓词重写期间取得一些成果。 在下面的示例中，查询被视为非和非（阶段 2）。 该初始查询是在谓词之间输入的。 打开一个新场景，并重写谓词以使用大于、小于符号。 此比较确定查询重写对性能的影响。

创建一个新场景并重写查询以在列值中使用“a>=”和“a”