分类：
2008-04-14 13:12:43
| 来源：数据库用户 |
|
一般来说，对于批量插入，您会希望积极地进行 异步页清除（asynchronous page cleaning），这样在缓冲池中就总有可用于新页的空余位置。页清除率，或者说总缺页率，可能导致计时上的很大不同，使得性能比较容易产生误解。例如，如果使用 100,000 页的缓冲池，并且不存在页清除，则批量插入在结束前不会有任何新的或更改过的（“脏的”）页写到磁盘上，但是随后的操作（例如选择，甚至乎关闭数据库）都将被大大推迟，因为这时有至多 100,000 个在插入时产生的脏页要写到磁盘上。另一方面，如果在同一情况下进行了积极的页清除，则批量插入过程可能要花更长的时间，但是此后缓冲池中的脏页要少一些，从而使得随后的任务执行起来性能更佳。至于那些结果中到底哪个要更好些，我们并不是总能分得清，但是通常来说，将所有脏页都存储在缓冲池中是不可能的，所以为了取得最佳性能，采取有效的页清除是有必要的。
为了尽可能好地进行页清除：将 CHNGPGS_THRESH 数据库配置参数的值从缺省的 60 减少到 5 这么低。这个参数决定缓冲池中脏页的阈值百分比，当脏页达到这个百分比时，就会启动页清除。
尝试启用注册表变量 DB2_USE_ALTERNATE_PAGE_CLEANING（在 DB2 V8 FixPak 4 中最新提供）。通过将这个变量设置成 ON，可以为页清除提供一种比缺省方法（基于 CHNGPGS_THRESH 和 LSN 间隙触发器）更积极的方法。我没有评测过其效果。请参阅 FixPak 4 Release Notes 以了解这方面的信息。确保 NUM_IOCLEANERS 数据库配置参数的值至少等于数据库中物理存储设备的数量。
至于 I/O 本身，当需要建立索引时，可以通过使用尽可能大的缓冲池来将 I/O 活动减至最少。如果不存在索引，则使用较大的缓冲池帮助不大，而只是推迟了 I/O。也就是说，它允许所有新页暂时安放在缓冲池中，但是最终仍需要将这些页写到磁盘上。
当发生将页写到磁盘的 I/O 时，通过一些常规的 I/O 调优步骤可以加快这一过程，例如：
将表空间分布在多个容器（这些容器映射到不同磁盘）。
尽可能使用最快的硬件和存储管理配置，这包括磁盘和通道速度、写缓存以及并行写等因素。
避免 RAID5（除非是与像 Shark 这样有效的存储设备一起使用）。
5. 锁
缺省情况下，每一个插入的行之上都有一个 X 锁，这个锁是在该行创建时就开始有的，一直到 insert 被提交。有两个跟 insert 和锁相关的性能问题：
为获得和释放锁而产生的 CPU 开销。
可能由于锁冲突而导致的并发问题。
对于经过良好优化的批量插入，由获得每一行之上的一个 X 锁以及后来释放该锁引起的 CPU 开销是比较可观的。对于每个新行之上的锁，惟一可以替代的是表锁（DB2 中没有页锁）。当使用表锁时，耗时减少了 3%。有 3 种情况可以导致表锁的使用，在讨论表锁的缺点之前，我们先用一点时间看看这 3 种情况：
运行 ALTER TABLE LOCKSIZE TABLE。这将导致 DB2 为随后使用该表的所有 SQL 语句使用一个表锁，直到 locksize 参数改回到 ROW。
运行 LOCK TABLE IN EXCLUSIVE MODE。这将导致表上立即上了一个 X 锁。注意，在下一次提交（或回滚）的时候，这个表将被释放，因此，如果您要运行一个测试，测试中每 N 行提交一次，那么就需要在每次提交之后重复执行 LOCK TABLE。
使用缺省锁，但是让 LOCKLIST 和 MAXLOCKS 数据库配置参数的值比较小。当获得少量的行锁时，行锁就会自动地逐渐升级为表锁。
当然，所有这些的缺点就在于并发的影响：如果表上有一个 X 锁，那么其他应用程序除非使用了隔离级别 UR（未提交的读），否则都不能访问该表。如果知道独占访问不会导致问题，那么就应该尽量使用表锁。但是，即使您坚持使用行锁，也应记住，在批量插入期间，表中可能存在数千个有 X 锁的新行，所以就可能与其他使用该表的应用程序产生冲突。通过一些方法可以将这些冲突减至最少：
确保锁的升级不会无故发生。您可能需要加大 LOCKLIST 和/或 MAXLOCKS 的值，以允许插入应用程序有足够的锁。对于其他的应用程序，使用隔离级别 UR。
对于 V8 FixPak 4，或许也可以通过 DB2_EVALUNCOMMITTED 注册表变量来减少锁冲突：如果将该变量设置为 YES，那么在很多情况下，只能获得那些符合某个谓词的行上的锁，而并不是获得被检查的所有行上的锁。
发出一个 COMMIT 命令以释放锁，因此如果更频繁地提交的话就足以减轻锁冲突的负担。 |
