[求助]从磁带db2 restore一直失败，请高手指点。。。

zero_dot

我的数据库是：V8.2 FixPak9a 的，OS：AIX 5200-05
数据库是归档模式的，数据量300G，2 盒IBM 72G 的 4mm 磁带搞定
备份时用：db2 backup db xxx online to /dev/rmt0

现在要在基本同样环境的机器上恢复。DB2 V8.2 FixPak9a 一样，OS：AIX 5300-03
恢复命令为：db2 restore database xxx from /dev/rmt0

问题出现了：
当恢复进行到2小时左右，好像也不像读到第一盘带尾的时候，恢复就什么提示都没有就停掉了。查看db2diag.log报restore terminated，前面恢复过程生成的文件都回滚删除干净了，真是痛心啊。。。
刚开始以为是磁带有问题，于是又找了前一份的备份来恢复，情况一样。
于是用db2ckbkp /dev/rmt0来检查备份，一样，检查了2小时左右，就罢工了，什么提示也都没有。。。

郁闷啊。。。。。。。。。。。。捣腾了无数趟，花了2天时间了。db2diag.log也发给ibm 800的工程师看过，也没看出也价值的信息。惨啊。。。
不知道那位大哥有这方面的丰富经验。请多提意见。。。。。。
那位大哥要对db2diag.log有兴趣的话，偶也可以贴个千八百行什么的出来 C C 。。。

[ 本帖最后由 zero_dot 于 2006-6-5 23:07 编辑 ]

zero_dot

晕，只有人看，没人回。。。
各位老大，不吝赐教啊。。。

大梦

数据库版本一样，是不是因为操作系统版本不一样的问题？

你可以在AIX5.2上建一个测试数据库，备份到文件系统，不用TAPE，再到AIX5.3上恢复试试，若这样都不成功，可能是操作系统的问题！若能成功，请用db2ckbkp检查一下你的备份介质看看！

大梦

如何使用db2ckbkp命令查看DB2数据库备份的类型




环境 产品：DB2 UDB
平台：平台无关
版本：V7.1 及以后版本

问题 如何使用db2ckbkp命令查看DB2数据库备份的类型？


解答 db2ckbkp命令不仅可以用来检查DB2数据库备份文件的完整性，而且还可以用来查询DB2数据库备份文件的元数据，如果我们有一些备份文件，但是不知道备份的类型，我们可以使用db2ckbkp -H <备份文件>来检查DB2数据库备份的类型：
如在我们的目录中有如下几个备份文件：
D:\Temp\SAMPLE.0\DB2\NODE0000\CATN0000\20041025>dir
驱动器 D 中的卷是 Data
卷的序列号是 2094-E2AA

D:\Temp\SAMPLE.0\DB2\NODE0000\CATN0000\20041025 的目录
2004-10-25 10:28 下午 36,212,736 222808.001
2004-10-25 10:30 下午 29,929,472 223024.001
2004-10-25 10:33 下午 24,944,640 223239.001
2004-10-25 10:34 下午 36,212,736 223408.001
我们想检查一下文件2223024.001的备份类型，可以使用如下命令：
D:\Temp\SAMPLE.0\DB2\NODE0000\CATN0000\20041025>db2ckbkp -H 223024.001


=====================
MEDIA HEADER REACHED:
=====================
Server Database Name -- SAMPLE
Server Database Alias -- SAMPLE
Client Database Alias -- SAMPLE
Timestamp -- 20041025223024
Database Partition Number -- 0
Instance -- DB2
Sequence Number -- 1
Release ID -- A00
Database Seed -- 41FDD448
DB Comment's Codepage (Volume) -- 0
DB Comment (Volume) --
DB Comment's Codepage (System) -- 0
DB Comment (System) --
Authentication Value -- 255
Backup Mode -- 1
Includes Logs -- 0
Compression -- 0
Backup Type -- 0
Backup Gran. -- 0
Status Flags -- 11
System Cats inc -- 1
Catalog Partition Number -- 0
DB Codeset -- GBK
DB Territory --
LogID -- 1098714476
LogPath -- C:\DB2\NODE0000\SQL00001\SQLOGDIR\
Backup Buffer Size -- 4984832
Number of Sessions -- 1
Platform -- 5

The proper image path would be:
SAMPLE.0\DB2\NODE0000\CATN0000\20041025\223024.001


Image header dumped -- NO VERIFICATION PERFORMED.

我们可以通过上述输出中的Backup Mode, Backup Type 和Backup Gran.来确定备份的类型，三个关键字的说明如下：
Backup Mode 0 - offline（脱机备份）, 1 - online（联机备份）
Backup Type 0 - full（全备份）, 3 - tablespace（表空间级备份）
Backup Gran. 0 - normal（正常备份）, 16 - incremental（增量备份）, 48 - delta（增量delta备份）
其中incremental（增量备份）和delta（增量delta备份）的说明如下：
Incremental（增量备份）： 增量备份映像是自从上次最新的、成功的完全备份操作以来，更改过的所有数据库数据的副本。也称为累积备份映像，因为进行的一系列增量备份中的每一个都会有上次增量备份映像的内容。增量备份映像的前身通常是同一对象最新的、成功的完全备份。
Delta（增量delta备份）： delta 备份映像或增量 delta 备份映像是自从上次相关表空间的成功备份（包括完整、增量或 delta 备份）以来，已更改过的所有数据库数据的副本。也称为差异备份映像或非累积备份映像。delta 备份映像的前身是最新的成功备份，包括 delta 备份映像中每个表空间的备份。

