db2的日志管理[转]

问题13、db2日志管理（完成）

---归档日志

db2 update db cfg for dbtest using logretain recovery userexit on

db2 update db cfg for dbtest using logarchmeth1 DISK:D:/DB2/Arch_log

db2 update db cfg for dbtest using logarchmeth2 DISK:D:/DB2/Arch_log2

[@more@]

db2 update db cfg for dbtest using LOGPRIMARY 100 LOGSECOND 50 LOGFILSZ 65535 ;

(此时单个日志文件的大小为:65535 *4K ,可用日志的个数为: 100+50 )

---循环日志

/*Logretaim=Recovery --（Logretaim/userexit两个值任选一个）

userexit=Yes*/

db2 update db cfg for edw using logarchmeth1 off logarchmeth2 off

db2 update db cfg for edw using logretain NO userexit NO

db2 update db cfg for edw using LOGPRIMARY 100 LOGSECOND 50 LOGFILSIZ 65535 ;

(此时单个日志文件的大小为:65535 *4K ,可用日志的个数为: 100+50 )

--重启数据库才生效 （或者断开所有链接）

set instance=db2inst4

db2stop force

db2start

db2 activate db edw

--更改联机日志的路径（更改后logpath的值发生改变）

db2 update db cfg for edw using newlogpath /dw/edwdata/db2log

一.日志概述

任何数据库管理系统都必须拥有确保数据一致性和可恢复性的机制。关系数据库系统为确保那些非常重要的特性所使用的众多机制之一是事务性日志记录。在本文中，我们将定义和讨论事务性日志记录的类型，及如何分配日志文件、如何存储它们。

数据库存储了供应用程序访问和处理的数据。那些应用程序会插入、读取、更新或删除数据。每一个这样的活动都是在一个事务中执行的，该事务被 定义成“应用程序过程中一个可恢复的操作序列”。除非已经提交了事务（也称作“工作单元”），否则它不会影响数据库。

将数据库操作组合到事务中只是确保数据一致性解决方案的一半。另一半是称作预写式日志记录（write-ahead logging）的数据库管理器实现。不管事务是否被提交，只要它们发生，就会记录这些事务。在将任何数据从缓冲池写到数据库结构之前，事务会从日志缓冲区（log buffer）写到 日志文件（事务性日志记录）。用于记录事务的文件叫做 事务日志 。

二.日志分类

DB2 UDB 有两种可用的日志记录类型 — 循环（circular）日志记录和 归档（archive）日志记录。其中归档日志又分为联机归档日志和脱机归档日志。

2.1循环日志记录

循环日志记录是数据库使用的缺省日志记录策略。在此策略中，一旦日志目录中最后一个主日志文件被写满了，就会将新的事务写到第一个日志文件中，从而覆盖现有的日志数据。这些新事务会继续依次覆盖每个旧日志文件。这种日志记录方法确保了所有已提交事务的数据一致性，这样就可以执行应急恢复。

循环日志记录通常在数据仓库环境中使用，在该环境中，恢复数据库需要的只是恢复数据库映象的问题。该策略不应该用在线事务处理（on-line transaction processing，OLTP）环境，因为它不可能进行前滚恢复。

2.2归档日志记录

与循环日志记录相比，当最后一个日志文件写满时，归档日志记录过程会创建一个新的日志文件，这样将来的事务就不会覆盖现有的日志文件。当初始化数据库时，系统会在活动日志目录中分配一定数量、指定大小的主日志文件。这个数量由数据库配置参数控制。当主日志文件都写满时，就会“根据需要”创建辅助日志文件，直到创建了最大数量的辅助日志文件为止。一旦达到了这个数量，如果需要附加的日志空间，就会发出一个错误，指出没有更多的可用日志文件，所有数据库活动停止。

利用归档日志记录，就可能采取联机(在线)数据库备份，在执行这一操作期间，会继续记录数据库活动。如果数据库崩溃或发生故障，就会使用全备份映象，然后执行使用归档日志的前滚操作，通过前滚到日志结尾，将数据库恢复到时间点状态或最近的一致状态，从而恢复数据库。

有两种归档日志：

联机归档日志: 活动日志中所有改动对正常处理已不需要，即该日志中所记录的事务都已提交并写入数据库文件时，该活动日志转换为联机归档日志。称之为联机，是由于它们与活动日志存放在同一个目录下。

脱机归档日志: 将联机归档日志从活动日志目录下Copy到另外的地方存档，就称为脱机归档日志。这些日志可能在数据库前滚恢复的时候仍然需要。

三．日志相关参数

我们只有弄清楚了日志相关的参数之后，才能正确修改配置参数，得到我们想要的日志管理模式，现对各参数介绍如下：

3.1 LOGRETAIN

缺省情况下，logretaim的值为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表示数据库的状态。

注：数据库管理器每次写一个事务日志。可以是活动状态的事务的总大小受数据库配置参数限制：

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7490392/viewspace-1059314/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7490392/viewspace-1059314/