大家好，又见面了，我是你们的朋友全栈君。
0：前言
DB2日志是以文件的形式存放在文件系统中，分为两种模式：循环日志和归档日志。当创建新数据库时，日志的缺省模式是循环日志。在这种模式下，只能实现数据库的脱机备份和恢复。如果要实现联机备份和恢复，必须设为归档日志模式。
在 DB2 UDB 中，脱机备份也是最简单的备份。脱机备份要求采取完全数据库备份，显然，在备份的过程中，数据库是脱机的。换言之，当执行脱机备份时，用户无法访问数据库。
如果您正在使用循环日志记录，脱机备份是惟一受支持的备份类型。
当首先创建一个数据库的时候，这是默认的日志记录方法。对于循环日志记录，log retain for recovery status 和 user exit for logging status 都被设为 NO。LOGRETAIN 和 USEREXIT 两个参数都被设为 OFF。
Log retain for recovery status = NO User exit for logging status = YES Log retain for recovery enabled (LOGRETAIN) = OFF User exit for logging enabled (USEREXIT) = OFF
目前在综合业务系统中，设置的均是归档日志模式；其它系统（如事后监督、经营决策、中间业务等）一般都设置为循环日志模式。至于采用何种模式，可以通过修改数据库配置参数（LOGRETAIN）来实现：
归档日志模式：db2 update db cfg for using logretain on
注：改为on后，查看数据库配置参数logretain的值时，实际显示的是recovery。改变此参数后，再次连接数据库会显示数据库处于备份暂挂（BACKUP PENDING）状态。这时，需要做一次对数据库的脱机备份（db2 backup db ），才能使数据库状态变为正常。 循环日志模式：db2 update db cfg for using logretain off
一.日志概述
任何数据库管理系统都必须拥有确保数据一致性和可恢复性的机制。关系数据库系统为确保那些非常重要的特性所使用的众多机制之一是事务性日志记录。在本文中，我们将定义和讨论事务性日志记录的类型，及如何分配日志文件、如何存储它们。 数据库存储了供应用程序访问和处理的数据。那些应用程序会插入、读取、更新或删除数据。每一个这样的活动都是在一个事务中执行的，该事务被 定义成“应用程序过程中一个可恢复的操作序列”。除非已经提交了事务（也称作“工作单元”），否则它不会影响数据库。 将数据库操作组合到事务中只是确保数据一致性解决方案的一半。另一半是称作预写式日志记录（write-ahead logging）的数据库管理器实现。不管事务是否被提交，只要它们发生，就会记录这些事务。在将任何数据从缓冲池写到数据库结构之前，事务会从日志缓冲区（log buffer）写到 日志文件（事务性日志记录）。用于记录事务的文件叫做 事务日志 。
二.日志分类
DB2 UDB 有两种可用的日志记录类型 — 循环（circular）日志记录和 归档（archive）日志记录。其中归档日志又分为联机归档日志和脱机归档日志。
2.1循环日志记录
循环日志记录是数据库使用的缺省日志记录策略。在此策略中，一旦日志目录中最后一个主日志文件被写满了，就会将新的事务写到第一个日志文件中，从而覆盖现有的日志数据。这些新事务会继续依次覆盖每个旧日志文件。这种日志记录方法确保了所有已提交事务的数据一致性，这样就可以执行应急恢复。 循环日志记录通常在数据仓库环境中使用，在该环境中，恢复数据库需要的只是恢复数据库映象的问题。该策略不应该用在线事务处理（on-line transaction processing，OLTP）环境，因为它不可能进行前滚恢复。
2.2归档日志记录
与循环日志记录相比，当最后一个日志文件写满时，归档日志记录过程会创建一个新的日志文件，这样将来的事务就不会覆盖现有的日志文件。当初始化数据库时，系统会在活动日志目录中分配一定数量、指定大小的主日志文件。这个数量由数据库配置参数控制。当主日志文件都写满时，就会“根据需要”创建辅助日志文件，直到创建了最大数量的辅助日志文件为止。一旦达到了这个数量，如果需要附加的日志空间，就会发出一个错误，指出没有更多的可用日志文件，所有数据库活动停止。 利用归档日志记录，就可能采取联机(在线)数据库备份，在执行这一操作期间，会继续记录数据库活动。如果数据库崩溃或发生故障，就会使用全备份映象，然后执行使用归档日志的前滚操作，通过前滚到日志结尾，将数据库恢复到时间点状态或最近的一致状态，从而恢复数据库。 有两种归档日志： 联机归档日志: 活动日志中所有改动对正常处理已不需要，即该日志中所记录的事务都已提交并写入数据库文件时，该活动日志转换为联机归档日志。称之为联机，是由于它们与活动日志存放在同一个目录下。 脱机归档日志: 将联机归档日志从活动日志目录下Copy到另外的地方存档，就称为脱机归档日志。这些日志可能在数据库前滚恢复的时候仍然需要。
三．日志相关参数
我们只有弄清楚了日志相关的参数之后，才能正确修改配置参数，得到我们想要的日志管理模式，现对各参数介绍如下：
3.1 LOGRETAIN
缺省情况下，logretain的值为OFF，此时采用循环日志记录方式，将其修改为ON/ RECOVERY时，采用归档日志记录方式，从而允许数据库管理器使用前滚恢复方法，可以进行在线备份。该参数使归档日志保留在数据库日志路径目录中。当启用了 logretain配置参数时，就不需要启用 userexit 。这两个参数中的任何一个都足以允许前滚恢复方法。
以下是 logretain的有效值： No（缺省值）— 表示不保留日志。 Recovery — 表示保留日志，且可以用于前滚恢复。此外，如果您使用数据复制，CAPTURE 程序可以将日志中所记录的更新写到更改表。 Capture — 表示只保留日志，这样 Capture 程序可以将更新写到更改表。如果没有裁剪这些日志，那么它们可以用于正向恢复。注：通常仅当为了数据复制而设置数据库时，才使用 Capture 设置。 如果 logretain设置成“Recovery”或者 userexit设置成“Yes”，将保留活动日志文件，而且这些文件将变成联机归档日志文件，以便在前滚恢复中使用。这称为日志保留记录。 在将 logretain设置成“Recovery”和／或将 userexit设置成“Yes”之后，必须对数据库进行完全备份。这一状态由 backup_pending标志参数表示。 如果 再logretain设置成“No”并且 userexit也设置成“No”，就不能对数据库执行前滚恢复，而且可恢复性仅限于最新的数据库备份。在这种情况下，数据库管理器会删除 logpath目录中的所有日志文件（包括联机归档日志文件），分配新的活动日志文件，并且回复到循环日志记录。 当 logretain设置成“Capture”时，在 Capture 程序完成时，它会调用 PRUNE LOGFILE 命令来删除日志文件。虽然如果不裁剪日志，这些日志就可以用于正向恢复，但如果您想要确保可以对数据库执行前滚恢复，就不应该将 logretain设置成“Capture”。 当 logretain配置参数设置成“RECOVERY”时，日志文件将保留在活动日志路径中。活动日志路径由数据库配置文件中的“日志文件路径（Path to Log Files）（ logpath）”或“更改的日志文件路径（Changed Path to Log Files）（ newlogpath）”值确定。
3.2 USEREXIT
该参数使数据库管理器调用用户出口程序来归档和检索日志。启用了用户出口之后，就允许前滚恢复。当启用了 userexit配置参数时，就不需要启用 logretain。这两个参数中的任何一个都足以允许前滚恢复方法。 使用该参数表示覆盖了循环日志记录（缺省值）。 userexit包含有 logretain的功能，反之却不成立。 当使用 userexit 配置参数或 logretain配置参数以允许前滚恢复时，活动日志路径非常重要。当启用了 userexit配置参数时，会调用用户出口来归档日志文件，并将它们移到活动日志路径以外的位置。 以下是该参数的有效值： No（缺省值） Yes 如果启用了该参数，无论 logretain参数如何设置，都会执行日志保留记录。该参数还表示用户出口程序应该用于归档和检索日志文件。当数据库管理器关闭日志文件时，会归档日志文件。当 ROLLFORWARD 实用程序需要使用日志文件来恢复数据库时，就会检索它们。 在启用了参数 logretain和／或 userexit时，必须对数据库进行完全备份。这一状态由 backup_pending标志参数表示。 如果取消选择这两个参数，就不能对数据库进行前滚恢复，因为将不再保留日志。在这种情况下，数据库管理器会删除 logpath目录中的所有日志文件（包括联机归档日志文件），分配新的活动日志文件，并且回复到循环日志记录。
3.3 LOGPRIMARY
该参数指定要创建的主日志的数量。 无论主日志是空的还是满的，所需的磁盘空间量都是相同的。因此，如果您配置的日志数量比需要的多，那么您就不必要地多使用了磁盘空间。如果您配置的日志太少了，就会遇到“日志满”情况。当选择要配置的日志数量时，必须考虑您生成的每个日志的大小，以及您的应用程序是否能处理“日志满”情况。 对于 V8.1，这个限制是 256 GB。即，日志文件的数量（LOGPRIMARY ＋ LOGSECOND）乘以以字节为单位的每个日志文件的大小（LOGFILSIZ * 4096）必须小于256 GB。
3.4 LOGSECOND
该参数指定为恢复日志文件（仅当需要时）而创建和使用的辅助日志文件的数量。请注意，日志文件的总数由以下等式限制： logprimary＋ logsecond<＝ 256（DB2 UDB V8.1） 当主日志文件满了时，就会按需要每次分配一个辅助日志文件（大小为 logfilsiz），最多达到由该参数控制的最大数量。如果所需的辅助日志文件的数量比该参数允许的数量大，就会将一个错误代码返回到应用程序，并且会停止对数据库的操作。
3.5 LOGFILSZ
该参数确定了每个已配置日志的页数量。一页的大小是 4 KB。每个主日志的大小（页数量）对数据库性能有直接影响。当将数据库配置成保留日志，每当写满一个日志时，就会发出一个分配和初始化一个新日志的请求。增加日志大小会减少为分配和初始化新日志所需的请求数量。但是，请注意，日志大小越大，格式化每个新日志所花费的时间就越多。格式化新日志对于连接到数据库的应用程序是透明的，而且也不会影响数据库性能。
3.6 LOGBUFSZ
该参数允许您指定数据库共享内存的数量，在将日志记录写到磁盘之前，用该共享内存作为这些记录的缓冲区。当发生以下情况之一时，会将日志记录写到磁盘：事务提交/日志缓冲区满了/引起写操作的其它一些内部数据库管理器事件。 缓冲日志记录将导致使日志文件 I/O 更有效，因为将日志记录写到磁盘的频率将更低，而每次写入磁盘的日志记录则更多。
3.7 MINCOMMIT
该参数允许您延迟将日志记录写到磁盘，直到已经执行了所规定的最小数量的提交。当您有多个针对数据库的应用程序正在运行，并且应用程序在非常短的时间段里请求了许多提交，那么该延迟可以帮助减少与写日志记录相关的数据库管理器开销，从而提高性能。 这种提交分组只有在该参数的值大于 1 且连接到数据库的应用程序数量大于该参数的值时才会发生。当执行提交分组时，应用程序提交请求将被挂起，直到以下两种情况有一种先发生：时间过去一秒或者提交请求的数量等于该参数的值。
3.8 NEWLOGPATH
数据库日志最初创建在名为 SQLOGDIR 的目录中，该目录是数据库目录的子目录。可以通过将该配置参数的值更改成指向另一个目录或设备来更改放置活动日志和将来归档日志的位置。如果将数据库配置成进行前滚恢复，那么就不会将当前存储在数据库日志路径目录中的归档日志移到新的位置。 因为您可以更改日志路径位置，所以前滚恢复所需的日志可能会在不同的目录中或在不同的设备上存在。在前滚过程中可以更改此配置参数以允许您访问多个位置中的日志。 在数据库处于一致状态之前，将不会更改对 newlogpath的值。信息性数据库配置参数 database_consistent表示数据库的状态。 注：数据库管理器每次写一个事务日志。可以是活动状态的事务的总大小受数据库配置参数限制： 日志空间 >= LOGFILSIZ * LOGPRIMARY * 4096 字节 <= LOGFILSIZ * (LOGPRIMARY LOGSECOND) * 4096 字节 <= 32 GB（对于 V7.2）或 <= 256 GB（对于 V8.1）
3.9 日志存储位置
缺省情况下，日志文件存储在以下目录中： 在 Windows 上：<instance name>NODE0000SQL000××SQLOGDIR 在 UNIX 上：<instance home directory>/<instance name>/NODE0000/SQL000××/SQLOGDIR 在上述目录路径中，对于所创建的每个数据库，会有一个 SQLxxxxx（“xxxxx”是以 0 开头的数字）目录。如果在 DB2 实例中有多个物理数据库，就很难知道哪个 SQLxxxxx 目录属于哪个数据库。要解决这个问题，只要输入以下 DB2 命令：db2 list db directory on c/d……就可以看出数据库对应的编号，eg：db2 list db directory on d可以看到dbtest数据库的一些信息如下： 数据库别名 = DBTEST 数据库名称 = DBTEST 数据库目录 = SQL00002 数据库发行版级别 = a.00 注释 = 目录条目类型 = 本地 目录数据库分区号 = 0 数据库分区号 = 0 或者用命令db2 get db cfg for dbtest 日志文件路径 = D:DB2NODE0000SQL00002SQLOGDIR
四.归档日志的设置
在DB2版本8.2以前，采用用户出口程序的方式进行日志归档操作，从DB2版本8.2开始，DB2集成了日志管理功能，目前支持采用如下三种方式归档日志: DISK:将归档日志存放到磁盘上 TSM:将归档日志存放到TSM服务器 BAR APIs:第三方厂商提供的产品 DB2在版本8.2中增加了如下配置参数: 第一个日志归档方法 (LOGARCHMETH1) = LOGRETAIN logarchmeth1 的选项 (LOGARCHOPT1) = 第二个日志归档方法 (LOGARCHMETH2) = OFF logarchmeth2 的选项 (LOGARCHOPT2) = 故障转移日志归档路径 (FAILARCHPATH) = 错误时重试日志归档次数 (NUMARCHRETRY) = 5 日志归档重试延迟(秒) (ARCHRETRYDELAY) = 20 供应商选项 (VENDOROPT) = 下面是关于这些参数的说明: 日志归档方法 1(logarchmeth1)和日志归档方法 2(logarchmeth2)这些参数使数据库管理器将日志文件归档至活动日志路径之外的位置。如果指定这两个参数，每个日志文件均归 档两次。这意味着您将拥有两个位于不同位置的归档日志文件副本。这些参数的有效值包括介质类型，且在某些情况下，包括目标字段。 使用冒号(:)来分隔值。有效的值为: OFF 指定不使用日志归档方法。如果 logarchmeth1 和logarchmeth2 都设置为 OFF，则认为数据库正在使用循环日志记录，且不可前滚恢复。这是缺省值。 LOGRETAIN 此值仅可用于 logarchmeth1，且等价于将 logretain配置参数设置为 RECOVERY。如果指定此值，将自动更新logretain 配置参数。 USEREXIT 此值仅对 logarchmeth1 有效，且等价于将userexit 配置参数设置为 ON。如果指定此值，将自动更新userexit 配置参数。 DISK 此值后必须紧跟冒号(:)，然后是全限定现有路径名，日志文件将在其中归档。例如，如果将 logarchmeth1 设置为 DISK: D:DB2Arch_log，则将归档日志文件放入名为 D:DB2Arch_log 的目录。 注意: 如果正在归档至磁带，可以使用 db2tapemgr 实用程序来存储和检索日志文件。TSM（Tivoli storage management） 如果指定不带任何附加配置参数，此值指示应该使用缺省管理类，将日志文件归档在本地 TSM 服务器上。如果此值后紧跟冒号(:)和 TSM 管理类，则使用指定的管理类来归档日志文件。 VENDOR 指定将使用供应商库来归档日志文件。此值后必须紧跟冒号(:)和库的名称。库中提供的 API 必须使用备份并复原供应商产品的 API。 注意: 如果将 logarchmeth1 或 logarchmeth2 设置为 OFF 以外的值，则必须配置数据库以进行前滚恢复。 如果更新 userexit或 logretain 配置参数，将自动更新 logarchmeth1，反之亦然。然而，如果您正在使用 userexit 或 logretain,必须将 logarchmeth2 设置为 OFF。 日志归档选项 1(logarchopt1)、日志归档选项 2(logarchopt2): 指定传递至 TSM 服务器或供应商 API 的字符串。对于 TSM，此字段用于允许数据库检索在不同 TSM 节点或通过不同 TSM用户生成的日志。字符串必须以如下格式提供: “-fromnode=nodename -fromowner=ownername”其中 nodename 是最初归档日志文件的 TSM 节点的名称，ownername 是最初归档日志文件的 TSM 用户的名称。每个日志归档选项字段对应于一个日志归档方法:logarchopt1与 logarchmeth1 配合使用，logarchopt2 与 logarchmeth2 配合使用。 故障转移归档路径(failarchpath) 如果指定的日志归档方法失败，则为归档日志文件指定备用目录。在失败的日志归档方法再次可用之前，此目录是日志文件的临时存储区，此时日志文件将从此目录中移至日志归档方法。通过将日志文件移动至该临时位置，可以避免日志目录发生已满情况。此参数必须是一个全限定现有目录。 出错时的归档重试次数(numarchretry) 指定在日志文件归档到 failarchpath 配置参数指定的路径之前，使用指定的归档方法归档日志文件的尝试次数。如果设置了 failarchpath 配置参数，则只能使用该参数。缺省值为 5。 归档重试延迟(archretrydelay) 指定在上一次尝试失败之后，归档日志文件尝试之间等待的时间量(以秒计)。缺省值为 20。 供应商选项(VENDOROPT) 指定使用第三方厂商进行备份、恢复、归档日志时需要的额外参数配置。参考第三方厂商存储软件的说明配置。 下面我们以一个简单的例子配置来说明如何将日志归档到磁盘。 1、修改数据库dbtest的配置参数(请在更新之前确保使用的目录已经建立，而且DB2实例用户有合适的权限): db2 update db cfg for dbtest using logarchmeth1 DISK:D:DB2Arch_log 注意:如果先前你没有设置为归档日志模式，需要先修改默认参数，设置完参数后需要先做一个数据库的脱机备份。再修改logarchmeth1的路径，脚本如下: db2 update db cfg for dbtest using logretain on userexit on db2 backup db dbtest TO E:DB2backup 此时，日志会被自动归档到D:DB2Arch_log下，如果我们想把日志归档到另外一个地方，或者当指定的日志归档方法失败（如归档路径的磁盘空间已满），想把归档日志文件指定到备用目录，可以为logarchmeth2、failarchpath指定路径，脚本如下：（请在更新之前确保使用的目录已经建立，而且DB2实例用户有合适的权限) db2 update db cfg for dbtest using logarchmeth2 DISK:D:DB2Arch_log2 db2 update db cfg for dbtest using failarchpath D:DB2templogarc 此时用命令db2 get db cfg for dbtest可以查看到修改后的参数情况如下： 第一个日志归档方法 (LOGARCHMETH1) = DISK:d:db2arch_log logarchmeth1 的选项 (LOGARCHOPT1) = 第二个日志归档方法 (LOGARCHMETH2) = DISK:D:DB2Arch_log2 logarchmeth2 的选项 (LOGARCHOPT2) = 故障转移日志归档路径 (FAILARCHPATH) = D:DB2templogarc 错误时重试日志归档次数 (NUMARCHRETRY) = 5 日志归档重试延迟（秒） (ARCHRETRYDELAY) = 20 供应商选项 (VENDOROPT) = 尽管采用了归档日志，但是当我们处理一个工作单元中包含多个类似IMPORT、INSERT、DELETE 、UPDATE、RUNSTATS 或 REORG时，当（logprimary＋ logsecond）个日志写满事物还没有处理完成（提交）时，就会出现日志满的错误，为此我们要考虑适当的修改日志的大小和数量，同时尽量多次提交（commit）处理事物，修改日志脚本如下： db2 UPDATE DB CFG FOR DBName USING LOGFILSIZ 6000 ; –日志文件大小 db2 UPDATE DB CFG FOR DBName USING LOGPRIMARY 8 ;–日志文件数目 db2 UPDATE DB CFG FOR DBName USING LOGSECOND 5 ; –辅助日志文件数目 另外，由于物理设备的大小限制，为了保证日志正常归档，需要不定期的删除归档日志存放路径下的无用日志，而如何判断哪些归档日志是否可以彻底删除？需要依据对数据库进行的备份情况而定。通常地，每周末进行一次完全备份，其余几天每天进行一次增量备份，只要备份文件保留完好，那么最近一次成功的增量备份日期（时间）之前的归档日志都可以删除。可以用命令db2 list history backup all for DBName查看对数据库的备份、恢复情况。 我们讨论了事务性日志记录的许多方面，如事务性日志记录是什么、如何控制它、它们存储在哪里以及如何存储、可能遇到的一些常见错误。如果您知道日志记录活动如何影响数据库和操作系统，就能够成功且有效地排除由于日志记录错误而产生的问题。
—-
代码语言：javascript复制[db2inst2@cognoswithdb2 ~]$ db2 get db cfg for sample
Database Configuration for Database sample
Database configuration release level = 0x1000
Database release level = 0x1000
Database territory = US
Database code page = 1208
Database code set = UTF-8
Database country/region code = 1
Database collating sequence = IDENTITY
Alternate collating sequence (ALT_COLLATE) =
Number compatibility = OFF
Varchar2 compatibility = OFF
Date compatibility = OFF
Database page size = 8192
Statement concentrator (STMT_CONC) = OFF
Discovery support for this database (DISCOVER_DB) = ENABLE
Restrict access = NO
Default query optimization class (DFT_QUERYOPT) = 5
Degree of parallelism (DFT_DEGREE) = 1
Continue upon arithmetic exceptions (DFT_SQLMATHWARN) = NO
Default refresh age (DFT_REFRESH_AGE) = 0
Default maintained table types for opt (DFT_MTTB_TYPES) = SYSTEM
Number of frequent values retained (NUM_FREQVALUES) = 10
Number of quantiles retained (NUM_QUANTILES) = 20
Decimal floating point rounding mode (DECFLT_ROUNDING) = ROUND_HALF_EVEN
Backup pending = NO
All committed transactions have been written to disk = NO
Rollforward pending = NO
Restore pending = NO
Multi-page file allocation enabled = YES
Log retain for recovery status = NO
User exit for logging status = NO
Self tuning memory (SELF_TUNING_MEM) = OFF
Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC(40256)
Database memory threshold (DB_MEM_THRESH) = 100
Max storage for lock list (4KB) (LOCKLIST) = 4096
Percent. of lock lists per application (MAXLOCKS) = 10
Package cache size (4KB) (PCKCACHESZ) = (MAXAPPLS*8)
Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = 5000
Sort list heap (4KB) (SORTHEAP) = 256
Database heap (4KB) (DBHEAP) = AUTOMATIC(1200)
Catalog cache size (4KB) (CATALOGCACHE_SZ) = (MAXAPPLS*5)
Log buffer size (4KB) (LOGBUFSZ) = 256
Utilities heap size (4KB) (UTIL_HEAP_SZ) = 5000
SQL statement heap (4KB) (STMTHEAP) = AUTOMATIC(8192)
Default application heap (4KB) (APPLHEAPSZ) = AUTOMATIC(256)
Application Memory Size (4KB) (APPL_MEMORY) = AUTOMATIC(40000)
Statistics heap size (4KB) (STAT_HEAP_SZ) = AUTOMATIC(4384)
Interval for checking deadlock (ms) (DLCHKTIME) = 10000
Lock timeout (sec) (LOCKTIMEOUT) = -1
Changed pages threshold (CHNGPGS_THRESH) = 60
Number of asynchronous page cleaners (NUM_IOCLEANERS) = AUTOMATIC(2)
Number of I/O servers (NUM_IOSERVERS) = AUTOMATIC(3)
Sequential detect flag (SEQDETECT) = YES
Default prefetch size (pages) (DFT_PREFETCH_SZ) = AUTOMATIC
Track modified pages (TRACKMOD) = NO
Default number of containers = 1
Default tablespace extentsize (pages) (DFT_EXTENT_SZ) = 32
Max number of active applications (MAXAPPLS) = AUTOMATIC(40)
Average number of active applications (AVG_APPLS) = AUTOMATIC(1)
Max DB files open per application (MAXFILOP) = 61440
Log file size (4KB) (LOGFILSIZ) = 1000
Number of primary log files (LOGPRIMARY) = 3
Number of secondary log files (LOGSECOND) = 10
Changed path to log files (NEWLOGPATH) =
Path to log files = /home/db2inst2/db2inst2/NODE0000/SQL00001/LOGSTREAM0000/
Overflow log path (OVERFLOWLOGPATH) =
Mirror log path (MIRRORLOGPATH) =
First active log file =
Block log on disk full (BLK_LOG_DSK_FUL) = NO
Block non logged operations (BLOCKNONLOGGED) = NO
Percent max primary log space by transaction (MAX_LOG) = 0
Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0
Percent log file reclaimed before soft chckpt (SOFTMAX) = 0
Target for oldest page in LBP (PAGE_AGE_TRGT_MCR) = 240
HADR database role = STANDARD
HADR local host name (HADR_LOCAL_HOST) =
HADR local service name (HADR_LOCAL_SVC) =
HADR remote host name (HADR_REMOTE_HOST) =
HADR remote service name (HADR_REMOTE_SVC) =
HADR instance name of remote server (HADR_REMOTE_INST) =
HADR timeout value (HADR_TIMEOUT) = 120
HADR target list (HADR_TARGET_LIST) =
HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
HADR spool log data limit (4KB) (HADR_SPOOL_LIMIT) = AUTOMATIC(0)
HADR log replay delay (seconds) (HADR_REPLAY_DELAY) = 0
HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 0
First log archive method (LOGARCHMETH1) = OFF
Archive compression for logarchmeth1 (LOGARCHCOMPR1) = OFF
Options for logarchmeth1 (LOGARCHOPT1) =
Second log archive method (LOGARCHMETH2) = OFF
Archive compression for logarchmeth2 (LOGARCHCOMPR2) = OFF
Options for logarchmeth2 (LOGARCHOPT2) =
Failover log archive path (FAILARCHPATH) =
Number of log archive retries on error (NUMARCHRETRY) = 5
Log archive retry Delay (secs) (ARCHRETRYDELAY) = 20
Vendor options (VENDOROPT) =
Auto restart enabled (AUTORESTART) = ON
Index re-creation time and redo index build (INDEXREC) = SYSTEM (RESTART)
Log pages during index build (LOGINDEXBUILD) = OFF
Default number of loadrec sessions (DFT_LOADREC_SES) = 1
Number of database backups to retain (NUM_DB_BACKUPS) = 12
Recovery history retention (days) (REC_HIS_RETENTN) = 366
Auto deletion of recovery objects (AUTO_DEL_REC_OBJ) = OFF
TSM management class (TSM_MGMTCLASS) =
TSM node name (TSM_NODENAME) =
TSM owner (TSM_OWNER) =
TSM password (TSM_PASSWORD) =
Automatic maintenance (AUTO_MAINT) = ON
Automatic database backup (AUTO_DB_BACKUP) = OFF
Automatic table maintenance (AUTO_TBL_MAINT) = ON
Automatic runstats (AUTO_RUNSTATS) = ON
Real-time statistics (AUTO_STMT_STATS) = ON
Statistical views (AUTO_STATS_VIEWS) = OFF
Automatic sampling (AUTO_SAMPLING) = OFF
Automatic reorganization (AUTO_REORG) = OFF
Auto-Revalidation (AUTO_REVAL) = DEFERRED
Currently Committed (CUR_COMMIT) = ON
CHAR output with DECIMAL input (DEC_TO_CHAR_FMT) = NEW
Enable XML Character operations (ENABLE_XMLCHAR) = YES
WLM Collection Interval (minutes) (WLM_COLLECT_INT) = 0
Monitor Collect Settings
Request metrics (MON_REQ_METRICS) = BASE
Activity metrics (MON_ACT_METRICS) = BASE
Object metrics (MON_OBJ_METRICS) = EXTENDED
Routine data (MON_RTN_DATA) = NONE
Routine executable list (MON_RTN_EXECLIST) = OFF
Unit of work events (MON_UOW_DATA) = NONE
UOW events with package list (MON_UOW_PKGLIST) = OFF
UOW events with executable list (MON_UOW_EXECLIST) = OFF
Lock timeout events (MON_LOCKTIMEOUT) = NONE
Deadlock events (MON_DEADLOCK) = WITHOUT_HIST
Lock wait events (MON_LOCKWAIT) = NONE
Lock wait event threshold (MON_LW_THRESH) = 5000000
Number of package list entries (MON_PKGLIST_SZ) = 32
Lock event notification level (MON_LCK_MSG_LVL) = 1
SMTP Server (SMTP_SERVER) =
SQL conditional compilation flags (SQL_CCFLAGS) =
Section actuals setting (SECTION_ACTUALS) = NONE
Connect procedure (CONNECT_PROC) =
Adjust temporal SYSTEM_TIME period (SYSTIME_PERIOD_ADJ) = NO
Log DDL Statements (LOG_DDL_STMTS) = NO
Log Application Information (LOG_APPL_INFO) = NO
Default data capture on new Schemas (DFT_SCHEMAS_DCC) = NO
Default table organization (DFT_TABLE_ORG) = ROW
Default string units (STRING_UNITS) = SYSTEM
National character string mapping (NCHAR_MAPPING) = GRAPHIC_CU16
Database is in write suspend state = NO
Extended row size support (EXTENDED_ROW_SZ) = ENABLE
[db2inst2@cognoswithdb2 ~]$ db2 get db cfg for sample|grep status
Log retain for recovery status = NO
User exit for logging status = NO
[db2inst2@cognoswithdb2 ~]$ 在我的10.5上没有找到LOGRETAIN参数
但是在我的v8上面，有
代码语言：javascript复制db2 => get db cfg for sample
数据库 sample 的数据库配置
数据库配置发行版级别 = 0x0a00
数据库发行版级别 = 0x0a00
数据库地域 = CN
数据库代码页 = 1386
数据库代码集 = GBK
数据库国家／地区代码 = 86
数据库整理顺序 = UNIQUE
备用整理顺序 (ALT_COLLATE) =
动态 SQL 查询管理 (DYN_QUERY_MGMT) = DISABLE
对此数据库的发现支持 (DISCOVER_DB) = ENABLE
缺省查询优化类 (DFT_QUERYOPT) = 5
并行度 (DFT_DEGREE) = 1
在算术异常时继续 (DFT_SQLMATHWARN) = NO
缺省刷新有效期 (DFT_REFRESH_AGE) = 0
缺省维护的选项（DFT_MTTB_TYPES）的表类型 = SYSTEM
保留的高频值的数目 (NUM_FREQVALUES) = 10
保留的分位点数目 (NUM_QUANTILES) = 20
备份暂挂 = NO
数据库是一致的 = YES
前滚暂挂 = NO
复原暂挂 = NO
启用的多页文件分配 = YES
恢复状态的日志保留 = NO
日志记录状态的用户出口 = NO
Data Links 标记到期时间间隔（秒） (DL_EXPINT) = 60
Data Links 写令牌初始时间间隔 (DL_WT_IEXPINT) = 60
副本的 Data Links 数目 (DL_NUM_COPIES) = 1
删除后的 Data Links 时间（天数） (DL_TIME_DROP) = 1
大写的 Data Links 标记 (DL_UPPER) = NO
Data Links 标记算法 (DL_TOKEN) = MAC0
数据库堆（4KB） (DBHEAP) = 600
数据库共享内存大小（4KB） (DATABASE_MEMORY) = AUTOMATIC
目录高速缓存大小（4KB） (CATALOGCACHE_SZ) = (MAXAPPLS*4)
日志缓冲区大小（4KB） (LOGBUFSZ) = 8
实用程序堆大小（4KB） (UTIL_HEAP_SZ) = 5000
缓冲池大小（页） (BUFFPAGE) = 250
扩充存储段大小（4KB） (ESTORE_SEG_SZ) = 16000
扩充存储段的数目 (NUM_ESTORE_SEGS) = 0
锁定列表的最大存储量（4KB） (LOCKLIST) = 50
应用程序组内存集的最大大小（4KB） (APPGROUP_MEM_SZ) = 30000
应用程序组堆的内存百分比 (GROUPHEAP_RATIO) = 70
最大应用程序控制堆大小（4KB） (APP_CTL_HEAP_SZ) = 128
共享排序的排序堆域值（4KB） (SHEAPTHRES_SHR) = (SHEAPTHRES)
排序列表堆（4KB） (SORTHEAP) = 256
SQL 语句堆（4KB） (STMTHEAP) = 2048
缺省应用程序堆（4KB） (APPLHEAPSZ) = 256
程序包高速缓存大小（4KB） (PCKCACHESZ) = (MAXAPPLS*8)
统计信息堆大小（4KB） (STAT_HEAP_SZ) = 4384
检查死锁的时间间隔（毫秒） (DLCHKTIME) = 10000
每个应用程序的锁定百分比列表 (MAXLOCKS) = 22
锁定超时（秒） (LOCKTIMEOUT) = -1
更改的页阈值 (CHNGPGS_THRESH) = 60
异步页清除程序的数目 (NUM_IOCLEANERS) = 1
I/O 服务器的数目 (NUM_IOSERVERS) = 3
索引排序标志 (INDEXSORT) = YES
顺序检测标志 (SEQDETECT) = YES
缺省预取大小（页） (DFT_PREFETCH_SZ) = AUTOMATIC
跟踪修改的页数 (TRACKMOD) = OFF
容器的缺省数目 = 1
缺省表空间扩展数据块大小(页) (DFT_EXTENT_SZ) = 32
活动应用程序的最大数目 (MAXAPPLS) = AUTOMATIC
活动应用程序的平均数目 (AVG_APPLS) = 1
每个应用程序的最大打开 DB 文件数 (MAXFILOP) = 64
日志文件大小（4KB） (LOGFILSIZ) = 1000
主日志文件的数目 (LOGPRIMARY) = 3
辅助日志文件的数目 (LOGSECOND) = 2
已更改的至日志文件的路径 (NEWLOGPATH) =
日志文件路径 = D:DB2NODE0000SQL0
002SQLOGDIR
溢出日志路径 (OVERFLOWLOGPATH) =
镜像日志路径 (MIRRORLOGPATH) =
首个活动日志文件 =
磁盘上已满的块日志 (BLK_LOG_DSK_FUL) = NO
事务使用的最大活动日志空间的百分比 (MAX_LOG) = 0
1 个活动 UOW 的活动日志文件的数目 (NUM_LOG_SPAN) = 0
组落实计数 (MINCOMMIT) = 1
软检查点前回收的日志文件的百分比 (SOFTMAX) = 100
启用的恢复的日志保留 (LOGRETAIN) = OFF 启用的日志记录的用户出口 (USEREXIT) = OFF
HADR 数据库角色 = STANDARD
HADR 本地主机名 (HADR_LOCAL_HOST) =
HADR 本地服务名称 (HADR_LOCAL_SVC) =
HADR 远程主机名 (HADR_REMOTE_HOST) =
HADR 远程服务名称 (HADR_REMOTE_SVC) =
远程服务器的 HADR 实例名 (HADR_REMOTE_INST) =
HADR 超时值 (HADR_TIMEOUT) = 120
HADR 日志写同步方式 (HADR_SYNCMODE) = NEARSYNC
第一个日志归档方法 (LOGARCHMETH1) = OFF
logarchmeth1 的选项 (LOGARCHOPT1) =
第二个日志归档方法 (LOGARCHMETH2) = OFF
logarchmeth2 的选项 (LOGARCHOPT2) =
故障转移日志归档路径 (FAILARCHPATH) =
错误时重试日志归档次数 (NUMARCHRETRY) = 5
日志归档重试延迟（秒） (ARCHRETRYDELAY) = 20
供应商选项 (VENDOROPT) =
启用的自动重新启动 (AUTORESTART) = ON
索引重新创建时间和重做索引构建 (INDEXREC) = SYSTEM (RESTART)
在索引构建期间记录页 (LOGINDEXBUILD) = OFF
loadrec 会话的缺省数目 (DFT_LOADREC_SES) = 1
要保留的数据库备份的数目 (NUM_DB_BACKUPS) = 12
恢复历史保留时间（天数） (REC_HIS_RETENTN) = 366
TSM 管理类 (TSM_MGMTCLASS) =
TSM 节点名 (TSM_NODENAME) =
TSM 所有者 (TSM_OWNER) =
TSM 密码 (TSM_PASSWORD) =
自动维护 (AUTO_MAINT) = OFF
自动数据库备份 (AUTO_DB_BACKUP) = OFF
自动表维护 (AUTO_TBL_MAINT) = OFF
自动 runstats (AUTO_RUNSTATS) = OFF
自动统计信息概要分析 (AUTO_STATS_PROF) = OFF
自动概要文件更新 (AUTO_PROF_UPD) = OFF
自动重组 (AUTO_REORG) = OFF
db2 =>应该是数据库版本参数约有差异
现在的关键问题就是
五:V10.5数据库日志的配置
由于版本的差异，我就从官方文档上找了相应的说明
5.1：循环日志
当创建新数据库时，循环日志记录是缺省行为。（将 logarchmeth1 和 logarchmeth2 数据库配置参数设置为 OFF。） 对于这种类型的日志记录，只允许完整的脱机数据库备份。进行完整备份时，数据库必须脱机（用户不可访问）。
正如它的名称所表示的那样，循环日志记录使用一个联机日志环，提供对事务故障和系统崩溃的恢复。仅使用和保留日志到确保当前事务的完整性这样一个程度。循环日志记录不允许将数据库在上次完整备份操作后执行的事务中前滚。上次备份操作后发生的所有更改都将丢失。因为这种类型的复原操作将数据恢复至进行完整备份的特定时间点，所以它称为版本恢复。
图 1. 循环日志记录
崩溃恢复期间，使用 活动 日志来防止故障 （系统电源或应用程序错误）使数据库处于不一致的状态。活动日志 位于数据库日志路径目录中。
5.2：归档日志
归档日志记录专门用于前滚恢复。已归档日志是指已从当前日志路径或镜像日志路径复制到其他位置的日志文件。 可使用 logarchmeth1 数据库配置参数和/或 logarchmeth2 数据库配置参数来使您或数据库管理员能够管理日志归档进程。
图 1. 前滚恢复中的活动和已归档数据库日志. 在运行时间较长的事务中，可以有多个活动日志。
仅当为数据库配置归档日志记录后，才支持进行联机备份。在联机备份操作期间，将记录对数据库的所有活动。完成联机备份后，数据库管理器会强制当前活动的日志关闭并因此对该日志归档。此过程确保联机备份有一组完整的已归档日志可用于恢复。复原联机备份映像时，必须至少将日志前滚至完成备份操作的时间点。为了便于执行此操作，在复原数据库时必须使已归档日志可用。
可使用 logarchmeth1 和 logarchmeth2 数据库配置参数来指定已归档日志的存储位置。可使用 logarchmeth1 参数对logpath 配置参数设置的活动日志路径中的日志文件归档。可使用 logarchmeth2 参数将活动日志路径中的日志文件的其他副本归档至另一位置。如果未配置镜像日志记录，那么将从 logarchmeth1 参数使用的同一日志路径中获取其他副本。如果配置了镜像日志记录（通过 mirrorlogpath 配置参数），那么 logarchmeth2 配置参数将改为对镜像日志路径中的日志文件归档，这可以在前滚恢复期间提高弹性。newlogpath 参数影响活动日志的存储位置。
在某些方案中，可以压缩已归档日志文件以帮助减少与这些文件相关联的存储开销。如果 logarchmeth1 和logarchmeth2 配置参数设置为 DISK、TSM 或 VENDOR，那么可通过将 logarchcompr1 和 logarchcompr2 配置参数设置为ON 来启用已归档日志文件压缩。如果以动态方式设置 logarchcompr1 和 logarchcompr2，那么不会对已归档的任何日志文件进行压缩。
如果使用 LOGRETAIN 选项来指定您想要用来管理活动日志的值，那么数据库管理器会在对活动日志路径中的日志文件归档并且崩溃恢复不再需要这些文件后重命名这些文件。如果启用了无限日志记录，那么需要为更多活动日志文件提供额外空间，这样数据库服务器会在对日志文件归档后对其重命名。数据库管理器在活动日志路径中保留了多达 8 个额外日志文件以进行重命名。
5.3：用于数据库日志记录的配置参数
任何高可用性策略的一个关键元素是数据库日志记录。可以使用数据库日志来记录事务信息、使主数据库与辅助（备用数据库）同步并前滚已接管出现故障的主数据库的辅助数据库。 要配置这些数据库日志记录活动，必须设置各种数据库配置参数。
归档重试延迟 (archretrydelay)
指定在上一次尝试失败之后，归档日志文件尝试之间等待的时间量（以秒计）。缺省值为 20。
日志磁盘已满时挂起 (blk_log_dsk_ful)
可以设置此配置参数以防止当 DB2® 数据库管理器不能在活动日志路径中创建新日志文件时发生“磁盘已满”错误。DB2 数据库管理器将改为每隔五分钟就尝试创建一次日志文件，直至成功。每次尝试之后，DB2 数据库管理器都会将一条消息写至管理通知日志。确认应用程序因为日志磁盘已满情况而挂起的唯一的方法就是监视管理通知日志。在成功创建日志文件之前，尝试更新表数据的所有用户应用程序都不能落实事务。只读查询可能不会直接受影响；但是，如果查询需要访问被更新请求锁定的数据或者由更新应用程序在缓冲池中修正的数据页时，只读查询也将被阻塞。
如果将 blk_log_dsk_ful 设置为 YES，那么会导致应用程序在 DB2 数据库管理器遇到日志磁盘已满错误时挂起。于是您就能够解决错误，而应用程序可以继续运行。磁盘已满情况可以通过将旧的日志文件移至另一文件系统、增加文件系统的大小以使挂起应用程序能够完成或调查并解决任何日志归档失败来解决。
如果将 blk_log_dsk_ful 设置为 NO，那么接收到日志磁盘已满错误的事务将失败并被回滚。
故障转移归档路径 (failarchpath)
如果常规归档路径存在问题（例如，如果该路径无法访问或已满），那么会为归档日志文件指定备用目录。在失败的日志归档方法再次可用之前，此目录是日志文件的临时存储区，日志归档方法再次可用后日志文件将从此目录中移至原始日志归档中所指定的路径。通过将日志文件移动至此临时位置，有助于避免日志目录发生已满情况。此参数必须是一个标准现有目录。
主日志归档压缩 (logarchcompr1) 和辅助日志归档压缩 (logarchcompr2)
在某些情况下，这些参数控制数据库管理器是否压缩归档日志文件。如果对日志归档文件进行压缩，那么可以减少与存储这些文件相关联的开销。
这些参数的有效值如下所示：
OFF
此值指定不压缩日志归档文件。缺省值为 OFF。
ON
此值指定压缩日志归档文件。如果以动态方式设置，那么不会对已归档的日志文件进行压缩。
注：
- 如果将 logarchmeth1 配置参数设置为 DISK、TSM 或 VENDOR 以外的值，那么无论 logarchcompr1 配置参数设置为何，对日志归档压缩都没有影响。
- 如果将 logarchmeth2 配置参数设置为 DISK、TSM 或 VENDOR 以外的值，那么无论 logarchcompr2 配置参数设置为何，对日志归档压缩都没有影响。
日志归档方法 1 (logarchmeth1)、日志归档方法 2 (logarchmeth2)
这些参数使数据库管理器将日志文件归档至活动日志路径之外的位置。如果同时指定这两个参数，那么由 logpath 配置参数设置的活动日志路径中的每个日志文件均会进行两次归档。这意味着将在两个不同目标位置具有该日志路径中的已归档日志文件的两个相同副本。如果通过使用 mirrorlogpath 配置参数指定了镜像日志记录，那么 logarchmeth2配置参数将归档镜像日志路径中的日志文件，而不是归档活动日志路径中日志文件的其他副本。这意味着将在两个不同目标位置归档日志文件的两个不同副本：一个副本来自活动日志路径，另一个副本来自镜像日志路径。
这些参数的有效值如下所示：
OFF
此值指定不使用日志归档方法。如果将 logarchmeth1 和 logarchmeth2 配置参数都设置为 OFF，那么认为数据库正在使用循环日志记录，且不可前滚恢复。缺省值为 OFF。
LOGRETAIN
指定活动日志文件文件保留并成为联机归档日志文件以用于前滚恢复。
USEREXIT
指定执行日志保留日志记录并应使用用户出口程序来归档和检索这些日志文件。日志文件是在变满时归档的。前滚实用程序必须使用日志文件来复原数据库时会检索这些日志文件。
DISK
此值后必须紧跟冒号 (:)，然后是现有标准路径名，日志文件将在其中归档。例如，如果将 logarchmeth1 配置参数设置为 DISK:/u/dbuser/archived_logs，那么归档日志文件将放入 /u/dbuser/archived_logs/INSTANCE_NAME/DBNAME/NODExxxx/LOGSTREAMxxxx/Cxxxxxxx 目录。
注： 如果正在归档至磁带，那么可以使用 db2tapemgr 实用程序来存储和检索日志文件。
TSM
如果指定不带有任何附加配置参数，那么此值指示应该使用缺省管理类，将日志文件归档在本地 Tivoli® Storage Manager (TSM) 服务器上。如果此值后紧跟冒号（:）和 TSM 管理类，那么使用指定的管理类来归档日志文件。
VENDOR
指定将使用供应商库来归档日志文件。此值后必须紧跟冒号（:）和库的名称。库中提供的 API 必须使用备份并复原供应商产品的 API。
注：
- 如果将 logarchmeth1 或 logarchmeth2 设置为 OFF 以外的值，那么必须配置数据库以进行前滚恢复。
日志归档选项 1 (logarchopt1) 和日志归档选项 2 (logarchopt2)
指定传递至 TSM API 或供应商 API 的字符串。
对于 TSM 环境，使用此参数来允许数据库检索在不同 TSM 节点或通过不同 TSM 用户或使用代理节点在 TSM 环境中（例如在 DB2 pureScale®环境中）生成的日志。必须以下例其中一种格式来提供字符串：
要在 TSM 服务器未配置为支持代理节点客户机时，检索不同 TSM 节点上生成的日志：
当未将 TSM 服务器配置成支持代理节点客户机时，对于检索通过不同的 TSM 用户生成的日志：
要在 TSM 服务器未配置为支持代理节点客户机时，检索在不同 TSM 节点上生成的日志以及由不同 TSM 用户生成的日志：
对于检索在客户机代理节点配置中（例如在 环境中，其中有多个成员处理相同数据）生成的日志：
注：
- 使用 -asnodename TSM 选项时，不使用每个成员的节点名 (nodename) 来存储数据。将改为使用 DB2 pureScale实例内所有成员使用的共享 TSM 目标节点的名称来存储数据。
- -fromnode 选项与 -fromowner 选项和 -asnodename 选项不兼容，因此不能同时使用。请将 -asnodename 选项用于使用代理节点的 TSM 配置，而将另外两个选项用于其他类型的 TSM 配置。有关更多信息，请参阅配置 Tivoli Storage Manager 客户机。
日志缓冲区 (logbufsz)
此参数允许您指定在将日志记录写至磁盘之前用作这些记录的缓冲区的内存量。当发生下列任何一项事件时会将日志记录写入磁盘：
- 事务落实
- 日志缓冲区已满
- 发生了某些其他的内部数据库管理器事件。
增加日志缓冲区的大小可使与日志记录关联的输入/输出 (I/O) 活动更有效，因为将日志记录写到磁盘中的频率更低，而每次写入的记录却更多。但是，如果日志缓冲区大小值较大，执行恢复所需的时间就会较长。此外，您也能够使用较高的 logbufsz 设置来减少从日志磁盘的读取次数。（要确定系统是否从中受益，请使用 log_reads 监视器元素来检查读取日志磁盘的次数是否很多。
日志文件大小 (logfilsiz)
此参数以 4 KB 的页数指定每个配置日志的大小。
对可配置的每个日志流的总活动日志空间有 1024 GB 的逻辑限制。此限制源自每个日志文件的上限（即 4 KB）以及最大主日志文件数与最大辅助日志文件数之和（即 256）。
日志文件的大小对性能有直接的影响。从一个日志切换至另一个日志需要付出性能代价。因此，从纯性能角度来说，日志文件大小越大越好。此参数还指示要归档的日志文件大小。这种情况下，日志文件大小越大并不一定越好，因为较大的日志文件大小增加了故障或导致日志装入方案中的延迟的发生机率。当考虑活动日志空间时，最好有较多的较小日志文件。例如，如果有 2 个很大的日志文件，并且事务启动接近一个日志文件的末尾，那么仅有一半日志空间仍然可用。
每当数据库取消激活（与该数据库的所有连接都终止）时，就截断当前正写入的日志文件。因此，如果某个数据库被频繁取消激活，那么最好不要选择较大的日志文件大小，这是因为 DB2 数据库管理器将仅创建将会截断的较大文件。可使用 ACTIVATE DATABASE 命令来避免此成本，因为它会阻止最后一个客户机与数据库断开连接时数据库自动取消激活。
假定应用程序将数据库保持为打开以使打开数据库时的处理时间最短，日志文件大小应由建立脱机归档日志副本所花的时间确定。
将日志文件的丢失降低至最小程度，也是设置日志大小时的一个重要注意事项。归档一次针对一整个日志文件进行操作。如果配置较大的日志文件，那么会增加归档之间的时间。 如果介质包含日志故障，某些事务信息将可能丢失。减小日志文件大小会增加归档的频率，但可以减少由于介质故障而丢失的信息量，因为平均而言，在任何给定的时间点处，尚未归档的日志数据较少。
每个事务的最大日志 (max_log)
此参数指示一个事务可以消耗的主日志空间的百分比。该值是为 logprimary 配置参数指定的值的百分比。
如果该值设置为 0，那么对一个事务可以消耗的总的主日志空间的百分比没有限制。如果应用程序违反了 max_log 配置，那么将强制该应用程序与数据库断开连接并且事务将回滚。
可以通过将 DB2_FORCE_APP_ON_MAX_LOG 注册表变量设置为 FALSE 来重设此行为。这将导致违反了 max_log 配置的事务失败。该应用程序仍然可以落实在工作单元中由先前语句完成的工作，它也可以回滚已完成的工作以撤销该工作单元。
当启用了无限活动日志空间时，此参数和 num_log_span 配置参数非常有用。如果打开了无限记录（即，logsecond 为 -1），那么事务数不受日志文件数的上限 (logprimary logsecond) 限制。当达到 logprimary 的值时，DB2 数据库管理器将开始归档活动日志，而不是使事务失败。这样可能会导致问题，例如，有一个长期运行的事务，但一直未落实它（可能是由于具有逻辑错误的应用程序导致的）。如果出现这种情况，那么活动日志空间会不断增长，从而可能使得崩溃恢复性能很差。为了防止这样，可以为 max_log 和/或 num_log_span 配置参数指定值。
注： max_log 配置参数施加的限制不适用于以下 DB2 命令： ARCHIVE LOG、 BACKUP DATABASE、 LOAD、 REORG、 RESTORE DATABASE 和 ROLLFORWARD DATABASE。
镜像日志路径 (mirrorlogpath)
要防止主日志路径上的日志发生磁盘故障或被无意中删除的情况，可以指定在辅助（镜像）路径上维护完全相同的一组日志。要执行此操作，将此配置参数的值更改为指向另一目录。如果数据库被配置为进行前滚恢复，那么不要将当前存储在镜像日志路径目录中的归档日志移至新位置。
mirrorlogpath 参数也会影响日志归档行为，您可以使用此参数进一步提高前滚恢复期间的弹性：设置了mirrorlogpath 和 logarchmeth2 时，logarchmeth2 将归档镜像日志路径中的日志文件，而不是归档活动日志路径中日志文件的其他副本。可以使用此日志归档行为来提高弹性，这是因为镜像日志路径中可用的已归档日志文件可能仍然可用以继续执行数据库恢复操作，即使在归档之前主日志文件由于磁盘故障而毁坏。
因为可以更改日志路径位置，因此前滚恢复所需的日志可以存在于不同的目录中。在前滚操作期间可更改此配置参数的值，以允许您从其他镜像日志路径访问日志文件。
必须跟踪这些日志的位置。
直到数据库处于一致状态时才会应用所作的更改。配置参数 database_consistent 返回数据库的状态。
要关闭此配置参数，将它的值设置为 DEFAULT。
注：
- 如果主日志路径是原始设备，那么此配置参数不受支持。
- 对此参数指定的值不能是原始设备。
- 在 DB2 pureScale环境中，连接至数据库或激活数据库的第一个成员会处理对此日志路径参数的配置更改。DB2 数据库管理器会验证路径是否存在，以及它对该路径是否具有读和写访问权。它还会为日志文件创建特定于成员的子目录。 如果其中任何一个操作失败，那么 DB2 数据库管理器会拒绝指定的路径，并使用旧路径让数据库联机。如果接受了指定的路径，那么会将新值传播给每个成员。 如果某个成员在尝试切换至新路径时失败，那么后续尝试激活它或连接至它都将失败 (SQL5099N)。 所有成员都必须使用相同的日志路径。
新日志路径 (newlogpath)
数据库日志最初创建于下列目录： db_path/ instance_name/ dbname/NODE0000/LOGSTREAM0000。通过将此配置参数的值更改为指向另一目录或另一设备，可以更改放置活动日志文件（将来会放置以后的归档日志）的位置。如果数据库被配置为进行前滚恢复，那么不要将当前存储在数据库日志路径目录中的归档日志移至新位置。
因为可以更改该日志路径的位置，因此前滚恢复所需的日志可以存在于不同的目录中或不同的设备上。在前滚操作期间可更改此配置参数的值，以允许您访问位于多个位置的日志。
必须跟踪这些日志的位置。
直到数据库处于一致状态时才会应用所作的更改。配置参数 database_consistent 返回数据库的状态。
注： 在 DB2 pureScale环境中，连接至数据库或激活数据库的第一个 成员会处理对此日志路径参数的配置更改。DB2 数据库管理器会验证路径是否存在，以及它对该路径是否具有读和写访问权。它还会为日志文件创建特定于成员的子目录。 如果其中任何一个操作失败，那么 DB2 数据库管理器会拒绝指定的路径，并使用旧路径让数据库联机。如果接受了指定的路径，那么会将新值传播给每个 成员。 如果某个成员在尝试切换至新路径时失败，那么后续尝试激活它或连接至它都将失败 (SQL5099N)。 所有 成员都必须使用相同的日志路径。
对组的落实次数 (mincommit)
此参数允许您延迟将日志记录写入磁盘，直到执行了最小数目的落实为止。 此延迟可有助于减少与写入日志记录关联的数据库管理器开销，这样如果您有多个应用程序对数据库运行，且在很短的时间内该应用程序请求了许多落实，那么可改进性能。
仅当此参数的值大于 1，且多个应用程序大约同时尝试落实其事务时，才会对落实进行这种分组。落实组合生效时，保持应用程序落实请求，直到经过 1 秒钟或落实请求数等于此参数的值为止。
出错时的归档重试次数 (numarchretry)
指定在日志文件归档到 failarchpath 配置参数指定的路径之前，使用配置的日志归档方法归档日志文件的尝试次数。如果设置了 failarchpath 配置参数，那么只能使用该参数。缺省值为 5。
事务可以跨越的活动日志数 (num_log_span)
此参数指示一个活动事务可以跨越的活动日志文件数。如果该值设置为 0，那么对单个事务可以跨越的日志文件数没有限制。
如果应用程序违反了 num_log_span 设置，那么将强制该应用程序与数据库断开连接。
当启用了无限活动日志空间时，此参数和 max_log 配置参数非常有用。如果打开了无限记录（即，logsecond 为 -1），那么事务数不受日志文件数的上限 (logprimary logsecond) 限制。当达到 logprimary 的值时，DB2 数据库管理器将开始归档活动日志，而不是使事务失败。这样可能会导致问题，例如，有一个长期运行的事务，但一直未落实它（可能是由于具有逻辑错误的应用程序导致的）。如果出现这种情况，那么活动日志空间会不断增长，从而可能使得崩溃恢复性能很差。为了防止这样，可以为 max_log 和/或 num_log_span 配置参数指定值。
注： 由 num_log_span 配置参数施加的限制不适用于下列 DB2 命令：ARCHIVE LOG、BACKUP DATABASE、LOAD、REORG、RESTORE DATABASE 和 ROLLFORWARD DATABASE。
溢出日志路径 (overflowlogpath)
此参数可以用于几种函数，这取决于日志记录要求。可以指定一个位置来让 DB2 数据库管理器查找前滚操作需要的日志文件。它与 ROLLFORWARD 命令的 OVERFLOW LOG PATH 选项相似，但是，不需要对发出的每个 ROLLFORWARD 命令指定 OVERFLOW LOG PATH 选项，可以只设置此配置参数一次。如果同时使用了这两个选项，那么 OVERFLOW LOG PATH 选项将覆盖该前滚操作的 overflowlogpath 配置参数。
如果 logsecond 设置为 -1，那么可以指定一个目录来让 DB2 数据库管理器存储从归档中检索到的活动日志文件。（如果活动日志文件不再存在于活动日志路径中，那么必须检索它们以用于回滚操作）。
如果未指定 overflowlogpath，那么 DB2 数据库管理器会将日志文件检索到活动日志路径中。通过指定此参数，可以提供其他存储器资源让 DB2 数据库管理器放置检索到的日志文件。好处包括将 I/O 成本分布到不同的磁盘上，以及允许将更多的日志文件存储在活动日志路径中。
例如，如果将 db2ReadLog API 用于复制，那么可以使用 overflowlogpath 来指定一个位置让 DB2 数据库管理器搜索此 API 所需的日志文件。如果找不到日志文件（在活动日志路径或溢出日志路径中）并且已配置数据库进行日志归档，那么 DB2 数据库管理器将检索日志文件。还可以使用此参数来指定一个目录来让 DB2 数据库管理器存储检索到的日志文件。好处包括降低活动日志路径上的 I/O 成本以及允许将更多的日志文件存储在活动日志路径中。
当配置无限日志记录（即，将 logsecond 设置为 -1）时，设置 overflowlogpath 非常有用。DB2 数据库管理器可以将从归档中检索的活动日志文件存储在此路径中。（使用无限日志记录，如果活动日志文件不再在活动日志路径中，那么可能需要从归档检索活动日志文件，以进行回滚或崩溃恢复操作。）
如果将原始设备配置为活动日志路径，那么在想要将 logsecond 设置为 -1 或想要使用 db2ReadLog API 时，必须配置 overflowlogpath。
要设置 overflowlogpath，指定一个最长 242 个字节的字符串。该字符串必须指向路径名，并且它必须为标准路径名，而不是相对路径名。该路径名必须是目录，而不是原始设备。
注： 在分区数据库环境中，数据库分区号自动追加在路径后面。这样做是为了维护多逻辑节点配置中路径的唯一性。
主日志文件 (logprimary)
此参数指定将创建的大小为 logfilsiz 的主日志数。
主日志文件，无论是空的还是满的，都需要相同的磁盘空间容量。因此，如果配置的日志多于需要的日志，将会不必要地占用磁盘空间。如果配置的日志太少，可能会遇到日志满载的情况。当选择要配置的日志数时，必须考虑建立的每个日志的大小，以及应用程序是否可以处理日志满载的情况。对活动日志空间的总日志文件大小限制为 256 GB。
如果对现有数据库启用前滚恢复，请将主日志数更改为主日志和辅助日志之和，再加 1。
辅助日志 (logsecond)
此参数指定创建并用于恢复（如果需要）的辅助日志文件的数目。
如果主日志文件已满，可按需要一次分配一个辅助日志文件（大小为 logfilsiz），最多可分配由此参数指定的最大数目。如果此参数设置为 -1，那么将数据库配置为无限活动日志空间。对在数据库上运行的未完成事务的大小或数量没有任何限制。在必须容纳大型作业的环境中（这些作业需要的日志空间比通常分配给主日志的空间多），无限活动日志记录功能非常有用。
注：
- 要将 logsecond 设置为 -1，必须启用日志归档。
- 如果此参数设置为 -1，那么崩溃恢复时间可能会延长，这是因为 DB2 数据库管理器可能需要检索已归档的日志文件。
相关参考:
blk_log_dsk_ful – 磁盘已满时阻止进行日志记录配置参数
db2tapemgr – 管理磁带上的日志文件命令
logarchmeth1 – 主日志归档方法配置参数
logarchmeth2 – 辅助日志归档方法配置参数
logbufsz – 日志缓冲区大小配置参数
logfilsiz – 日志文件大小配置参数
logprimary – 主日志文件数配置参数
logsecond – 辅助日志文件数配置参数
max_log – 每个事务的最大日志配置参数
mincommit – 对组的落实次数配置参数
mirrorlogpath – 镜像日志路径配置参数
newlogpath – 更改数据库日志路径配置参数
num_log_span – 跨越的日志数配置参数
overflowlogpath – 溢出日志路径配置参数
UPDATE DATABASE CONFIGURATION 命令
5.4：通过日志归档管理日志文件
DB2® 服务器日志文件归档因为各种操作系统文件处理问题和安排问题而变得很复杂。例如，如果磁盘在 DB2 数据库管理器对日志文件队列归档时失效，那么这些日志文件及以及它们包含的事务数据可能会丢失。 正确配置数据库记录可以防止这些类型的问题损害可用性和恢复策略。
以下是适用于所有日志归档方法的一般注意事项：
- logarchcompr1 数据库配置参数指定数据库管理器是否压缩 logarchmeth1 所指定的位置中包含的日志文件。如果logarchmeth1 配置参数为 DISK、TSM 或 VENDOR 以外的值，那么日志归档压缩将没有影响，无论 logarchcompr1 配置参数设置为何。
- logarchcompr2 数据库配置参数指定数据库管理器是否压缩 logarchmeth2 所指定的位置中包含的日志文件。如果logarchmeth2 配置参数为 DISK、TSM 或 VENDOR 以外的值，那么日志归档压缩将没有影响，无论 logarchcompr2 配置参数设置为何。
- logarchmeth1 数据库配置参数导致数据库管理器对日志文件归档或在数据库前滚恢复期间检索日志文件（通过使用您指定的方法）。当 ROLLFORWARD 实用程序需要一个在日志路径目录中找不到的日志文件时，会发出检索日志文件的请求。系统从 logpath 配置参数指定的路径对日志文件归档。 logarchmeth2 数据库配置参数导致数据库管理器对日志文件的其他副本归档。如果配置了镜像日志记录，那么系统将从镜像日志路径中获取已归档至 logarchmeth2 参数指定的路径的日志文件。如果未配置镜像日志记录，那么系统将从当前日志路径获取已归档至 logarchmeth2 参数指定的路径的日志文件。
- 如果您要使用下列任何功能，那么不应该使用本地连接的磁带机来存储日志文件：
- 无限日志记录
- 在表空间级别进行联机恢复
- 复制
- db2ReadLog API
- 高可用性灾难恢复 (HADR)
任何这些功能都会导致检索日志文件，从而与日志归档操作相冲突。此外，您不能在 DB2 pureScale® 环境中使用以本地方式连接的磁带机，因为正执行日志合并操作的成员必须检索其他成员的日志。
- 如果正在使用日志归档，那么当活动日志写完时，日志管理器将尝试将它们归档。在某些情况下，如果数据库在日志管理器能够成功记录归档之前被取消激活，那么日志管理器可能会在该数据库被激活时尝试再次归档日志。因此，一个日志文件会多次归档。
- 如果使用归档，那么一个日志文件满时，即使该日志文件仍是活动的且需要用于正常的处理，系统仍会将它传送至日志管理器。此过程允许数据的副本尽快从易丢失数据的介质移出。传递至日志管理器的日志文件保留在日志路径目录中，直到不再需要它用于正常处理为止。这样就复用了磁盘空间。
- 如果日志文件已归档且不包含任何已打开事务，那么 DB2 数据库管理器不会删除该文件但在需要此类文件时将其重命名为下一个日志文件。此过程可改进性能，因为创建新的日志文件（而不是重命名文件）需要写出所有页以保证有必要磁盘空间或有其他存储空间可用。数据库管理器在活动日志路径中保留了多达 8 个额外日志文件以进行重命名。
- 在崩溃恢复的成员崩溃恢复期间（在 DB2 pureScale 环境中）或运行时回滚期间，DB2 数据库管理器不会检索日志文件，除非您将 logsecond 数据库配置参数设置为 -1（即，如果您启用无限日志记录）。在 DB2 pureScale 环境中，在组崩溃恢复期间，数据库管理器可能必须检索已归档日志，即使您未启用无限日志记录也是如此。
- 配置日志归档不保证前滚恢复至故障点，而是仅尝试缩小故障范围。日志文件填满后，日志管理器会对这些日志异步归档。如果日志文件填满之前包含该日志的磁盘失效，那么该日志文件中的数据会丢失。而且，因为这些文件排队等待归档，所以磁盘可能会在复制所有文件之前失效，从而导致队列中的任何日志文件丢失。为有助于避免日志路径所在的磁盘或设备失效而导致日志文件永久丢失，您可以使用 mirrorlogpath 数据库配置参数来确保将这些日志写入第二个路径。如果第二个路径未与主磁盘或设备同时失效，那么可以使用这些日志文件进行恢复。 如果设置了 mirrorlogpath 和 logarchmeth2 配置参数，那么 logarchmeth2 配置参数会对镜像日志路径中的日志文件归档（而不是对当前日志路径中的日志文件的其他副本归档）。在前滚恢复期间，可使用此日志归档行为来提高弹性。原因在于，从镜像日志路径归档的可用日志文件可能仍可用于继续数据库恢复操作，即使当前日志路径中的主日志文件在归档前因为磁盘失效已损坏也是如此。
- 每个日志文件的已配置大小对日志归档有直接影响。如果每个日志文件都非常大，磁盘发生故障时将会丢失大量数据。如果将数据库配置为使用较小日志文件，那么日志管理器会以更高频率对日志归档。 但是，如果您要将数据移到慢速设备（如磁带）上，您可能希望有较大的日志文件以防构建该队列。如果归档每个文件需要大量开销（例如，回绕磁带设备或建立与归档介质的连接），也建议您使用较大日志文件。
- 如果使用日志归档，那么日志管理器会尝试在主日志填满时对其归档。在某些情况下，日志管理器将在日志变满之前对其归档。如果日志文件因为数据库取消激活、您发出 ARCHIVE LOG 命令、到达联机备份结尾或您发出 SET WRITE SUSPEND 命令而截断，那么会发生此情况。 注： 要释放未使用的日志空间，应在对日志文件归档前将其截断。
- 如果要将日志和备份映像归档至磁带机，那么必须确保同一磁带机并非同时是备份映像和已归档日志的目标。因为某些日志归档可能在备份操作进行时发生，所以当这两个进程尝试同时写至同一磁带机时可能发生错误。
在调用用户出口程序或供应商程序来归档或检索日志文件时应注意以下注意事项：
- DB2 数据库管理器在启动用户出口程序来归档日志文件时，以读方式打开该文件。在某些操作系统上，这可防止用户出口程序能删除日志文件。其他操作系统（例如，AIX® 操作系统）允许进程（包括用户出口程序）删除日志文件。用户出口程序在日志文件归档后永远不能删除它，因为该文件可能仍是活动的并且是崩溃恢复所需的。DB2 数据库管理器管理它在对日志文件归档时重复使用的磁盘空间。
- 用户出口或供应商程序可能接收到对不存在的文件进行归档的请求，因为存在许多归档请求并且第一次成功归档操作后该文件会被删除。用户出口或供应商程序还可能接收到检索不存在的文件的请求，因为该文件位于另一目录或到达了日志结尾。在两种情况下，用户出口或供应商程序都应忽略此请求并传递指示成功的返回码。
- 在 Windows 操作系统上，不能使用 REXX 用户出口来归档日志。
- 用户出口或供应商程序应允许时间点恢复后存在同名的不同日志文件。应编写用户出口或供应商程序以保存所有日志文件或将这些日志文件与正确恢复路径相关联。
- 如果对使用同一磁带设备对日志文件归档的两个或更多数据库启用用户出口或供应商程序，并且正在其中一个数据库上执行前滚操作，那么所有其他数据库都不应处于活动状态。如果另一数据库尝试对日志文件归档而前滚操作正在进行，那么可能会发生下列其中一种情况：
- 可能找不到前滚操作所需的日志。
- 归档至磁带设备的新日志文件可能会覆盖先前存储在该磁带设备上的日志文件。
为避免发生任一情况，可执行下列其中一个步骤：
- 可确保在前滚操作期间数据库分区上没有其他数据库调用打开的用户出口程序。
- 可编写用户出口程序以处理此情况。
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/t0011560.html
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/130904.html原文链接：https://javaforall.cn
