跟Oracle类似DB2也分为两个模式，日志循环vs归档日志，也就是非归档和归档模式，下面对这两种模式做简单的介绍。
日志循环
日志循环是默认方式，也就是非归档模式，这种模式只支持backup offline脱机备份，在备份过程中需要DB2停止服务。
运行脱机备份需要如下注意的地方：
1，停止应用对DB2的访问。
2，通过LIST APPLIACATIONS命令查看现有的连接，然后通过FORCE APPLIACATION命令来结束连接。
3，通过DEACTIVATE DATABASE 命令来确保数据库未处于活动状态。
4，通过BACKUP DATABASE命令来对数据库进行备份。
归档日志
归档日志不是默认状态，需要配置后才会起作用，DB2在使用日志保留模式的时候数据库是可恢复的数据库，支持在线备份、前滚恢复和崩溃恢复。
配置DB2进入归档日志模式主要是靠Logarchmeth1和Logarchmeth2两个参数（注：Logretain参数在DB2 v8以后已经被Logarchmeth1取代，可以不用管）。
Logarchmeth1设置为LOGRETAIN
使用归档日志，数据库是可恢复的数据库。启用前滚恢复和崩溃恢复，但是非自动归档模式。
归档日志文件之后，必须人工将无用的归档日志删除，以便新的日志文件可以复用磁盘空间。每当日志文件已满，DB2 就开始将记录写至另一个日志文件，并且不断创建新日志文件。
Logarchmeth1设置为除OFF 或LOGRETAIN以外的值
使用归档日志。数据库是可恢复的数据库。启用前滚恢复和崩溃恢复。当日志文件满时，自动对它进行归档，归档的目的地就是Logarchmeth1设置的位置。
如果在归档日志文件时发生错误，归档暂挂一段时间，此时间由ARCHRETRYDELAY数据库配置参数指定。还可以使用NUMARCHRETRY 数据库配置参数来指定 DB2 尝试将日志文件归档到主要或辅助归档目录的次数，然后它再尝试将日志文件归档到故障转移目录（由 FAILARCHPATH 数据库配置参数指定）。
Logarchmeth1和Logarchmeth2配置可能有如下几种组合
1，Logarchmeth1设置为LOGRETAIN，Logarchmeth2只能设置为OFF
归档日志位置就是DB2数据库日志的位置，需要人工干预归档日志的转移和空间维护工作
2，Logarchmeth1设置为USEREXIT，Logarchmeth2只能设置为OFF
归档日志的管理交由USEREXIT来处理，通过设置编译USEREXIT可以实现相对复杂一些的归档管理方式
3，Logarchmeth1设置为<Directory>，Logarchmeth2设置为OFF
归档日志的工作将会自动进行，需要归档日志将会被自动归档到<Directory>指定的位置，由于归档是自动进行，DB2的日志目录中只有正常logprimary＋logsecond个数据库日志。
4，Logarchmeth1设置为<Directory1>，Logarchmeth2设置为<Directory2>
归档日志的工作将会自动进行，需要归档日志将会被自动归档到<Directory1>和<Directory2>指定的位置，也就是会产生两份归档日志由于归档是自动进行，DB2的日志目录中只有正常logprimary＋logsecond个数据库日志。
<Directory1>或者<Directory2>都可以设置为TSM。一般推荐<Directory1>为文件系统，<Directory2>设置为TSM，既可以归档到TSM离线保存，又可以在线使用文件系统中归档日志，比较方便。
注意：设置Logarchmeth1和Logarchmeth2后，数据库会进入backup pending状态，必须进行一次脱机备份，数据才会进入recovery模式并且正常工作。
其他常用的日志设置参数
1，故障转移归档路径（failarchpath）
如果指定的日志归档方法失败，则为归档日志文件指定备用目录。在失败的日志归档方法再次可用之前，此目录是日志文件的临时存储器，此时日志文件将从此目录中移至日志归档方法。通过将日志文件移动至该临时位置，可以避免日志目录发生已满情况。此参数必须是一个标准现有目录。
如果用tsm作为归档目的，这个参数比较必要，当tsm出现问题不能接收归档文件数据的时候，这个可以救急，以免数据库挂起。
2，日志文件大小（logfilsiz）
此参数以 4 KB 的页数指定每个配置日志的大小。
如果logfilsiz太小会引起频繁的日志切换和归档，而且遇到大事务的时候 （logprimary＋logsecond）× logfilsiz 不足装下所有内容的时候，该事务会失败回滚。
3，每个事务的最大日志数（max_log）
此参数指示一个事务可以消耗的主日志空间的百分比。该值是为 logprimary 配置参数指定的值的百分比。
如果该值设置为 0，则对一个事务可以消耗的总的主日志空间的百分比没有限制。如果应用程序违反了 max_log 配置，则将强制该应用程序与数据库断开连接，事务将被回滚，并且将返回错误 SQL1224N。
如果对事务大小无法估计，一般都设置为0，避免意外回滚发生。
4，主日志（logprimary）
此参数指定将创建的大小为 logfilsiz 的主日志数。 默认为3
主日志，无论是空的还是满的，都需要相同的磁盘空间容量。因此，若配置的日志多于需要的日志，将会不必要地占用磁盘空间。若配置的日志太少，可能会遇到日志满载的情况。当选择要配置的日志数时，必须考虑建立的每个日志的大小，以及应用程序是否可以处理日志满载的情况。对活动日志空间的总日志文件大小限制为 256 GB。
5，辅助日志（logsecond）
此参数指定创建并用于恢复（如果需要的话）的辅助日志文件的数目。 默认为2
如果主日志文件已满，可按需要一次分配一个辅助日志文件（大小为 logfilsiz），最多可分配由此参数指定的最大数目。如果此参数设置为 -1，则将数据库配置为无限活动日志空间。对在数据库上运行的未完成事务的大小或数量没有任何限制。在必须容纳大型作业的环境中（这些作业需要的日志空间比通常分配给主日志的空间多），无限活动日志记录功能非常有用。
DB2 数据库支持两种不同的日志模式：循环(Circular)和归档(Archival)。当新数据库创建时，系统默认的日志模式为循环。如果业务需求要求更高级的功能，您可以将日志模式从循环修改为归档。
DB2 将一直尝试将日志条目写入主要日志文件集，也就是数据库活动时间自动分配的日志文件。如果某个事务将所有主要日志文件消耗怠尽(所有主要日志文件都被标记为 unavailable)，则数据库管理员将分配一个次要日志文件。当这个文件变满时，数据库管理员将再次检查主要日志文件的状态是否为 unavailable。如果是，则再分配一个次要日志文件并继续在其中写入条目。该过程将不断重复，直到所有次要日志文件都分配并写满。如果没有主要日志文件可供写入 Redo 条目，并且已经分配最大数量的次要日志文件，则应用程序将收到以下错误消息：
SQL0964C The transaction log for the database is full.
希望您曾经遇到过这种错误。但是，如果遇到此错误，则应该根据需要增加主要和次要日志文件(或者它们的大小)的数量。在理想情况下，主要日志文件的数量或大小应该足够保存最大的事务。分配次要日志文件相当消耗资源，因为它将在运行时执行。因此，我们应该将需要在高峰工作负荷期间分配的次要日志文件数量降到最低。要更新主要或次要日志文件的数量，可以发起以下命令：
UPDATE DB CFG FOR db_name USING LOGPRIMARY value
UPDATE DB CFG FOR db_name USING LOGSECOND value
注意：如果出现此问题，则应该分析造成整个日志文件空间变满的原因是什么。它可能是由失控查询或用户错误造成的，因此增加日志文件的数量或大小只能在表面上解决问题。比如说，假设某个用户发起了一个 DELETE FROM tab1 语句，且 TAB1 是一个相当大的表。虽然这一语句看上去没什么问题，每行生成一条删除日记记录，但是如果未经过配置处理它可以轻易地将日志空间填满。
循环日志
当循环日志生效时，事务数据将通过循环的方式写入主要日志文件。当存储于某个日志文件中的所有记录都不再需要用于恢复时，该日志文件将被重用，并且可以在以后再次成为活动日志文件。这意味着在循环日志模式中，日志文件的内容最终将被新日志条目重写。由于日志文件的内容被重写覆盖了，因此我们只能将数据库恢复到最后一次完整的数据库备份。不能使用循环日志执行时间点(point-in-time)恢复。
归档日志
在归档日志模式中，redo log 条目将写入主要日志文件。但是，与循环日志不同，这些日志文件永远都不可重用。当存储于某个日志文件中的所有记录都不再需要用于恢复时，该日志文件将被标记为非活动 而不是可重用。这意味着它的内容永远都不会被覆盖。当第一个主要日志文件变满时，系统将分配一个新的日志文件，这样主要日志文件的配置数量(LOGPRIMARY 数据库参数)将一直可用。
与单个事务相关的所有条目必须在活动日志空间中保持一致。如果长时间运行的事务所需要的日志空间大于主要日志文件可以提供的空间，则可能会分配并使用次要日志文件。在归档日志模式中，通过结合使用数据库备份映像和日志文件，我们可以将数据库恢复到具体的时间点。有关此流程的详细描述请参见下文。
何修改日志模式
创建新的 DB2 数据库时，默认的日志模式为循环日志 。如果希望将日志模式从循环修改为归档，可以执行以下步骤：
在磁盘上创建一个文件夹(比如说 e:db_namearchive)，磁盘上必须有足够的空间存储归档日志文件。保证归档文件目标文件夹与活动日志文件目标文件夹分开。
终止与数据库的连接：
TERMINATE
更新归档日志文件目标文件夹(为归档日志文件指定路径可以将归档日志模式打开)。
UPDATE DB CFG FOR db_name USING LOGARCHMETH1 "Disk:e:db_namearchive"
重新连接到数据库：
CONNECT TO db_name
连接失败并显示以下错误消息：
SQL1116N A connection to or activation of database db_name cannot be made because of backup pending: SQLSTATE=57019
出现错误消息的原因是，日志模式已经从循环更改为归档，并且需要执行完全数据库备份。数据库处于循环日志模式时执行的备份并不充分，因此当切换模式后需要执行新备份。
使用以下命令执行完全数据库备份：
BACKUP DATABASE db_name TO d:db_nameackup
尝试再次连接到数据库。这次应该能够成功。
CONNECT TO db_name
事务是逻辑工作单元。每一个事务在事务日记文件中都存储有相应的日志记录。每个事务都有一个相应的 Redo Log 条目。Redo Log 条目将写入当前的活动日志文件。当活动日志文件变满时，它将被标记为 unavailable。此时，DB2 将接着此活动日志文件另外创建一个日志文件，并继续在其中写入日志条目。当前活动日志文件变满时，DB2 将重复这一循环过程。当事务完成后(发起 COMMIT 或 ROLLBACK 语句)，相应的日志条目将被释放，因为不再需要将它们用于恢复数据库。