分类： DB2/Informix
2008-05-31 16:58:47
检查点
Dynamic Server 处理共享内存中的所有工作，并尽可能久地在共享内存中保留页面。这非常有效。考虑一个索引页面。假设某个人将一些行插入到页面中。如果不在共享内存中保留页面，那么每当需要修改这个索引页面时，都存在读取页面、修改页面和将它写出到磁盘所引起的额外开销。这可能需要付出很高的代价。
但是，在某些时候，数据库服务器必须将页面写回到磁盘，因为需要为其他页面腾出空间。而且，需要考虑恢复的问题。
如果引擎突然崩溃，所有工作都来不及干净地提交或回滚，那么必须采取行动使服务器恢复到一致状态。
快速恢复有两部分：
物理恢复将所有页面的原像返回到磁盘。原像是页面在被修改之前的镜像。
逻辑恢复是指前滚最近检查点中的所有事务。所有被提交的事务将被完整地重放。但是没有被提交的事务将被回滚。
检查点可以描述为磁盘与共享内存之间的一个同步点。在那个同步点，数据库服务器有一个已知的一致点。在一个检查点期间，所有缓冲区都被刷新到磁盘，使它们被稳定地存储在磁盘上。数据库服务器并不是在每个事务完成后立即将事务存储到磁盘，而是将事务存储在逻辑日志缓冲区中。
取决于使用什么类型的事务日志（有缓冲还是无缓冲），逻辑日志缓冲区被周期性地刷新到逻辑日志。
当发生检查点时，一个检查点记录也将被记录到逻辑日志中。 这被记录在备用页面中。在恢复期间，从备用页面中发现最近的检查点，以便从这个检查点开始恢复。
取决于物理日志缓冲区大小、缓冲池大小以及有多少脏缓冲区等因素，检查点可能需要一些时间完成。在 V11 之前，检查点将阻塞任何线程进入所谓的关键代码段。关键代码段是指必须一次完成的代码，例如写一个页面。这一点有时候会使用户应用程序在检查点上等待。
在 Informix Dynamic Server V11 中，这种旧的算法已经被改写。新算法据说实际上是非阻塞的。这意味着在检查点期间数据库服务器现在允许其他线程工作。
数据库服务器监视资源使用情况，并与过去的检查点性能比较。必要时，服务器将更频繁地触发检查点，以避免用完关键资源，例如物理日志。这样一来，服务器可以确保在检查点处理期间其他线程和客户机应用程序不会被阻塞。
Informix Dynamic Server V9 中引入的模糊检查点（fuzzy checkpoint）已经被摒弃。
在 V11 之前，数据库管理员常见的做法是将 LRU 刷新调得更积极，以便不断地排出 LRU。因此，检查点将更快地完成，因为要做的工作更少了，同时这也减少了其他线程等待检查点完成所需的时间。
但是，在 V11 中，不必将 LRU 刷新调得如此积极。在检查点期间事务处理不会被阻塞。将 LRU 刷新调得缓一些，可以提高事务性能。在 V11 上，通过放缓 LRU 刷新可以明显提高性能。
由于检查点现在是非阻塞的，在一个检查点事务期间，它们仍然会将信息写到逻辑日志，而原像页面仍然放在物理日志中。在一个检查点期间，引擎可能遇到以下几种情况：
这种情况下，检查点将临时地阻塞，以确保所需的资源可用。
如果物理日志满了 75%，则检查点将阻塞，以确保物理日志不会溢出。物理日志是一个循环文件，所以在物理恢复中使用那个文件时，应确保引擎知道起点和终点在哪里。
当前算法确保至少有一个检查点被写到日志中。
为了避免检查点阻塞事务处理，需要：
Informix Dynamic Server V11 引入了配置参数 RTO_SERVER_RESTART。
该参数指定数据库服务器将尝试完成恢复并回到联机或静态模式的秒数。如果出现了崩溃，需要使服务器回到联机模式，那么这个参数就很方便。
在逻辑重放的过程中，必须处理每个日志记录。在此处理中，必须从磁盘读取页面。这种 I/O 会大大降低日志重放的性能。如果不知道快速恢复的逻辑部分需要多少 I/O，就难于判断恢复需要多长时间。
为了实现这个目标，并在规定的秒数内变得可用， Informix Dynamic Server 必须管理快速恢复期间发生的 I/O 量。谓词，当配置 RTO_SERVER_RESTART 时，Informix Dynamic Server 利用物理日志以保存它认为在逻辑恢复中要用到的附加前像（before-image）。
在快速恢复的物理部分，缓冲池将自动装入从最近检查点前滚逻辑日志所需的数据页。这里不必从磁盘读页面，因为它已经在内存中，可以直接使用。
当引擎联机时，需要打开 RTO_SERVER_RESTART，以便标记那些页面，使它们在快速恢复中被填充到缓冲池中。只有在再循环之后这个优点才会实现。
启用 RTO_SERVER_RESTART 之后，数据库服务器:
CKPTINTVL
但是，启用 RTO_SERVER_RESTART 也有一些不好的地方：
最少情况下，总的逻辑空间只需大到能够包含两个检查点周期的所有事务。如果启用了 RTO_SERVER_RESTART，并且服务器有一个小于 4GB 的组合缓冲池，那么总的日志空间建议为组合缓冲池大小的 110%。
默认情况下，RTO_SERVER_RESTART 被禁用。该配置参数的取值范围如表 10 所示：
| RTO_SERVER_RESTART 设置 | 取值范围 |
|---|---|
| Off | 0 |
| On | 60-1800 |
可以通过手动地修改配置文件或者使用 onmode -wf RTO_SERVER_RESTART 以更改 RTO_SERVER_RESTART 配置参数。
RTO_SERVER_RESTART 的新值在数据库服务器停止并重新启动之后生效。
在 IDS V11 中，模糊检查点已经被弃用。因此，新的检查点算法需要更多的物理日志活动。而为 Informix Dynamic Server V7 配置的应用程序在物理日志记录活动频率方面变化不大，或者没有变化。在 V9 上运行的应用程序的物理日志记录有所增加。如果启用了 RTO_SERVER_RESTART，那么也会增加物理日志记录活动。
较大的物理日志不会影响性能。通常，常见的 1GB 到 4GB 的物理日志就足够了。
Informix Dynamic Server V11.10 的一个新特性是可以使用 onparams 实用程序，在不需要静态模式或者重新启动系统的情况下更改物理日志的大小、位置或者同时更改这两项。
检查点间接地受 LOGSIZE 和 LOGFILES 配置参数的影响。当检查一个逻辑日志文件以判断是否可以释放它时，会检查它是否包含最近的检查点。在释放一个逻辑日志文件之前，数据库服务器必须在当前逻辑日志文件中写一个新的检查点记录。当这种事情频繁发生时，会增加检查点的频率。在 V11 中，这通常不是一个重要的因素。
ONCONFIG 参数 CKPTINTVL 指定数据库服务器判断是否需要检查点的频率，单位为秒。
如果启用了 RTO_SERVER_RESTART，则 ONCONFIG 参数 CKPTINTVL 被忽略。
ONDBSPACEDOWN 配置参数指示服务器如何处理由于 I/O 错误而停用的非镜像常规数据库空间。取决于设置，在检查点期间引擎可以挂起。临时数据库空间不受 ONDBSPACEDOWN 的影响。
在 V11 之前，有四种情况可能触发检查点：
ONCONFIG 参数 CKPTINTVL 如果启用了 RTO_SERVER_RESTART，则不使用 CKPTINTVL 配置参数。这是因为最重要的是尽量跟踪恢复过程要花多少时间以维护 RTO_SERVER_RESTART_POLICY。
如果没有启用 RTO_SERVER_RESTART，则 CKPTINTVL 配置参数指定数据库服务器判断是否需要检查点的频率，单位为秒。
如果 CKPTINTVL 到期，并且还没有更新（没有东西记录到物理日志中，并且没有新的管理事件），则不会发生检查点。当页面更新或者对系统的更改很少时，通常使用较长的 CKPTINTVL 设置。当 CKPTINTVL 较大时，决定因素就成了物理日志。
但是，如果物理日志非常大，使用较长的检查点间歇期会导致快速恢复需要更多的时间。如果数据库可用性非常重要，那么当引擎崩溃时这一点影响很大。在这种情况下，建议使用 CKPTINTVL 和适当大小的物理日志。
检查点完成时，要从在线日志中读取消息。该消息还指定一个检查点要花多少时间完成。在 V11 之前，关于用户被阻塞在关键代码段之外多长时间有一个临时的规范。DBA 可以使用该信息帮助调优检查点。可以使用 onstat -m 读这些消息。
一个新的 onstat 选项（-g ckp）允许跟踪之前 20 个检查点的历史，并允许使用该信息跟踪检查点。