DB2重定向恢复和前滚常见问题解析

p>DB2重定向恢复和前滚常见问题解析

p> 

p>前言 

p>数据库管理和维护工作中一项重要的内容就是对数据库进行定期的备份和恢复。这种工作的重要性除了表现在数据的保全，系统的容灾方面，还表现在为应用系统的开发和测试搭建数据库环境。 

p>设想在一个不断更新升级的应用环境中，数据库的数据在不断的更新，程序开发人员也在不断开发新的版本，建立测试数据和环境，对应用进行测试，再发布到生产环境下。这样，对于一个高复杂性的应用，使用生产环境中的真实数据来建立测试环境就变成了合理的选择。当然，在使用真实数据之前，为了保护公司利益可能需要删除或修改一些敏感的数据。 

p>在上述场景下，数据库管理员就要根据项目开发的要求，把生产环境的数据复制到开发和测试环境。数据库重定向恢复技术就提供了一个比较快的方式帮助管理员完成这项工作。 

p>本文针对哪有对 DB2 恢复有初步知识的读者，重点讨论在重定向恢复和前滚的过程当中经常碰到的问题，并通过一些实际应用中遇到的问题，探讨如何事先避免以及问题发生之后的解决办法。 

p> 

p>DB2 重定向恢复和前滚知识简介 

p>从上一节假定的场景中，我们知道 DB2 重定向恢复常用于在不同的环境中进行数据库的恢复。这些环境的不同就会给重定向恢复造成一些麻烦。比如：生产环境的内存通常比测试环境的都要大，生产环境中给事物日志分配的空间也要大一些，另外，最明显的区别就是测试环境中表空间的位置和原来在生产环境上不一样了。对于这些区别，提前了解和掌握以后就有助于预防和解决在数据库恢复时遇到的问题。下面就分别介绍重定向恢复和前滚的操作方法和相关命令。 

p>自动生成重定向恢复脚本以及重定向恢复状态查询 

p>DB2 提供了命令，供用户从一次数据库备份文件中提取数据库重定向恢复脚本。示例如下，其中 /db2_backup/db2inst1/sample 是数据库备份文件所在的目录，20101023180128 是数据库备份文件的时间戳。 

p>db2 restore db sample from /db2_backup/db2inst1/sample taken at 20101023180128 

p>redirect generate script redirect_sample.sql 

p>DB20000I The RESTORE DATABASE command completed successfully. 

p> 

p>所生成的重定向文件 redirect_sample.sql，可以分为三个部分： 

p>1. Restore 语句 

p>此语句用来标示一个重定向的恢复操作命令开始，它在普通恢复的命令上加了 redirect 参数。 

p>RESTORE DATABASE SAMPLE 

p>FROM '/db2_backup/db2inst1/sample' 

p>TAKEN AT 20101023180128 

p>INTO SAMPLE 

p>REDIRECT; 

p> 

p>2. set containers 语句： 

p>当目标数据库所的物理存储设备与原来的数据库不一样时，就需要下面的命令来指定新的物理容器。 

p>SET TABLESPACE CONTAINERS FOR 0 

p>USING ( 

p>  PATH '/db2inst1/SAMPLE' 

p>); 

p>SET TABLESPACE CONTAINERS FOR 1 

p>USING ( 

p>  PATH '/ db2inst1/temp' 

p>); 

p>SET TABLESPACE CONTAINERS FOR 2 

p>USING ( 

p>  DEVICE '/dev/rsample_1G' 131072 

p>); 

p>…… 

p> 

p>3. restore continue 语句： 

p>此语句代表重定向恢复语句序列完成，系统开始恢复数据库。 

p>RESTORE DATABASE SAMPLE CONTINUE; 

p> 

p>在数据库进行恢复的过程中，我们可以通过 list utilities 命令查看 restore 的状态。示例如下： 

p>db2 list utilities show detail 

p> 

p>ID = 4 

p>Type = RESTORE 

p>Database Name = SAMPLE 

p>Partition Number = 0 

p>Description = db 

