通常，对数据库cfg parm LOGFILSIZ的更改要求干净地将数据库退回（DEACTIVATE / ACTIVATE），这意味着没有正在进行中的交易/未打开的交易（例如，没有不确定的交易或通过DB2_ONLINERECOVERY进行的异步撤消）。
知道存在任何形式的数据库恢复（例如崩溃恢复），数据库前滚或HADR备用重播时，可以采取特殊处理。
LOGFILSIZ是存储在数据库cfg级别上并且也内部存储在数据库目录下的GLFH中的那些数据库cfg参数之一。GLFH值用于所有数据库激活以及整个数据库恢复操作。当您更新数据库cfg值时，它会挂起，直到下一次干净激活为止，在此之后我们将更新GLFH值以匹配数据库cfg值。
下面将概述数据库恢复操作的处理：
崩溃恢复
由于数据库崩溃，我们知道数据库已经处于活动状态，因此LOGFILSIZ更改已经发生或正在等待更改。因此，所有崩溃恢复将基于GLFH值处理一个恒定的日志文件大小，并且在崩溃恢复的重做或撤消阶段将不会发生任何变化。崩溃恢复的撤消阶段完成后，我们通常会保持数据库正常运行。
如果有尚未解决的挂起的LOGFILSIZ更改，那么在完成崩溃恢复之前，我们会问一个问题：“是否有正在进行中/未完成的事务？”。如果没有，那么我们将提取所有挂起的日志记录数据库cfg参数更改，包括LOGFILSIZ并更新GLFH值。如果有任何进行中/未完成的事务，则挂起的数据库cfg parm将保持挂起状态，直到数据库的下一次完全激活为止。
数据库前滚
我称数据库为前滚，盲目重播。那是因为我们从过去开始，盲目向前前进，并不完全知道接下来会看到什么。因此，数据库前滚由它在需要重播日志数据的每个日志文件中看到的日志文件大小决定。因为我们知道日志文件大小的更改只能在完全激活的情况下发生，所以我们知道在我们要以新的日志文件大小重播第一条日志记录时不存在运行中/打开的事务。检测到此错误后，我们将恢复重播位置上移到该第一条日志记录，并更新GLFH值。我们多次重复此操作，以查看具有不同日志文件大小值的日志文件。
在数据库前滚结束时，数据库被停用。下次激活时，如果没有不确定的事务，并且LOGFILSIZ数据库cfg值与GLFH中的值不同，则我们更新GLFH值以匹配数据库cfg值。如果存在不确定的事务，那么我们将开始崩溃恢复，并且LOGFILSIZ更改将保持挂起状态。
HADR备用重播
在HADR环境中，备用数据库就像是试图保持同步的主数据库的镜像。但是，Db2不会重播在主数据库上完成的数据库cfg更新。用户负责在两侧发布UPDATE DB CFG命令，以确保它们在任何接管情况下都匹配。是的，我知道人们对此表示讨厌，而且有开放的 RFE为此，但这是截至11.5的当前流程。
在主服务器上进行更新时，在停用并彻底激活后，新的日志文件大小将影响主服务器。届时，具有新大小的日志文件将被传送到备用数据库。备用数据库将接收这些日志文件，因为它知道干净的激活已完成，它将看到新的大小，备用数据库将开始以新的大小预分配新的空文件。然后，当备用重放在日志文件中看到具有新大小的第一条日志记录时，就像数据库前滚一样，我们将更新 恢复重播位置到此第一条日志记录并更新GLFH值。
我们多次重复此操作，以查看具有不同日志文件大小值的日志文件。现在，备用数据库上发生了接管。由于此角色从备用更改为主要，因此数据库一直处于激活状态，因此GLFH值暂时占主导地位。但是，一旦这个新的主数据库停用并重新激活干净，数据库的cfg值将与GLFH值进行比较，任何差异都将导致GLFH值被更新。
因此，故事的寓意是在主数据库上发布UPDATE DB CFG LOGFILSIZ时，最好尝试同时在备用数据库上执行相同的操作以准备接管。但是，在重播模式下，对重播没有影响。
