使用内存盘提高OLTP数据库的性能和可用性（2）使用内存盘提高数据库性能-2

look_w

使用内存盘保存日志  在一些大型的应用系统上，数据库的数据可能会达到几百个 G 甚至更多。此时，使用内存盘保存整个数据库不太可行。但是，把读写频繁的日志文件建立在内存盘上，不但可以提高数据库的访问速度、增加磁盘寿命，还可以为高可用性配置提供便利。本部分描述，如何把日志文件单独存放在内存盘上。
用户在决定将日志文件存放在内存盘之前，首先需要计算日志文件的大小。运行时，当所有的活动日志文件被写满，尚未完成的事务就会失败，并被 rollback。因此，用户应保证日志的大小满足日常操作的要求。这需要考虑在通常情况下需要的日志大小，以及在两种极端情况需要的日志大小。这两种极端情况是：

• 在应用程序最繁忙的时候，这时并发的应用最多，但是每个应用占用的日志大小相对较小。此时，应通过实验，得出平均每个事务占用的日志数，并乘以并发的应用的个数。
• 在执行批量操作时，此时往往是业务不太繁忙的时候，但是执行批量操作的应用，往往会在一个事务中执行较多的操作。因此，往往需要占用相当大的日志文件。这种情况下，可以通过修改应用程序，强制应用在每执行几万到几十万个操作就执行一次 commit 或 rollback。这种控制一次提交数量的方法，还可以同时提高应用程序的效率。

在 DB2 数据库中，活动日志分为主要日志 (primary) 和次要日志 (second)。DB2 数据库的主要日志文件，会在数据库被“激活”的同时建立。这通常发生于第一次 connect 时 ( 有时用户可能会被第一次链接的漫长时间折磨的发狂，内存盘有治疗这种狂躁症的功效 J)。数据库运行时主要日志文件会被循环使用。通常设定主要日志文件的大小应满足绝大多数应用，在绝大多数时间的要求。
当未结束的事务将主要日志文件占满，数据库就会启用次要日志文件。次要日志文件也会被循环使用。所有的活动日志文件 ( 主要日志文件和次要日志文件 ) 一旦被分配就不会释放，直到数据库退出。因为，活动日志大小不够时，可能引起事务回滚，因此在实际业务系统上，次要文件往往被设置的足够大。但如果要使用内存盘作为活动日志目录，用户就要考虑在满足业务需求的前提下，尽量减小次要日志文件的大小。即使配置了溢出日志路径 (overflowlogpath)，也是如此。
根据主要和次要日志的大小，用户可以选择内存盘的大小，并通过修改 NEWLOGPATH 参数，为日志文件指定存放目录。( 修改这个参数后，需要重新启动数据库才能生效。)
db2 update db cfg using NEWLOGPATH /db2data/log
当用户把日志文件放在内存盘后，日志缓冲区的作用会减小。因此，用户可以通过将日志缓冲区设置为较小的值，以节约内存。
db2 update db cfg using LOGBUFSZ 256
配置参数  在做过一些测试以后，用户可能会发现，单纯使用内存盘提高效率并不明显。这是因为许多数据库默认的参数，并不适合使用内存盘的情况，因此需要对许多参数进行配置，以提高性能，同时避免过度使用内存。
在了解如何进行配置前，用户首先需要了解 DB2 数据库的内存分配。下图描述了 DB2 如何进行内存分配。用户可以从 DB2 Information Center 中找到 DB2 进行内存分配的更详细的描述。
图 3。DB2 的内存分配   需要注意的是，在有的 Linux 系统上，内存盘占用的内存，不是在 mkfs 或 mount 时一次性分配的。在数据库运行期间，随着数据的写入，内存盘占用的内存会逐渐增大。此时，如果将 DB2 自动调整内存的功能打开，那么在业务高峰时，会导致内存盘和 DB2 数据库管理器争抢内存。因此，强烈建议用户关闭数据库的自调整内存功能，并对数据库的参数进行手动的调节。
db2 update db cfg using SELF_TUNING_MEM OFF
在进行参数调节时以下几个要点需要特别注意：

• 因为，内存盘的速度比磁盘的速度快很多，因此通过配置大 Bufferpool 来提高数据读写速度的方法，作用很小。但是，需要注意的是，数据库仍要把数据读入 Bufferpool，才能对其操作。因此，Bufferpool 至少要能容下所有未完成的事务和未完成的查询所要占用的数据页。用户应在业务高峰或进行最密集的批量操作时，通过实验确定 Bufferpool 的大小。
• 当数据库建立在磁盘上时，因为磁盘和内存速度的巨大差距，因此需要对 SQL 语句进行精致而复杂的优化。如果使用内存盘，这个优化过程就显的复杂而不必要。可以将 SQL 语句的优化等级降低为 3 或 2。( 对使用 XML 的用户，仍建议使用默认的优化级别 )db2 update db cfg using DFT_QUERYOPT 3
• 使用内存盘创建的数据库，因为所有的读写操作，实际上都仅在内存中进行，所以建立多个 Index 对写入速度的影响，明显减小。但是，Index 对读操作的效率提升仍然有效。基于这个特性，用户可以考虑适当多建一些 Index。
• 考虑合适的 runstats 时机。使用内存盘以后，对 runstats 有 2 个方面的影响。一方面，因为读写速度加快，对 runstats 的要求减低，这样可以减少 runstats 的运行频率。另一方面，因为运行 runstats 的速度更快，因此用户可以更频繁的运行 runstats。因此，用户应重新考虑 runstats 运行的时机。
• 使用内存盘创建的数据库，其数据的读写速度，与其在内存盘上所在的位置无关。因此，使用 reorg 提升速度的效果非常微弱。但是，数据库仍需要使用 reorg 来释放被删除的数据占用的空间。因此，用户需要根据内存盘的大小和数据的多少决定 reorg 的时机，而不是为了提高速度进行 reorg。
• 使用内存盘以后，数据库同时并发的事务可以得到很大提高。但是，任何一个并发的应用都需要占用一定的内存。过多的并发还会使 locklist 占用的内存增加，并增加锁等待的概率。因此，用户需要谨慎的根据服务器内存的数量和业务的需要，来确定允许的并发访问的数量，防止因为过多的并发带来的各种问题。
• 使用内存盘以后，主要的瓶颈不再是磁盘 IO。因此根据 CPU 数目，建立多 partition 的数据库，将有效提高读写速度。同时，修改并行相关的参数，提高并行度，也有助于提高读写速度。
• 如果建立多 partition 的数据库，那么建立多个内存盘，保证每个 partition 都访问一个盘。同时也为日志指定单独的内存盘。这样对提高效率是有帮助的。
• 对仅使用内存盘保存日志的用户，写操作时的主要瓶颈会由日志，转化到对表空间的读写上。适当增加 Bufferpool 可以减少对表空间的读写频率。
• 应谨慎修改 sort 和 join 相关的参数，保证尽可能的使用 HASH join。