p>Start Time = 10/24/2010 13:49:17.515893 

p>State = Executing 

p>Invocation Type = User 

p>Progress Monitoring: 

p>  Completed Work = 2938126336 bytes 

p>  Start Time = 10/24/2010 13:49:17.515898 

p> 

p>其中的 Completed Work 代表已完成的数据量，与备份文件的大小比较可以估算出大概的完成时间。 

p>常用前滚命令 , 所需日志文件的确定以及状态查询 

p>前滚命令多种多样，这里不一一列举。最常用的语句就是 rollforward to 和 rollforward complete。 

p>例如，使用指定目录的日志文件，前滚到某一时刻点： 

p>rollforward db sample to 2010-11-21-17.00.00.000000 

p>using local time overflow log path ( /db2_backup/sample/logs ) 

p> 

p>前滚结束： 

p>rollforward db sample complete overflow log path ( /db2_backup/sample/logs ) 

p> 

p>最有效的查询 rollforward 状态的语句： 

p>db2 rollforward db db_name query status 

p> 

p>例如，restore 成功结束，rollforward 还没有开始，查看状态会得到类似结果： 

p>db2 rollforward db sample query status 

p> 

p>  Rollforward Status 

p> 

p>Input database alias = sample 

p>Number of nodes have returned status = 1 

p> 

p>Node number = 0 

p>Rollforward status = DB pending 

p>Next log file to be read = S0001519.LOG 

p>Log files processed = - 

p>Last committed transaction = 2010-10-23-08.41.52.000000 UTC 

p> 

p>我们可以得知，rollforward 要读取的下一个日志文件是 S0001519.LOG。 

p>在数据库前滚的过程中，我们也可以通过 list utilities 查看前滚的状态。 

p>$ db2 list utilities show detail 

p> 

p>ID = 5 

p>Type = ROLLFORWARD RECOVERY 

p>Database Name = SAMPLE 

p>Partition Number = 0 

p>Description = Database Rollforward Recovery 

p>Start Time = 10/25/2010 01:45:44.392021 

p>State = Executing 

p>Invocation Type = User 

p>Progress Monitoring: 

p>  Phase Number [Current] = 1 

p>  Description = Forward 

p>  Completed Work = 824384727 bytes 

p>  Start Time = 10/25/2010 01:45:44.392051 

p> 

p>  Phase Number = 2 

p>  Description = Backward 

p>  Completed Work = 0 bytes 

p>  Start Time = Not Started 

p> 

p> 

p>DB2 重定向恢复常见问题解析 

p>在 DB2 重定向恢复的三个阶段中，错误常常发生在第二阶段，也就是 set tablespace containers 的时候。在这里列举了一些常见的错误，和这些错误的解决方法及预防。供大家参考。 

p>对裸设备类型的容器，大小计算错误 

p>命令及结果： 

p>db2 set tablespace containers for 8 using( DEVICE '/dev/rsample_1G' 262144 ) 

p>SQL1422N The size of the container is invalid. SQLSTATE=54039 

p> 

p>解决方法以及预防： 

p>容器大小 262144 不正确。结合 lslv 的检查结果和表空间的 pagesize，重新计算容器大小。 

p>lslv rsample_1G 

p>LOGICAL VOLUME: rsample_1G  VOLUME GROUP: datavg3 

p>LV IDENTIFIER: 00c790ea00004c000000011fb9a36069.112 PERMISSION: read/write 

p>VG STATE: active/complete 

p>LV STATE: opened/syncd 

p>TYPE: raw 

p>WRITE VERIFY: off 

p>MAX LPs: 512 

p> 

p>PP SIZE: 64 megabyte(s) 

p>COPIES: 1 

p>SCHED POLICY: parallel 

p>LPs: 16  

p>PPs: 16 

p>STALE PPs: 0 

p>BB POLICY: relocatable 

p>INTER-POLICY: minimum 

p>RELOCATABLE: yes 

p>INTRA-POLICY: middle 

p>UPPER BOUND: 1024 

