Informix Onbar Restore遭遇错误——XBSA Error

在灾备站点对Informix系统作恢复时，遭遇下面的错误。XBSA Error: (BSAGetObject) Backup object does not exist in Storage Manager.

bar_act.log中的日志记录如下：

2008-07-29 13:31:27 131316  131952 /home/informix/bin/onbar_d -r -w -p
2008-07-29 13:31:27 131316  131952 BAR_XFER_BUF_SIZE  exceeded maximum allowed limit. Changing buffer size to 61440.
2008-07-29 13:31:28 131316  131952 Successfully connected to Storage Manager.
2008-07-29 13:31:28 131316  131952 XBSA Error: (BSAGetObject) Backup object does not exist in Storage Manager.
2008-07-29 13:31:28 131316  131952 Object information: bar_objdesc
    obj_id 0 obj_name 'rootdbs' obj_type 'R' act_id 0 act_type 2 act_status 0
    act_start '2008-07-29 13:31:28'  act_end '2008-07-21 00:30:01'
    ins_time 0 rsam_time 0 level 0 copyid hi:lo 0:62113775 req_act_id 3585
    logstream 0 est_pages hi:lo 0:0 first_log 0 chpt_log 0 last_log 0
    partial_flag 0 do_query 0 ins_sm_id 0 ins_sm_name ''
    ins_verify 0 ins_verify_date '' restore order 0:0
    objInfo ''
    retry 0 in_catalog 0 in_bootfile 0 child_pid 0 child_state 0
    bkup_host ''
2008-07-29 13:31:34 131316  131952 Due to the previous error, logical restore will not be attempted.
2008-07-29 13:31:34 131316  131952 /home/informix/bin/onbar_d complete, returning 100 (0x64)

生产端的Informix恢复没有遇到类似问题呀，有点不知所措。只好查找资料，后来发现原因在于onbar的设计问题，与TSM的export和import不兼容。

Informix的备份数据在存储在TSM中有个对应的objectid，但是这个对象ID在TSM执行了导入和导出操作后，发生了变化。所以导致在灾备端使用原有的ixbar.0文件进行恢复是，系统提示说找不到相应的对象。

关于这个问题的解决方案是，在灾备端的TSM服务器中使用show version查找出相应新的object id，然后手工编辑修改ixbar.0文件中的相应内容，使得onbar在恢复的时候可以根据新的ID读取到备份映像。

tsm: TK-DR>show version tkbas570 /prd
/prd : /prd/bipdbs/ 0 (MC: DEFAULT)
Active, Inserted 07/22/08 00:33:56
ObjId: 0.4196, GroupMap 00000000, objType 0x02

/prd : /prd/cdr_sbspace/ 0 (MC: DEFAULT)
Active, Inserted 07/22/08 00:33:58
ObjId: 0.4197, GroupMap 00000000, objType 0x02

/prd : /prd/datadbs/ 0 (MC: DEFAULT)
Active, Inserted 07/22/08 00:34:02
ObjId: 0.4198, GroupMap 00000000, objType 0x02

/prd : /prd/idxdbs/ 0 (MC: DEFAULT)
Active, Inserted 07/22/08 01:13:46
ObjId: 0.4199, GroupMap 00000000, objType 0x02 

/prd : /prd/logdbs/ 0 (MC: DEFAULT)
Active, Inserted 07/22/08 00:33:53
ObjId: 0.4194, GroupMap 00000000, objType 0x02

/prd : /prd/phydbs/ 0 (MC: DEFAULT)
Active, Inserted 07/22/08 00:33:55
ObjId: 0.4195, GroupMap 00000000, objType 0x02

/prd : /prd/rootdbs/ 0 (MC: DEFAULT)
Active, Inserted 07/22/08 00:32:44
ObjId: 0.4193, GroupMap 00000000, objType 0x02

此时，从生产端恢复出来的ixbar.0文件的内容如下：

prd                logdbs             CD 1 3589  0 0         62428858   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                phydbs             CD 1 3589  0 0          62428859   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                rootdbs            R  1 3589  0 0          62428857   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                bipdbs             ND 1 3589  0 0          62428860   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                idxdbs             ND 1 3589  0 0          62428946   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                cdr_sbspace        ND 1 3589  0 0         62428861   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                datadbs            ND 1 3589  0 0         62428862   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -

