DB2日志原理

主日志文件和辅助日志文件

主日志文件是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件是在需要时动态分配的。下面是相关的一些数据库配置参数：

参数	用途
LOGPRIMARY	表明要分配的主日志文件的数量
LOGSECOND	表明可以分配的辅助日志文件的最多数量
LOGFILSIZ	用于指定一个日志文件的大小（4KB页的个数）

 

例如，一个数据库配置文件中参数如下：

日志文件大小（4KB）                         (LOGFILSIZ) = 1024

主日志文件的数目                           (LOGPRIMARY) = 3

辅助日志文件的数目                          (LOGSECOND) = 2

日志文件路径                            = D:\DB2\NODE0000\SQL00001\SQLOGDIR\

假定执行以下事务，该事务将插入一百万条记录：

Insert into table1 values(1);

Insert into table1 values(2);

…

Insert into table1 values(1,000,000);

Commit;

DB2将填充第一个日志文件，然后继续填充第二个日志文件，然后再填充第三个日志文件。当填满第三个日志文件时，就没有主日志文件了，于是DB2动态地分配第一个辅助日志文件。因为LOGSECOND是大于0的，当这个辅助日志文件被填满时，DB2将继续分配另一个辅助日志文件，一直重复这个过程，直到分配的辅助日志文件数量达到最大值LOGSECOND。对于本例，当DB2尝试分配第三个辅助日志文件时，将返回一个错误，表明事务已用完日志空间。这时事务将回滚。

 

=============================================

这与Oracle不同。Oracle DBWR是否将data buffer写入datafile与事务是否提交无关。LGWR将redo log buffer写入log也与事务是否提交无关。只是LGWR优先DBWR写。

Oracle中，LGWR在下列情况下写：

l     事务提交（commit）；

l     每3秒写一次；

l     当redo log buffer用到三分之一时；

l     当DBWRn 进程写buffer中的数据到数据文件中时。

DBWR在下列情况下写：

l     When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers, it signals DBW n to write.

l     DBWRn  periodically writes buffers to advance the  checkpoint.（检查点大约3秒一次，所以DBWR每3秒写一次。所有引起执行检查点的动作也会触发DBWR写）。

Oracle中的commit命令：

在事务commit之前，下面的就已经发生了：

l     Oracle生成undo，undo包含了事务修改的数据的旧值；

l     在redo log buffer中产生redo信息，redo记录了data block的改变和rollback block的改变。redo log buffer中的这些信息可能在事务commit之前写入disk。

l     在database buffer中修改了数据，这些修改可能在事务commit之前被写入disk。

事务commit，发生了下列事情：

l     undo表空间中与事务相关的内部表记录事务的commit，产生SCN，并在这些表中记录；

l     LGWR将redo log buffer中redo信息写入redo log file。并在redo log file中写入相应的SCN；

l     释放rows和tables上的锁；

l     Oracle标记事务完成。

======================================================

DB2中不存在独立的undo，而是将undo信息也记录在日志文件中。事务不提交的情况下，不会将日志归档或是覆盖日志文件。这就导致了上面的事务挂起的情况。如果使用无限日志记录模式，DB2会在一个日志被填满时立即归档而不等到所有的事务都已经被提交且具体化时才归档。这样可以保证活动日志目录永远不会被填满。

 

 

日志的类型：

活动日志：如果以下两个条件之一得到满足，则一个日志被认为是活动的（active）：

l     它包含尚未被提交或回滚的事务信息。

l     它包含已经被提交但其更改还没有被写到数据库磁盘的事务的信息。

在线归档日志：包含被提交且具体化的事务的信息。这些日志与活动日志放在相同的目录中。

离线归档日志：已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成，也可以由 DB2 自动完成。

 

 

日志记录类型：循环日志记录和归档

循环日志记录

类似于Oracle的 noarchivelog模式。

循环日志记录是 DB2 默认的日志记录模式。顾名思义，这种类型的日志记录以循环的模式重用日志。例如，如果有四个主日志，DB2 将按照以下顺序使用它们：Log #1，Log #2，Log #3，Log #4，Log #1，Log #2，依此类推。

在循环日志记录模式下，只要一个日志只包含已提交且 被具体化到数据库磁盘上的事务的信息，那么它就可以被重用。换句话说，如果日志仍然是活动日志，那么它就不能被重用。

 

归档日志记录

当使用归档日志记录模式时，您要经常归档（保留）日志。在循环日志记录模式下，已提交且被具体化的事务将被覆盖，而在归档日志记录模式下，这些事务将得到保留。例如，如果有 4 个主日志文件，DB2 将按照以下顺序使用它们：Log #1，Log #2，Log #3，Log #4，（如果 Log #1 的所有事务已被提交且具体化，则归档 Log #1），Log #5（如果 Log #2 的所有事务已被提交且具体化，则归档 Log #2），Log #6，依此类推。

 

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF（默认值）时，归档日志记录被禁用，循环日志记录被启用。

为了启用归档日志记录，可以将 LOGARCHMETH1 设置为以下值中的任何一个值：

LOGRETAIN	日志文件将被保留在活动日志目录中
USEREXIT	日志的归档和检索是由用户提供的用户出口程序自动执行的，这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中，或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时，这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下，db2uext2 必须存储在 sqllib\bin 目录中，在 UNIX 下，db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name	与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序，而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name]	与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数，则使用默认的管理类
VENDOR:library_name	与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因，数据库配置文件仍然包含参数 LOGRETAIN 和 USEREXIT。从 8.2 版开始，这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXIT 或 LOGRETAIN 参数，那么 LOGARCHMETH1 将自动被更新，反之亦然。

 

无限日志记录

不管是使用循环日志记录还是归档日志记录，日志空间都可能被填满活动日志。如果启用无限日志记录，DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如，如果有一个长时间运行的事务，在启用无限日志记录模式的情况下，就不会出现日志空间被耗尽的情况。

要启用无限日志记录：

1.  将 LOGSECOND 数据库配置参数设置为 -1。

2.  启用归档日志记录。

 

 

 

 

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

转载于:http://blog.itpub.net/25744374/viewspace-750126/