p>MOUNT POINT: N/A 

p>LABEL: None 

p>MIRROR WRITE CONSISTENCY: on/ACTIVE 

p>EACH LP COPY ON A SEPARATE PV ?: yes 

p>Serialize IO ?: NO 

p>DEVICESUBTYPE : DS_LVZ 

p> 

p>计算公式如下：PPs * PP Size / pagesize 

p>此处，pagesize 按照８ K 计算 。 

p>db2 set tablespace containers for 8 using( DEVICE '/dev/rsample_1G' 131072 ) 

p>DB20000I The SET TABLESPACE CONTAINERS command completed successfully. 

p> 

p>指定的容器，已经被使用了 

p>命令及结果： 

p>db2 set tablespace containers for 64 using( DEVICE '/dev/rsample_4G' 524288 ) 

p>SQL0294N The container is already in use. SQLSTATE=42730 

p> 

p>解决方法以及预防： 

p>通过 lslv 检查裸设备的状态，注意其中 LV STATE 的值。如果是 opened/syncd，意味着这个容器正在被其他的系统占用。如果是 closed/syncd，就可能是可用的设备。这里说“可能”是因为有些时候，比如数据库停掉以后，它所使用的所有的裸设备就都是 closed/syncd 状态，但如果这时其他应用使用了这个裸设备，就会让这个数据库受损。所以在使用前一定要确认，没有其他系统在使用这个裸设备。 

p>DB2 在使用一个裸设备的时候会设置一些标志位，表明哪一个实例的数据库正在使用这个裸设备。但是当 DB2 删除一个表空间或者其中一个容器的时候，有时候这些标志位不会被清空，这时候虽然没有其他的数据库在使用这个设备，依然会出现上面的错误。在确认没有其他系统使用之后，就可以用下面的 DB2 命令手动清空这些标志位。 

p>db2untag -f /dev/rsample_4G 

p> 

p>指定的容器类型，与原有容器不一致 

p>命令及结果： 

