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

最小化死锁

在整个应用程序中，总是按相同次序访问资源可以最小化死锁。例如，如果一个应用程序组件将要访问表 A，然后是表 B，接着是表 C，而另一个应用程序组件需要访问表 A 和 C，那么第 2 个组件应该遵循先 A 后 C 的访问次序。

对于 DB2 Version 8，导致死锁的一个常见原因是锁列表数据库配置参数的大小不足，尤其是使用默认值时。请参阅本文的 最大化并发性 小节。如果出现这种情况，增加锁列表大小就可以解决问题。默认情况下 DB2 9 使用了 STMM，它会调整锁列表大小以避免可能由此引起的锁升级和死锁。

确保参照完整性（referential integrity，RI）关系中的依赖表拥有与外键匹配的索引。

利用连接池

利用连接池，包括由应用服务器管理的连接池，如果不在应用服务器环境中运行，则使用由应用程序管理的连接池。打开和关闭连接的过程开销较大，会影响到应用程序或数据库的性能，而使用连接池就可以消除大部分这样的开销。

如果使用了大量的连接，那么请使用 DB2 的连接集中器（connection concentrator）功能。该功能只允许较少的 DB2 “后端” 连接为应用程序连接服务，从而节省了内存。

动态或静态 SQL 选择

现在，动态 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” 部分。

最小化 DB2 语句的 PREPARE 成本

只需在 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

通过使用一些基本原则，可以更有效地使用 JDBC。首先，确保已经针对列数据类型使用恰当的 setxxx 方法将数据绑定到参数标记。这会避免数据类型转换开销过高和可能的 SQL 数据类型失配错误。其次，尽可能避免使用可滚动的结果集设置，因为服务器会实现临时表来支持这种设置。使用这种设置会影响到性能，尤其是使用大的结果集设置时。