ITPub博客

首页 > Linux操作系统 > Linux操作系统 > DB2_体系架构_db2归档模式

DB2_体系架构_db2归档模式

原创 Linux操作系统 作者:fengjin821 时间:2009-07-24 14:16:29 0 删除 编辑

同事在现场遇到问题,环境是AIX + DB2V9.1 + Veritas磁带备份,归档日志文件没有被备份走,因此活动日志目录文件数目越来越大了.

 

  由于没有怎么弄过DB2的归档,因此自己做了一下设置DB2归档的试验,并且看了一下同事发过来的信息,最后我得出的结论是veritas的备份参数文件db2.conf有个参数不对,造成根本没有备份归档日志,只是备份了全库而已,下面是相关的信息文件:
    
文件: 相关信息.rar
大小: 5KB
下载: 下载
 
 
以下是我做的关于DB2归档模式设置的试验,和总结的一些db2归档、备份、恢复的一些知识,以备后用:

1.设置db2归档模式的示例(用logarchmeth1参数)
 
1.1创建数据库,并且修改LOGFILSIZ参数从默认的1000为100,这样每个日志文件大小为100*4K=400K,方便模拟试验
[db2inst1@seagull ~]$ db2sampl
  Creating database "SAMPLE"...
  Connecting to database "SAMPLE"...
  Creating tables and data in schema "DB2INST1"...
  'db2sampl' processing complete.
 
[db2inst1@seagull ~]$ db2 connect to sample
   Database Connection Information
 Database server        = DB2/LINUX 9.1.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLE
 