p>db2 set tablespace containers for 3 using( PATH '/db2inst1/SAMPLE/TBS/SYSTOOL’) 

p>SQL0298N Bad container path. SQLSTATE=428B2 

p> 

p>解决方法以及预防： 

p>原有容器是 FILE 类型，如果在重定向恢复的时候指定为 PATH，就会报错。 

p>修改后： 

p>db2 set tablespace containers for 3 

p>using( File '/db2inst1/SAMPLE/TBS/SYSTOOL.DAT' 100 ) 

p>DB20000I The SET TABLESPACE CONTAINERS command completed successfully. 

p> 

p>指定的容器名发生错误 

p>命令及结果： 

p>db2 set tablespace containers for 106 

p>using( DEVICE '/dev/dev/rsample_500M' 65536 ) 

p>SQL0298N Bad container path. SQLSTATE=428B2 

p> 

p>解决方法以及预防： 

p>确保容器名及路径的正确性。 

p>db2 set tablespace containers for 106 

p>using( DEVICE '/dev/rsample_500M' 65536) 

p>DB20000I The SET TABLESPACE CONTAINERS command completed successfully. 

p> 

p>Restore db continue 的时候发生错误，数据库恢复目录满 

p>db2 restore db sample continue 

p>SQL2544N The directory where the database is being restored has become full. 

p> 

p>解决方法以及预防： 

p>检查包含 PATH 的语句， 

p>set tablespace containers for 0 using( 

p>  PATH '/db2inst1/SAMPLE' 

p>) ; 

p> 

p>可能的原因： 

p>目录 /db2inst1/SAMPLE 满了。 

p>重点检查 SMS 表空间所在目录的使用情况。更换或者扩充文件系统。也可以通过 db2diag.log 文件得到更详细的信息。 

p> 

p>前滚常见问题解析 

p>运行 rollforward 时，日志文件缺失 

p>命令及结果： 

p>db2 "rollforward db sample to 2010-10-24-17.00.00 

p>using local time overflow log path (/db2_backup/db2inst1/logs)" 

p> 

p>SQL4970N Roll-forward recovery on database "SAMPLE" cannot reach the specified 

p>stop point (end-of-log or point-in-time) on database partition(s) "0". 

p>Roll-forward recovery processing has halted on log file "S0102805.LOG". 

p> 

p>错误日志（db2diag.log）： 

p>2010-11-23-03.03.17.731773-300 I2966741A419 LEVEL: Error 

p>PID : 1089734 TID : 2615 PROC : db2sysc 0 

p>INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 

p>EDUID : 2615 EDUNAME: db2loggr (SAMPLE) 0 

p>FUNCTION: DB2 UDB, data protection services, sqlpgasn, probe:650 

p>RETCODE : ZRC=0x801000BB=-2146434885=SQLPR_MISSING_LOGFILES 

p>"rollforward missing log files" 

p> 

p>解决方法以及预防： 

p>从备份磁盘获取所需的日志文件。然后再次运行 rollforward 命令。 

p>也可以通过以下命令来提前准备所需日志文件，避免出错。可以从“Start Time”和“End Time”判断 rollforward 到某个时间点所需的最后的一个日志文件。 

p>db2 list history archive log since 20101023040030 for sample | more 

p>  List History File for sample 

p>Number of matching file entries = 30 

p>Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID 

p>-- --- -------- ---- --- ------- ------- -------- 

p>  X D 20101023045856 1 U S0102805.LOG C0000000 

p>------------------------------------------- 

p>------------------------------------------- 

p>  Comment: 

p>Start Time: 20101023045856 

p>  End Time: 20101026033936 

p>  Status: A 

p>------------------------------------------- 

p> 

p>运行 rollforward complete 时，活动日志空间满 

p>命令及结果： 

p>db2 "rollforward db sample complete overflow log path /db2_backup/db2inst1/logs)" 

p>SQL1004C There is not enough storage on the file system to process the command. 

p> 

p>错误日志（db2diag.log）： 

p>2010-10-27-23.06.28.470787-240 I172869537A496 LEVEL: Error 

p>PID : 1970552 TID : 5655 PROC : db2sysc 0 

p>INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 

p>APPHDL : 0-61 APPID: *LOCAL.db2inst1.101028030442 

p>AUTHID : DB2inst1 

p>EDUID : 5655 EDUNAME: db2agent (SAMPLE) 0 

p>FUNCTION: DB2 UDB, recovery manager, sqlpForwardRecovery, probe:2610 

p>RETCODE : ZRC=0x850F000C=-2062614516=SQLO_DISK "Disk full." 

p>  DIA8312C Disk was full. 

p> 

p>解决方法以及预防： 

p>修改数据库配置参数 NEWLOGPATH，指定空间更大的目录作为活动日志目录。然后再次运行 rollforward 命令。 

p>db2 update db cfg for sample using NEWLOGPATH /db2_backup/db2inst1_log01/sample 

p> 

p> 

p>或者提前修改 redirect restore 命令，在做数据库恢复的时候就指定更大的目录作为活动日志目录。这样可以避免在 rollforward 的过程中遇到问题。 

p>db2 "restore db sample \ 

p>  from /db2_backup/db2inst1/backup \ 

p>  taken at 20101023084025 newlogpath /db2_backup/db2inst1_log01/sample \ 

p>  redirect" 

p> 

p> 

p>与缓冲池相关的错误 ,解决方法以及预防 

p>命令及结果： 

p>db2 "rollforward db sample to 2010-11-21-17.00.00.000000 

p>using local time overflow log path ( /db2_backup/db2inst1/SAMPLE/logs ) " 

p>SQL1218N There are no pages currently available in bufferpool "". 

p>SQLSTATE=57011 

p> 

p>错误日志（db2diag.log）： 

p>2010-11-24-05.19.14.842891-300 I67571A941 LEVEL: Error 

p>PID : 296330 TID : 75304 

p>PROC : db2sysc 0 

p>INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 

p>APPHDL : 0-27 APPID: *LOCAL.db2inst1.101124101914 

p>AUTHID : DB2INST1 

p>EDUID : 75304 EDUNAME: db2agent (SAMPLE) 0 

p>FUNCTION: DB2 UDB, SQO Memory Management, SqloMemController::registerConsumer, p 

p>robe:1000 

p>MESSAGE : ZRC=0x8B0F0000=-1961951232=SQLO_NOMEM "No Memory Available" 

p>  DIA8300C A memory heap error has occurred. 

p> 

p>解决方法以及预防： 

p>这里的错误是源数据库设置的缓冲区太大，目标数据库所在系统无法支持。我们可以修改参数值 DB2_OVERRIDE_BPF，强制 DB2 采用较小的缓冲区。重启实例后，再次执行 rollforward 操作。 

p>db2set DB2_OVERRIDE_BPF=500 （500 为假定值） 

p> 

p>与表空间状态相关的错误，解决方法以及预防 

p>LOAD 操作可能会对 rollforward 造成一定的影响。有时候在 rollforward 的过程中需要交互操作。如果选择 (t)，会造成表空间的状态不正常。 

p>命令及结果： 

p>db2 "rollforward db sample to 2010-11-19-17.00.00 

p>using local time overflow log path ( /db2_backup/db2inst1/logs )" 

p> 

p>SQL3799W Load recovery for table "TEST .WORK_DETAIL" at time 

p>"20101116221501" on node "0" is pending due to warning "-2061" with additional 

p>information "/dev/null". 

p>Do you want to continue(c),terminate this device only(d),abort the utility(t) ? 

p> 

p>错误日志（db2diag.log）： 

p>2010-11-24-11.15.39.678474-300 I806561A381 LEVEL: Warning 

p>PID : 2126036 TID : 1 PROC : db2redom (SAMPLE) 0 

p>INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 

p>APPHDL : 0-668 APPID: *LOCAL.db2inst1.081124154042 

p>FUNCTION: DB2 UDB, recovery manager, sqlpRecDbRedo, probe:2129 

p>MESSAGE : Tablespace 27 in restore pending state. 

p> 

p>解决方法以及预防： 

p>我们可以查看某一备份时刻之后的 LOAD 操作情况。 

p>db2 list history backup since 20101120170928 for sample | more 

p> 

p>如果出现了 rollforward 造成的表空间不可用。我们可以进行相应的表空间恢复。或者删除、重建相应的表空间，并导入数据。 

p>与表状态相关的错误，解决方法以及预防 

p>在数据库 restore 和 rollforward 完成之后，检查每个数据表的状态时，可能会发现有的数据表状态不可用。简单的方法是过滤 db2diag.log 文件，找出类似下面的错误信息。 

p>错误日志（db2diag.log）： 

p>2010-11-26-08.01.51.170966-300 E21515A743 LEVEL: Warning 

p>PID : 3104786 TID : 26364 PROC : db2sysc 0 

p>INSTANCE: db2inst1 NODE : 000 DB : SAMPLE 

p>APPHDL : 0-380 APPID: *LOCAL.db2inst1.101126125907 

p>AUTHID : DB2INST1 

p>EDUID : 26364 EDUNAME: db2redom (SAMPLE) 0 

p>FUNCTION: DB2 UDB, data management, sqldMarkObjInErr, probe:1 

p>MESSAGE : ADM5571W DB2 is marking the "DATA" object with id "141" in 

p>  tablespace "8" for table "TBSPACEID=8.TABLEID=141" unavailable. 

p>  Either the table will have to be dropped, or if the object is part of 

p>  a partitioned table the partition in error can be detached or the 

p>  index in error can be dropped. 

p> 

p>解决方法以及预防： 

p>一般情况下，我们需要删除并重建这些数据表。必要的情况下，我们可以从其他环境或备份进行数据恢复。 

p> 

p>结束语 

p>本文列举了一些 DB2 重定向恢复中经常出现的问题及解决办法，希望能帮助读者解决一些实际工作当中碰到的情况。