在过去几年中,产生了很多著作论述关于 DB2 设计和实现的最佳实践,包括大量图书和文章。这些著作深入探讨了如何设计 DB2 并将其集成到应用程序中。为了提供一些基本指导以让客户和业务合作伙伴了解这些内容,本文汇编了在使用 IBM® DB2® 技术设计和实现应用程序时需要考虑的一系列最佳实践。本文的目标是获得更加有效和高效的 DB2 实现。本文不会为现有 DB2 客户和独立软件开发商(ISV)提供详细的性能最佳实践。
DB2 for Linux, UNIX, and Windows 提供了一个数据库平台,可以在这个平台上构建健壮的、随需应变的业务应用程序。DB2 提供了关系数据的优化管理,而且在 DB2 9 中还提供了 XML 数据的优化管理。
本文假设您了解关系数据库系统(RDBMS)的基本原理,并且用 DB2 或其他 RDBMS 实现过应用程序。本文还提供了一些常用的最佳实践,可以帮助您进行基础的性能设计以及创建易于操作和维护的 RDBMS 环境。同时,本文不会考虑数据库设计的所有领域,比如安全性、备份/恢复以及故障转移。本文还列出了其他领域的一些常用技巧,比如性能,但是不会详细讨论这些主题领域的数据库分析和设计问题。本文还提供了一些附加资源,希望为您提供关于所有 DB2 主题领域的更广泛信息。本文列出的常用最佳实践可以简化与 DB2 相关的应用程序的部署、管理以及性能改善,从而为负责应用程序部署的人员提供帮助。
大量 DB2 技术材料都能够为负责用 DB2 for Linux, UNIX, and Windows 实现应用程序的人员提供帮助。无论是对新手还是有经验的从业者来说,对各种来源的信息进行分类都是一件比较麻烦的事。建议从以下站点开始查找网上可用的 DB2 技术材料。
Information Management developerWorks 专区 包含本文,也包含大量其他的 DB2 文章、许多技术材料、演示代码和可下载的产品试用版。Information Management developerWorks Technical Library 包含了广泛的内容,包括技术文章、产品文档和教程。
可获得大量与 DB2 有关的著作。与 DB2 相关的出版物的最佳来源之一就是 IBM Press。具体包括以下图书:
此外,还可以查阅 IBM Redbooks,其中包含了 DB2 和相关 Information Management 产品的技术性技巧。
对于业务合作伙伴,可以从 IBM Virtual Innovation Center(VIC)获得包括 DB2 在内的 IBM 产品的有用信息。您需要 注册 成为 PartnerWorld 成员才能访问 VIC。要访问 DB2 Course Material,注册之后在 VIC 主页面右侧底端的 Shortcuts 下选择 All courses by product。然后将跳转到一个标题为 “Product Selections” 的 Web 页面。根据提示访问与产品相关的课程材料。
![]() |
![]() |
当将数据库从一个 RDBMS 迁移到 DB2 时,可以对支持的源 RDBMS 使用 DB2 Migration Tool Kit(MTK),这些 RDBMS 包括 SQL Server、Oracle、Sybase 和 MySQL。表、视图、索引、RI 约束、用户定义的函数(UDF)以及一些过程都可以通过此工具迁移。UDF 和过程的迁移质量依赖于源代码的复杂性。还需要进行评估,以确定是否应该以迁移后的 UDF 和过程为基础优化(refine)代码,或者从头重新编码。使用 MTK 时,需要考虑一些重要的数据类型:
通过最小化到客户机的结果集通信量,SQL 存储过程能够降低网络开销,而且存储过程也能够改善静态(预准备的)SQL 的性能。存储过程的其他益处还包括减少客户端处理(通过更多地使用 DB 服务器资源)以及 DB2 的代码管理。使用存储过程的其他技巧还包括:
对于好的数据库性能来说,最大化并发性非常重要。下面列出了一些详细的建议:
现在,动态 SQL 比静态 SQL 更加广泛。通常,动态 SQL 更容易实现,而且通过语句重用,能获得跟静态 SQL 一样的性能。然而,仍然有一些适合静态 SQL 的情形,比如涉及到安全性因素、针对某些 OLTP 工作负载最大化性能等情况。
要获取关于何时使用静态 SQL 的全面信息,请参阅 DB2 在线文档。
要了解特定的 Java™ 环境需要考虑的因素,包括使用 SQLJ 创建静态 SQL,请查阅 “IBM DB2 Database for Linux, UNIX, and Windows Information Center” 的 “Introduction to SQLJ” 部分。
要了解特定 CLI/ODBC 环境需要考虑的因素,包括使用静态 profiling 创建静态 SQL,请查阅 “IBM DB2 Database for Linux, UNIX, and Windows Information Center” 的 “Creating static SQL with CLI/ODBC/JDBC Static Profiling” 部分。
只需在 SQL 语句中使用一次参数标记,然后就可以多次重用。更多信息请参阅 “IBM DB2 Database for Linux, UNIX, and Windows Information Center” 中的 “Parameter Markers” 部分。
对于占用资源很多的 SQL 语句,查看实际的变量值(字符)而不是参数标记也许对优化器较为有益。实现此目的一种简单方式就是在代码中使用字符,而不是使用参数标记。但是,这将导致语句缓存发生过多的插入活动,潜在影响性能和内存使用,因为仅有一个字符值不同的 SQL 语句就会被当作不同的语句。对于一个包中的静态 SQL(比如 SQL 存储过程),通过 REOPT ALWAYS 绑定或预编译选项,可以使用参数标记同时允许通过值进行优化。对于 DB2 9 和 动态 SQL,也可以通过一个全局或语句级别的优化配置来指定 REOPT ALWAYS。
通过使用一些基本原则,可以更有效地使用 JDBC。首先,确保已经针对列数据类型使用恰当的 setxxx 方法将数据绑定到参数标记。这会避免数据类型转换开销过高和可能的 SQL 数据类型失配错误。其次,尽可能避免使用可滚动的结果集设置,因为服务器会实现临时表来支持这种设置。使用这种设置会影响到性能,尤其是使用大的结果集设置时。
一旦开发出了一种模式并且可以使用,将 SQL 语句作为输入使用 Design Advisor 来建议索引。对于经常使用的查询以及大型或复杂的查询,这一点尤其重要。
此外,针对由完整应用程序测试填充的动态 SQL 缓存重新运行 Design Advisor。这允许根据实际工作负载和 SQL 语句的执行频率建议索引。确保在 Design Advisor 执行之前运行了 runstats。
另一个方法可能需要较多的操作,但是允许利用潜在的(“虚拟的”)索引查看访问计划。可通过以下方法实现:
编写 DB2 日志的速度是一个重要的 DB2 性能因素(依赖于数据更新的速率)。以下是一些帮助改善 DB2 记录日志性能的技巧:
了解如何使用访问计划信息优化 SQL 语句。访问计划描述访问路径,这些路径是 DB2 优化器为 SQL 语句访问数据而选择的。可视化解释(Visual Explain)是查看访问计划的最简单方式,通过 DB2 Control Center 实现。db2expln 和 db2exfmt 命令用更简洁的方式提供了广泛的信息,在需要针对性能频繁分析 SQL 语句时,通常使用这两个命令。
db2expln 使用起来比 db2exfmt 稍微简单,因为您能够直接将一条语句传递给它,以进行解释。同样,使用 db2expln 更容易分析一个包中所有的静态 SQL。db2exfmt 需要已经将一条 SQL 语句解释到这些表中,并设置 EXPLAIN 表中信息内容的格式。db2exfmt 通常用于广泛的性能分析,因为它提供了大部分优化器信息。
要了解关于使用 Explain 工具的更多信息,请查阅 “IBM DB2 Database for Linux, UNIX, and Windows Information Center” 的 “Visual Explain overview”、“db2expln - SQL and XQuery Explain Command” 和 “db2exfmt - Explain table format command” 部分。
![]() |
![]() |
如果可能,将服务器专门用于运行数据库。这样,无需关心未知的额外工作负载就可以执行数据库调优。
考虑使用 DB2 的自动功能,尤其是 DB2 9 支持的 STMM,以及 DB2 Version 8 和 DB2 9 都支持的 Automatic Maintenance(尤其是自动的 runstats)。这些功能不但会减少监控和维护数据库所需的操作,也能对数据库进行更加有效的调优。
只要可能,最低限度为每个 CPU 分配 6-10 个磁盘, 而且将所有文件分散到所有可用的磁盘上(索引、数据、表空间和临时表空间)。务必考虑使用自动存储,从 DB2 Version 8.1 FP9 开始的版本都支持这项功能。始终将 DB2 日志放在与表空间隔离的磁盘,以避免关键数据库组件之间的 I/O 争用。
在应用程序部署前禁用监控,这可能节省大约 5% 的监控开销。某种程度上,在生产环境中始终打开监控功能则物有所值。当调试问题或分析性能时应该打开监控。但是,如果需要将数据库复制到十几个或者数百个设备上时,一定要在部署前关闭监控。
当对数据量或数据内容进行重大更改时,定期运行 RUNSTATS。即使表的行数保持一致,使用由 RUNSTATS 更新的统计信息来更改数据内容可以产生不同的、也许更好的访问路径。 执行 RUNSTATS 之后,包含静态 SQL 的 DB2 包应该被定期地重新绑定(通过 db2rbind 命令),以确保静态 SQL 使用了最优的访问路径。
定期运行 REORGCHK,并执行推荐的 REORGs。与 RUNSTATS 类似,当发生重大的数据更改时,应该始终运行 REORGCHK。
定期收集快照数据。快照数据能够提供缓冲池使用情况、排序堆使用情况、锁定和表读/写活动的定期视图。关于动态 SQL 活动(通过 db2 get snapshot for dynamic sql on dbname 命令来实现)和总体数据库活动(通过 db2 get snapshot for database on dbname 命令来实现)(用实际数据库名称替换 dbname)的视图都很有用。通过定期记录快照并进行分析,可以发现发生的反常活动和趋势。在探测趋势时,这种定期使用快照的方法特别有用。针对更长期的监控,可以考虑使用 SQL 表函数访问快照数据。当将数据放回到 DB2 时,存储和比较大量快照数据就容易得多了。
该工具可用于进行问题诊断以及对 DB2 中发生的事件进行一般分析。该工具也可以用来监控 DB2 日志使用情况以及 DB2 缓冲池使用情况。
DB2 编目是一个非常有价值的信息来源。建议用户通过一组 SYSCAT 模式的视图来访问编目。在 DB2 9 中,关于表的状态和使用情况的有用信息可以使用一个叫做 SYSIBMADM.ADMINTABINFO 的新视图来找到。关于 DB2 编目的更多信息请参阅 “IBM DB2 Database for Linux, UNIX, and Windows Information Center” 的 “Roadmap to the Catalog Views” 部分。
始终使用最新的 DB2 产品补丁是预防问题的一个重要步骤。制定一个定期更新 DB2 修订包应用程序的计划,即使系统中没有错误也是如此。和任何软件产品一样,DB2 并不是完美的,而且 IBM 几乎每季度都会发行修订包,以设法改善软件的可靠性。应用修订包可以主动阻止潜在的问题,也有助于最小化与 DB2 相关的应用系统的宕机时间。
![]() |
![]() |
本文提供了一些关于基础设计、实现、运行时以及可管理性的指导,以帮助您在 DB2 中实现应用程序。尽管没有提供实现这些指导的所有必须细节,但仍然希望本文为您提供了一些重要的考虑因素。您还可以利用 参考资料 部分提供的附加资源,获取有关本文内容的更深入的技术指导。
![]() |
![]() |
衷心感谢 Bill Wilkins 和 Steve Rees 对本文进行的审校工作。
![]() | ||
![]() |
Scott Martin 目前是位于 Waltham, Mass IBM Innovation Center for Business Partners 的一名 DB2 技术顾问。Scott 帮助许多 ISV 和业务合作伙伴解决 DB2 for Linux, UNIX, Windows 和 z/OS 平台上的问题,包括数据库迁移、性能分析与调优、数据库设计以及问题诊断。Scott 获得了多个 DB2 和 z/OS 认证。 Scott 以前就职于 Global Technology Services,从事应用程序开发、数据库管理、数据库设计以及数据库调优等工作。 |
![]() | ||
![]() |
Colin Meiser 已经为 IBM 工作了 9 年,是一名经过认证的 IT 架构师,他目前为 Consumer Products 行业解决方案小组工作。他拥有近 30 年的 IT 经验,过去 15 年一直从事与大型数据库和数据仓库实现相关的工作。他获得了多个 DB2 和 Business Intelligence 认证。 |
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15082138/viewspace-534775/,如需转载,请注明出处,否则将追究法律责任。