明确了上述数字的含义后，我们就可以很容易地辨别上述备份文件是属于“联机全备份”：
Backup Mode -- 1 （联机备份）
Backup Type -- 0 （全备份）
Backup Gran. -- 0 （正常备份）

zero_dot

原帖由 大梦 于 2006-6-7 09:18 发表
数据库版本一样，是不是因为操作系统版本不一样的问题？

你可以在AIX5.2上建一个测试数据库，备份到文件系统，不用TAPE，再到AIX5.3上恢复试试，若这样都不成功，可能是操作系统的问题！若能成功，请用db2ckbk ...

db2ckbkp 早做过了，跟备份一样，读到那个点。就歇菜了。。。进程都没了。。。
我拿了3份备份做过检查和恢复了，都是一样在2小时多1、2分钟的时候出错。
2006-06-02-11.48.54
2006-06-02-13.50.09

2006-06-02-16.19.46
2006-06-02-18.20.50

2006-06-05-16.07.23
2006-06-05-18.10.23

2006-06-06-06.45.23
2006-06-06-08.46.36

2006-06-06-12.57.29
2006-06-06-15.00.25

太邪门了吧。。不可能3份磁带都在这个点有问题吧。。。
不知道是不是磁带机有差异，主机上写的，备机的磁带机读不了。
主备机的磁带机的配置参数我也都检查过了。一样的呀。。。。

不过你提的OS的差异我可以试试，谢谢提醒。。有结果再贴出来。。

mymm

磁带机的型号一样吗？BLOCK大小一样吗？
如果有足够的HD空间，用tctl把数据转存出来再用db2ckbkp检查一下!

zero_dot

这是主机上的磁带机的信息：
YX-DB:/#lscfg -vl rmt0
  rmt0             U787B.001.DNW400C-P1-T14-L1-L0  LVD SCSI 4mm Tape Drive (36000 MB)

        Manufacturer................IBM     
        Machine Type and Model......DDS Gen5        
        Device Specific.(Z1)........V315
        Serial Number...............204C8035
        Device Specific.(LI)........A170029F
        Part Number.................18P8777
        FRU Number..................18P8779     
        EC Level....................H80564   
        Device Specific.(Z0)........0180020283000130
        Device Specific.(Z3)........L1  

YX-DB:/#lsattr -El rmt0
block_size    1024  BLOCK size (0=variable length)       True
compress      yes   Use data COMPRESSION                 True
density_set_1 71    DENSITY setting #1                   True
density_set_2 38    DENSITY setting #2                   True
extfm         no    Use EXTENDED file marks              True
mode          yes   Use DEVICE BUFFERS during writes     True
ret           no    RETENSION on tape change or reset    True
ret_error     no    RETURN error on tape change or reset True
size_in_mb    36000 Size in Megabytes                    False
YX-DB:/#

这是备机上的信息：
MSSP-DB:/#lscfg -vl rmt0
  rmt0             U7879.001.DQD2P3R-P1-C3-T2-L0-L0  LVD SCSI 4mm Tape Drive (36000 MB)

        Manufacturer................IBM     
        Machine Type and Model......DDS Gen5        
        Device Specific.(Z1)........V314
        Serial Number...............20585044
        Device Specific.(LI)........A170029F
        Part Number.................18P8777
        FRU Number..................18P8779     
        EC Level....................H80564   
        Device Specific.(Z0)........0180020283000130
        Device Specific.(Z3)........L1  

MSSP-DB:/#lsattr -El rmt0
block_size    1024   BLOCK size (0=variable length)       True
compress      yes    Use data COMPRESSION                 True
density_set_1 71     DENSITY setting #1                   True
density_set_2 38     DENSITY setting #2                   True
extfm         yes,no Use EXTENDED file marks              True
mode          yes    Use DEVICE BUFFERS during writes     True
ret           no     RETENSION on tape change or reset    True
ret_error     no     RETURN error on tape change or reset True
size_in_mb    36000  Size in Megabytes                    False
MSSP-DB:/#

应该说，两边的磁带机是一个型号的，参数只有一个extfm不同。奇怪的是，备机上的这个参数不可以改的。

经过多方测试，现在问题集中了，同一份磁带，在主机上做db2ckbkp能顺利往下做，备机上就是到那个点就db2ckbkp进程就死掉了，系统里找不到这个进程了。

所以比较磁带机的不同，就只有那个extfm参数了。。不知道这个参数时候有影响。。。

zero_dot

原帖由 mymm 于 2006-6-7 11:13 发表
磁带机的型号一样吗？BLOCK大小一样吗？
如果有足够的HD空间，用tctl把数据转存出来再用db2ckbkp检查一下!

我用dd命令从磁带上弄了一个小数据库的备份到硬盘，然后用db2 restore，竟然不认这个image。
老大，tctl命令该加那些参数，你确认弄出来的数据能用来恢复的吗 ？
谢谢了。。。

大梦

直接备份到文件系统，带压缩方式！有可能是tape device的问题！

mymm

原帖由 zero_dot 于 2006-6-7 13:00 发表
应该说，两边的磁带机是一个型号的，参数只有一个extfm不同。奇怪的是，备机上的这个参数不可以改的。

不知道是不是这个参数影响， 但它应该是可以修改的，别用smit，用：

1. chdevl -l rmt0 -a extfm=yes

复制代码