对应的信息不匹配，也就是上述onbar -r -w -p 恢复时报错的原因。下面要做的就是手工修改ixbar.0文件，使得信息匹配。

prd                logdbs             CD 1 3589  0 0          4194   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                phydbs             CD 1 3589  0 0          4195   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                rootdbs            R  1 3589  0 0          4193   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                bipdbs             ND 1 3589  0 0          4196   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                idxdbs             ND 1 3589  0 0          4199   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                cdr_sbspace        ND 1 3589  0 0          4197   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -
prd                datadbs            ND 1 3589  0 0          4198   2008-07-22 00:30:01 1     16501 -1807680450 3589  0     - -

接着按照之前的操作进行恢复就行了。下面是系统恢复时的bar_act.log的相应输出。红色标注的部分很关键。

2008-07-28 16:55:35 86250  176390 /home/informix/bin/onbar_d -r -w -p
2008-07-28 16:55:36 86250  176390 BAR_XFER_BUF_SIZE  exceeded maximum allowed limit. Changing buffer size to 61440.
2008-07-28 16:55:36 86250  176390 Successfully connected to Storage Manager.
2008-07-28 16:56:07 86250  176390 Begin cold level 0 restore rootdbs (Storage Manager copy ID: 0 4193).
2008-07-28 16:57:32 86250  176390 Completed cold level 0 restore rootdbs.
2008-07-28 16:57:32 86250  176390 Begin cold level 0 restore logdbs (Storage Manager copy ID: 0 4194).
2008-07-28 16:57:32 86250  176390 Completed cold level 0 restore logdbs.
2008-07-28 16:57:32 86250  176390 Begin cold level 0 restore phydbs (Storage Manager copy ID: 0 4195).
2008-07-28 16:57:32 86250  176390 Completed cold level 0 restore phydbs.
2008-07-28 16:57:32 86250  176390 Begin cold level 0 restore bipdbs (Storage Manager copy ID: 0 4196).
2008-07-28 16:57:32 86250  176390 Completed cold level 0 restore bipdbs.
2008-07-28 16:57:32 86250  176390 Begin cold level 0 restore cdr_sbspace (Storage Manager copy ID: 0 4197).
2008-07-28 16:57:37 86250  176390 Completed cold level 0 restore cdr_sbspace.
2008-07-28 16:57:37 86250  176390 Begin cold level 0 restore datadbs (Storage Manager copy ID: 0 4198).
2008-07-28 17:51:56 86250  176390 Completed cold level 0 restore datadbs.
2008-07-28 17:51:56 86250  176390 Begin cold level 0 restore idxdbs (Storage Manager copy ID: 0 4199).
2008-07-28 17:57:11 86250  176390 Completed cold level 0 restore idxdbs.
2008-07-28 17:57:12 86250  176390 Completed whole system restore.
2008-07-28 17:57:13 86250  176390 /home/informix/bin/onbar_d complete, returning 0 (0x00)

等恢复结束后使用onmode -m命令将IDS置于online状态。

至此，系统恢复就算做完了，最后一步是关于TSM，sysutil和ixbar.0之间的信息同步问题。

使用onsmsync命令（不带任何参数），结果是系统按照新的object-id将信息在sysutil上进行更新。

如果使用onsmsync -b命令，则系统只会将sysutil库中的信息同步到新的ixbar.0紧急引导文件上。后台操作输出如下：

2008-07-29 08:41:28 144210  152372 onsmsync -b
2008-07-29 08:41:29 144210  152372 Copy of old emergency bootfile saved in /home/informix/etc/ixbar.0.20080729.084129
2008-07-29 08:41:29 144210  152372 onsmsync complete, returning 0 (0x00)

此时得到的结果是sysutil库中的信息和ixbar.0中的信息与生产端相同，但与TSM端的不同。具体操作策略要看策略是怎么样的，也可以对目标系统再次进行备份。这样以后再恢复的时候就不会遇到本文所遇到的对象不存在的错误了。