[db2inst1@seagull ~]$ db2 get db cfg|grep LOG
 Catalog cache size (4KB)              (CATALOGCACHE_SZ) = (MAXAPPLS*4)
 Log buffer size (4KB)                        (LOGBUFSZ) = 8
 Log file size (4KB)                         (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Changed path to log files                  (NEWLOGPATH) =
 Path to log files                                       = /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/
 Overflow log path                     (OVERFLOWLOGPATH) =
 Mirror log path                         (MIRRORLOGPATH) =
 Block log on disk full                (BLK_LOG_DSK_FUL) = NO
 Percent max primary log space by transaction  (MAX_LOG) = 0
 Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0
 Log retain for recovery enabled             (LOGRETAIN) = OFF
 First log archive method                 (LOGARCHMETH1) = OFF
 Options for logarchmeth1                  (LOGARCHOPT1) =
 Second log archive method                (LOGARCHMETH2) = OFF
 Options for logarchmeth2                  (LOGARCHOPT2) =
 Log pages during index build            (LOGINDEXBUILD) = OFF
 
[db2inst1@seagull ~]$ db2 update db cfg for sample using LOGFILSIZ 100
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
[db2inst1@seagull ~]$ db2 connect reset
SQL1024N  A database connection does not exist.  SQLSTATE=08003
[db2inst1@seagull ~]$ db2 connect to sample
   Database Connection Information
 Database server        = DB2/LINUX 9.1.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLE
 
 [db2inst1@seagull ~]$ db2 get db cfg|grep LOGFILSIZ
 Log file size (4KB)                         (LOGFILSIZ) = 100
 
 
1.2 修改logarchmeth1参数,且备份数据库
 
[db2inst1@seagull archive]$ db2 update db cfg for sample using LOGARCHMETH1 DISK:/db2home/db2inst1/archive
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
SQL1363W One or more of the parameters submitted for immediate modification
were not changed dynamically. For these configuration parameters, all
applications must disconnect from this database before the changes become
effective.
[db2inst1@seagull archive]$ db2 connect reset  #特别注意,这里一定要重新连接,否则更改不起作用,我第一次试验就是因为没有重联,结果就是发现归档老是没有成功。
DB20000I  The SQL command completed successfully.
[db2inst1@seagull archive]$ db2 connect to sample
SQL1116N  A connection to or activation of database "SAMPLE" cannot be made
because of BACKUP PENDING.  SQLSTATE=57019
[db2inst1@seagull archive]$ db2 backup database sample to /db2home/db2inst1/backup/
Backup successful. The timestamp for this backup image is : 20080121234435
 
[db2inst1@seagull archive]$ db2 connect to sample
   Database Connection Information
 Database server        = DB2/LINUX 9.1.0
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLE
 
[db2inst1@seagull archive]$ db2 get db cfg|grep LOG
 Catalog cache size (4KB)              (CATALOGCACHE_SZ) = (MAXAPPLS*4)
 Log buffer size (4KB)                        (LOGBUFSZ) = 8
 Log file size (4KB)                         (LOGFILSIZ) = 100
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Changed path to log files                  (NEWLOGPATH) =
 Path to log files                                       = /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/
 Overflow log path                     (OVERFLOWLOGPATH) =
 Mirror log path                         (MIRRORLOGPATH) =
 First active log file                                   = S0000000.LOG
 Block log on disk full                (BLK_LOG_DSK_FUL) = NO
 Percent max primary log space by transaction  (MAX_LOG) = 0
 Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0
 Log retain for recovery enabled             (LOGRETAIN) = OFF
 First log archive method                 (LOGARCHMETH1) = DISK:/db2home/db2inst1/archive/
 Options for logarchmeth1                  (LOGARCHOPT1) =
 Second log archive method                (LOGARCHMETH2) = OFF
 Options for logarchmeth2                  (LOGARCHOPT2) =
 Log pages during index build            (LOGINDEXBUILD) = OFF
[db2inst1@seagull archive]$
 
1.3 模拟事务,测试是否会归档
[db2inst1@seagull archive]$ ls /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/
S0000000.LOG  S0000001.LOG  S0000002.LOG
[db2inst1@seagull archive]$ db2 "insert into staff select * from staff"
DB20000I  The SQL command completed successfully.
 
...重复执行该语句,直到报SQL0964C错误
[db2inst1@seagull archive]$ db2 "insert into staff select * from staff"
DB21034E  The command was processed as an SQL statement because it was not a
valid Command Line Processor command.  During SQL processing it returned:
SQL0964C  The transaction log for the database is full.  SQLSTATE=57011
 
#活动日志目录里面先前的日志文件不见了,只剩下了first active ->current的log,个数正好小于等于logprimary(3) + logseconday(2)
[db2inst1@seagull archive]$ ls /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/
S0000007.LOG  S0000008.LOG  S0000009.LOG  S0000010.LOG  S0000011.LOG
[db2inst1@seagull C0000000]$ db2 get db cfg|grep "First active log file"
 First active log file                                   = S0000007.LOG
 
#可以看到归档目录下已经有了归档文件,且活动日志目录里面的文件被归档后就删除了,归档设置成功!
[db2inst1@seagull C0000000]$ ls
S0000000.LOG  S0000001.LOG  S0000002.LOG  S0000003.LOG  S0000004.LOG  S0000005.LOG  S0000006.LOG
 
此时的LOGRETAIN参数实际还是OFF的,也可以归档,我觉得原因是db2有两种设置归档模式的方法:
1)一种是设置USEREXIT=ON,此时对应的LOGRETAIN必须为ON,归档由USEREXIT指定的用户程序来执行归档
2)另外一种是设置LOGARCHMETH1参数(还有一些相关参数,参考后续介绍),此参数可取值如下
  a.OFF      :表示非归档
  b.LOGRETAIN:等价于将 LOGRETAIN 配置参数设置为 RECOVERY,如果指定此值,将自动更新LOGRETAIN参数
  c.USEREXIT :且等价于将 USEREXIT 配置参数设置为 ON,如果指定此值,将自动更新USEREXIT参数
  d.DISK     :日志文件将在其中归档,
  e.TSM      :将日志文件归档在本地 TSM 服务器上
  f.VENDOR   :指定将使用供应商库来归档日志文件。此值后必须紧跟冒号(:)和库的名称
 
结论:
1)我的试验里,设置了LOGARCHMETH1=DISK:/xx/xx,就可以归档了,LOGRETAIN=OFF或者RECOVERY无所谓
2)如果执行db2 update db cfg for sample using LOGRETAIN=ON,则相应的LOGARCHMETH1从DISK:/xx/xx自动
变成了LOGRETAIN,而不管其原值是什么,此时不会自动归档,必须设置USEREXIT,或者再更新LOGARCHMETH1参数为DISK:/xx/xx
3)更改db cfg后,一定要connect reset,否则可能不起作用
4)不用模拟事务,可以利用db2 archive log for db sample 命令来强制归档,同样可以看到归档是否生效
 
2.db2 事务日志和归档的管理
 
