针对基础设计、性能和可管理性的DB2最佳实践

核心提示：避免 I/O 瓶颈只要可能，最低限度为每个 CPU 分配 6-10 个磁盘，针对基础设计、性能和可管理性的DB2最佳实践(5)， 而且将所有文件分散到所有可用的磁盘上（索引、数据、表空间和临时表空间），务必考虑使用自动存储，以帮助您在 DB2 中实现应用程序，尽管没有提供实现这些指导的所有必须细节，从 DB2 Vers

避免 I/O 瓶颈

只要可能，最低限度为每个 CPU 分配 6-10 个磁盘， 而且将所有文件分散到所有可用的磁盘上（索引、数据、表空间和临时表空间）。务必考虑使用自动存储，从 DB2 Version 8.1 FP9 开始的版本都支持这项功能。始终将 DB2 日志放在与表空间隔离的磁盘，以避免关键数据库组件之间的 I/O 争用。

考虑在部署前关闭监控

在应用程序部署前禁用监控，这可能节省大约 5% 的监控开销。某种程度上，在生产环境中始终打开监控功能则物有所值。当调试问题或分析性能时应该打开监控。但是，如果需要将数据库复制到十几个或者数百个设备上时，一定要在部署前关闭监控。

RUNSTATS 命令很有用

当对数据量或数据内容进行重大更改时，定期运行 RUNSTATS。即使表的行数保持一致，使用由 RUNSTATS 更新的统计信息来更改数据内容可以产生不同的、也许更好的访问路径。 执行 RUNSTATS 之后，包含静态 SQL 的 DB2 包应该被定期地重新绑定（通过 db2rbind 命令），以确保静态 SQL 使用了最优的访问路径。

REORGCHK 命令也能提供帮助

定期运行 REORGCHK，并执行推荐的 REORGs。与 RUNSTATS 类似，当发生重大的数据更改时，应该始终运行 REORGCHK。

收集快照数据

定期收集快照数据。快照数据能够提供缓冲池使用情况、排序堆使用情况、锁定和表读/写活动的定期视图。关于动态 SQL 活动（通过 db2 get snapshot for dynamic sql on dbname 命令来实现）和总体数据库活动（通过 db2 get snapshot for database on dbname 命令来实现）（用实际数据库名称替换 dbname）的视图都很有用。通过定期记录快照并进行分析，可以发现发生的反常活动和趋势。在探测趋势时，这种定期使用快照的方法特别有用。针对更长期的监控，可以考虑使用 SQL 表函数访问快照数据。当将数据放回到 DB2 时，存储和比较大量快照数据就容易得多了。

了解如何使用 db2pd 工具

该工具可用于进行问题诊断以及对 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 修订包应用程序的计划，即使系统中没有错误也是如此。和任何软件产品一样，DB2 并不是完美的，而且 IBM 几乎每季度都会发行修订包，以设法改善软件的可靠性。应用修订包可以主动阻止潜在的问题，也有助于最小化与 DB2 相关的应用系统的宕机时间。

结束语

本文提供了一些关于基础设计、实现、运行时以及可管理性的指导，以帮助您在 DB2 中实现应用程序。尽管没有提供实现这些指导的所有必须细节，但仍然希望本文为您提供了一些重要的考虑因素。