2.1 DB2 事务日志摘要
 
  事务是逻辑工作单元。每一个事务在事务日记文件中都存储有相应的日志记录。每个事务都有一个相应的 Redo Log 条目。Redo Log 条目将写入当前的活动日志文件。当活动日志文件变满时,它将被标记为 unavailable。此时,DB2将接着此活动日志文件另外创建一个日志文件,并继续在其中写入日志条目。当前活动日志文件变满时,DB2 将重复这一循环过程。当事务完成后(发起 COMMIT 或 ROLLBACK 语句),相应的日志条目将被释放,因为不再需要将它们用于恢复数据库。

  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 是一个相当大的表。虽然这一语句看上去没什么问题,每行生成一条删除日记记录,但是如果未经过配置处理它可以轻易地将日志空间填满。

2.2 循环日志

  当循环日志生效时,事务数据将通过循环的方式写入主要日志文件。当存储于某个日志文件中的所有记录都不再需要用于恢复时,该日志文件将被重用,并且可以在以后再次成为活动日志文件。这意味着在循环日志模式中,日志文件的内容最终将被新日志条目重写。由于日志文件的内容被重写覆盖了,因此我们只能将数据库恢复到最后一次完整的数据库备份。不能使用循环日志执行时间点(point-in-time)恢复。

2.3 归档日志

  在归档日志模式中,redo log 条目将写入主要日志文件。但是,与循环日志不同,这些日志文件永远都不可重用。当存储于某个日志文件中的所有记录都不再需要用于恢复时,该日志文件将被标记为非活动 而不是可重用。这意味着它的内容永远都不会被覆盖。当第一个主要日志文件变满时,系统将分配一个新的日志文件,这样主要日志文件的配置数量(LOGPRIMARY 数据库参数)将一直可用。

  与单个事务相关的所有条目必须在活动日志空间中保持一致。如果长时间运行的事务所需要的日志空间大于主要日志文件可以提供的空间,则可能会分配并使用次要日志文件。在归档日志模式中,通过结合使用数据库备份映像和日志文件,我们可以将数据库恢复到具体的时间点。有关此流程的详细描述请参见下文。

   设置了归档模式后,数据库将支持前滚恢复。此时,系统中将会存在三种类型的日志文件:

  •   活动日志:该日志包含尚未提交或回滚的事务单元的相关信息,以及已提交但尚未写入数据库文件的事务的信息。
  •   联机存档日志:活动日志中所有改动对正常处理已不需要,即该日志中所记录的事务都已提交并写入数据库文件时,该活动日志转换为联机存档日志。称之为联机,是由于它们与活动日志存放在同一个目录下。
  •   脱机存档日志:将联机存档日志从活动日志目录下Copy到另外的地方存档,就称为脱机存档日志。这些日志可能在数据库前滚恢复的时候仍然需要。

2.4如何修改日志模式

2.4.1方法一

  创建新的 DB2 数据库时,默认的日志模式为循环日志 。如果希望将日志模式从循环修改为归档,可以执行以下步骤:

  在磁盘上创建一个文件夹(比如说 e:\db_name\archive),磁盘上必须有足够的空间存储归档日志文件。保证归档文件目标文件夹与活动日志文件目标文件夹分开。

  终止与数据库的连接:

  TERMINATE

  更新归档日志文件目标文件夹(为归档日志文件指定路径可以将归档日志模式打开)。

  UPDATE DB CFG FOR db_name USING LOGARCHMETH1 "Disk:e:\db_name\archive"

  重新连接到数据库:

  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_name\backup

  尝试再次连接到数据库。这次应该能够成功。

  CONNECT TO db_name

参考:http://www-1.ibm.com/support/docview.wss?uid=csc13f7a6c7247d1d91048256f39003aee5a 

 2.4.1方法二

 设置LOGRETAIN=ON,且LOGARCHMETH1=USEREXIT,同时USEREXIT=ON,并且要创建好一个名为db2uext2的可执行文件,具体方法略。

 

 

另:有个关于db2的恢复的一个帖子,觉得不错,先保留在这里,有空再做一下试验。

 

文件: DB2 9 数据库恢复简介.rar
大小: 99KB
下载: 下载

 

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

上一篇: db2备份步骤
请登录后发表评论 登录
全部评论

注册时间:2009-04-29

  • 博文量
    191
  • 访问量
    505266