IDS ONBAR+TSM 问题及跟踪机制

使用 OnBar 和 TSM 时避免遇到一些常见的陷阱。 
发生超时
问题
由于超时问题，增量备份被终止。 
在增量备份过程中，IDS 需要读取每个被使用过的页面，以便决定该页面是否适合做备份。如果只有一小部分数据被更改，则会导致冗长的读
操作，而没有将任何数据写到 TSM 服务器。在这些情况下，就有可能发生超时。 
解决方案
TSM 管理员应该将 TSM 参数 IDLETIMEOUT 和 COMMTIMEOUT 增加至较为合理的值，以避免 OnBar 增量备份被终止。 
返回 XBSA Error 133 (0x85)
问题
XBSA 133 (0x85) 错误代码的意思是 BAR_NO_BSALIB。它指出一个与 XBSA 库有关的问题。 
解决方案
确保 $ONCONFIG 参数 BAR_BSALIB_PATH 指向正确的 XBSA 库，并且用户 informix 能够装载这个库，即该用户能够检查库和目录的许可权限
查看 OnBar 活动日志，获得确切的错误消息： 

OnBar 活动日志中的错误消息
2005-01-01 11:31:12 68140  39848 ERROR: An unexpected error occurred:  Could not load 
module /usr/tivoli/tsm/client/informix/bin/libTDPinf.a.  The module has an invalid 
magic number. Exec format error.
       

以上错误消息表明，您可能需要从共享库 libTDPinf.a 中提取共享对象 bsashr10.o。这是一个与 AIX® 相关的问题，在 第一篇文章 中已有
讨论。 
返回 XBSA Error 96 (0x60) 
问题
OnBar 终止备份，并返回 XBSA Errorcode 96 (0x60)。 这是一个常见的错误，可能存在几个原因。 
解决方案
大多数情况下，返回 XBSA 96 (0x60) 错误是因为 inclexcl.def 文件中缺少某些条目或存在无效的条目。 
如果 inclexcl.def 中的条目有错误，在 OnBar> 活动日志中应该可以看到如下消息或与之类似的消息：

OnBar 活动日志中的错误消息
2005-01-01 13:16:02 48788  68348 XBSA Error (BSACreateObject): An unspecified 
XBSA error has occurred: 96
        

对 BSACreateObject() 的调用被中止，说明可能存在 inclexcl.def 配置错误。 
对于 V10 之前版本的 IDS，导致 XBSA 96 (0x60) 错误的另一个原因可能是缺少 TDP/Informix 许可或 TDP/Informix 许可无效（在 IDS V10 
中不需要许可文件）：

OnBar 活动日志中的错误消息
2005-01-01 11:34:02 68212  48844 XBSA Error (BSAInit): An unspecified 
XBSA error has occurred: 96
        

这里 BSAInit() 调用被中止。检查在当前工作目录中是否已经生成一个名为 tsmlic.log 的日志文件。 
许可文件通常存放在 TDP/Informix 的默认安装路径中：
AIX: /usr/tivoli/tsm/client/nformix/bin[64]/tdpi.lic
Solaris: /opt/tivoli/tsm/client/nformix/bin[64]/tdpi.lic
逻辑日志的惟一备份对象名称
问题
事务日志总是有一个惟一的名称，因为对象名称中有一部分是日志号。下面是一个具体的备份对象名称，其中 IDS 实例名称为 ids10，服务器
号为 67，逻辑日志 ID 为 99：
/ids10/ids10/67/99
采用这种命名惯例的结果是，逻辑日志永远不会到期，因为它们总有一个惟一的名称，因而绝不会进入不活动状态。不过这条规则也有一个惟
一的例外，那就是日志抢救操作，这种操作再次用相同的对象名称来备份已经被保存的逻辑日志，从而使得前一个版本进入不活动状态。但是
，新版本的备份对象（抢救出的日志）随之进入活动状态。 
解决方案
对于逻辑日志进入不活动状态这个问题，Informix 提供了 onsmsync （Online Storage Manager Synchronization）实用程序。Onsmsync 可
用于解决 TSM 中逻辑日志进入不活动状态这个问题，还可以从 sysutils 数据库和 emergency bootfile 中删除旧的条目，使它们保持同步。 
还可以使用 'dsmc expire' 命令来使逻辑日志进入不活动状态。但是请记住，在这种情况下，sysutils 数据库和 emergency bootfile 之间
没有进行同步。这时要由您自己来负责保持该信息同步。 
dbspace 的重复备份对象名称
问题
对于 IDS 实例 ids10，根 dbspace 的 0 级备份将命名为： 
/ids10/ids10/rootdbs/0
增量备份（1 级和 2 级）将有以下与之关联的备份对象名称： 
/ids10/ids10/rootdbs/1
/ids10/ids10/rootdbs/2
Dbspace 备份对象将自动进入不活动状态，因为相同级别（例如 0 级、1 级、2 级）的一个新的备份将拥有和之前一致的备份对象名称，因而
之前的那个版本将进入不活动状态。 
乍一看来，为 dbspaces 重用备份对象名称似乎是一种好方法，因为之前的版本将自动切换至不活动状态。在这种情况下，TSM 根据底层备份
拷贝组的设置使那些对象到期。 
但是，当您想用不同的管理类存储备份时，这种技术就显现出一个陷阱。如果每周做一次 0 级备份，每天做一次 1 级备份，并且都是为期一
个月（例如 TSM 管理类 MC31）。在一个季度的季末，要做一次 0 级备份，并且为期 1 年（例如 TSM 管理类 MC365）。一种可行的方法是使
用两个不同的 inclexcl.def 文件，其中默认的 inclexcl.def 将包含以下关于每日备份的条目： 
include /ids10/.../[0-2] MC31
对于每季一次的备份，应该在 inclexcl.def 中将以上条目替换为： 
include /ids10/.../[0-2] MC365
这时出现的问题是，TSM 将对所有具有相同名称的备份对象执行管理类的重新绑定。因此，之前每周执行的 0 级备份现在将被绑定到管理类 
MC365。顺便说一下，所有具有相同备份对象名称的版本，不管是活动的版本还是不活动的版本，都将被重新绑定。 
这还不算糟糕，真正的问题是在以后用初始的 inclexcl.def 条目做每周的 0 级备份时出现的。现在每季度做的 0 级备份将被重新从管理类 
MC365 绑定到 MC31。所以，当您将来需要恢复每季度的备份时，这个备份却很可能不可用了。 
解决方案
为了防止上述行为，必须为每季度的备份注册一个专用的节点名。通常，TSM 节点名与客户机的主机名相对应，但是也可以为同一台客户机注
册好几个节点名。TSM 管理员必须在 TSM 服务器上执行新节点名的注册。完成注册之后，就可以在专用的 TSM 节点名下执行每季度的备份了
。 
由于无法直接告诉 OnBar 去使用这个专用节点名，所以必须更改客户机系统选项文件（dsm.sys）。在 dsm.sys 文件中更改（或添加）与专用
节点名相关的 NODENAME 参数。然后，便可以使用 OnBar 执行 0 级备份。这个过程可以确保备份是在专用节点名之下进行的，从而可以防止
已有备份对象被重新绑定管理类。 
值得一提的是，您应该以完全系统备份的形式来执行每季度的备份，例如指定 OnBar 选项 '-w'。 完全系统备份确保能够在不应用逻辑日志的
情况下恢复备份。修改后的 inclexcl.def 应该包含以下两个条目： 
exclude /.../*
include /ids10/.../[0-2] MC365
exclude 条目确保逻辑日志不会备份在专用节点名之下，否则在恢复每日的备份时将出现麻烦。这种情况下将出现的问题是，有些逻辑日志存
储在一般节点名下，另一些逻辑日志又存储在专用节点名下。因此，在逻辑恢复期间，OnBar 就能够发现存储在一般节点名之下的逻辑日志，
而不是那些存储在专用节点名之下的逻辑日志，除非您使用 'dsmc set access...' 授予适当的访问权限（请参阅 导入恢复 一节）。 
可取的做法是，总是将逻辑日志存储在一般节点名之下，省略用于日志的条目，并在修改的 inclexcl.def 中指定一个 exclude 条目。这种方
法将导致在 0 级备份期间，当出现日志切换、触发 ALARMPROGRAM 并试图备份未保存的逻辑日志时，OnBar 活动日志中出现以下错误消息： 

OnBar 活动日志中的错误消息
... Successfully connected to Storage Manager.
... XBSA Error (BSACreateObject): An unspecified XBSA error has occurred: 96
... /usr/informix/bin/onbar_d: process exit 96 (0x60)
       

这条错误消息可以忽略。在 0 级备份完成，并且恢复了 dsm.sys 中的初始节点名之后，逻辑日志将被保存。下一次的日志切换将使用 
ALARMPROGRAM 机制（例如 'onbar -b -l'） 在初始节点名下备份所有未保存的日志。应确保配置了足够多的逻辑日志空间，以防在进行每季
度的备份时出现日志已满的状况。 
也可以创建一种完全去耦的 dsm.sys 配置，该配置只是为这种每季度的备份而考虑的。在运行每季度的 0 级备份时，逻辑日志仍然可以由 
ALARMPROGRAM 备份。为实现这一点，可以创建一个专用目录，其中包含用于所有文件（除了 dsm.sys）到初始 DSMI_DIR 目录的符号链接。在
这种新配置中，可以创建一个修改后的 dsm.sys 文件（更改 NODENAME 和 INCLEXCL 条目），然后在开始每季度的备份之前，将 DSMI_DIR 环
境变量设置为该目录。 
这样可确保修改过的 dsm.sys 设置仅用于这种专门的每季度的 0 级备份，而逻辑日志仍然由 ALARMPROGRAM 备份在初始节点名之下。这样便
消除了在执行每季度备份时出现日志已满的状况的危险。在执行每季度的备份之后，您仍将收到上述 XBSA 0x96 错误，因为执行 0 级备份的 
OnBar 进程试图将当前逻辑日志发送到 TSM（这个 OnBar 进程使用专用的节点名环境）。然而，如前所述，这一点不必担心，因为一旦出现下
一次日志切换，受影响的逻辑日志将由 ALARMPROGRAM 保存起来。 
上述过程并不妨碍您与在专用节点名之下执行的每季度备份一起使用这些逻辑日志，以执行时间点（Point-In-Time）恢复。 为完成该任务，
需要将恢复过程划分成物理恢复和逻辑恢复，例如： 
将节点名设置为用于每季度备份的专用节点名 
只执行一次物理恢复 
'OnBar -r -w -p -t '
重新将节点名设置为一般节点名 
继续恢复操作，这次是逻辑恢复 
'onbar -r -l -t '
如果您不想划分恢复操作，那么可以使用 'dsmc set access....'（请参阅 导入恢复 一节）授予适当的访问权限。 
如果您想恢复一个 Whole-System-Backup（完全系统备份），那么并不需要指定 '-w' 标志。这是一种常见的误解。在恢复期间指定 '-w' 标
志意味着应该由 OnBar 执行一次顺序的恢复（例如一个 dbspace 接一个 dbspace）。 
如果省略 '-w' 选项，OnBar 仍可以恢复一个 Whole-System-Backup。在这种情况下，只有根 dbspace 被顺序地恢复，之后 OnBar 将派生出
一些附加的 OnBar 进程（取决于 $ONCONFIG 参数 BAR_MAX_BACKUP）并且并行地恢复剩下的 dbspace。 
在开始那样的并行恢复之前，必须在 $ONCONFIG 中将 LTAPEDEV 设置为与 /dev/null 不同的值。如果基础设施（磁盘、网络、TSM 服务器）
合理的话，这样将大大减少恢复时间。在恢复过程的最后，在 OnBar 活动日志中可以看到一条如下所示的消息： 

OnBar 活动日志中的警告消息
...WARNING: Physical restore complete. Logical restore required before work
       

这很容易使人产生误解。您不能恢复任何日志，因为您已经恢复了一个 Whole-System-Backup（以并行方式），而不是 Parallel-Backup。这
时，可以执行 'onmode -m' 命令，使 IDS 数据库服务器上线。这个过程可能要花费几分钟的时间，因为要清除物理日志和逻辑日志。执行 
'onstat -D -r' 监视相关 dbspace/块上的写操作。 
Whole-System-Backup 由 emergency bootfile 的第 4 个位置中的 1 来标识。Parallel-Backup 在这个位置上的标识是 0： 

Emergency Boot 文件
ids10             rootdbs            R  1 117   0 0  .........
ids10             rootdbs            R  0 112   0 0  .........
       

下面是 OnBar 活动日志的摘录，展示了顺序恢复与并行恢复之间的不同之处： 

顺序物理恢复 ('onbar -r -w -p')
2006-01-01 17:00:25 45242  38228 Completed cold level 0 restore rootdbs.
2006-01-01 17:00:25 45242  38228 Begin cold level 0 restore logdbs.
2006-01-01 17:00:25 45242  38228 Completed cold level 0 restore logdbs.
2006-01-01 17:00:25 45242  38228 Begin cold level 0 restore physdbs.
2006-01-01 17:00:25 45242  38228 Completed cold level 0 restore physdbs.
2006-01-01 17:00:26 45242  38228 Completed whole system restore.
       

在单个 OnBar 进程中一个接一个地恢复 dbspace。子进程 ID 显示在第 3 个位置，在一次顺序恢复期间一直保持不变。 

并行物理恢复('OnBar -r -p')
2006-01-01 17:04:02 42612  25106 Begin cold level 0 restore rootdbs.
2006-01-01 17:05:27 42612  25106 Completed cold level 0 restore rootdbs.
2006-01-01 17:05:27 52488  42612 Process 52488  42612 successfully forked.
2006-01-01 17:05:27 56058  42612 Process 56058  42612 successfully forked.
2006-01-01 17:05:27 52488  42612 Successfully connected to Storage Manager.
2006-01-01 17:05:27 56058  42612 Successfully connected to Storage Manager.
2006-01-01 17:05:27 52488  42612 Begin cold level 0 restore logdbs.
2006-01-01 17:05:27 56058  42612 Begin cold level 0 restore physdbs.
2006-01-01 17:05:29 56058  42612 Completed cold level 0 restore physdbs.
2006-01-01 17:05:29 52488  42612 Completed cold level 0 restore logdbs.
2006-01-01 17:05:29 56058  42612 Process 56058  42612 completed.
2006-01-01 17:05:29 52488  42612 Process 52488  42612 completed.
2006-01-01 17:05:29 42612  25106 WARNING: Physical restore complete. Logical restore required 
before work can continue.
       

在恢复根 dbspace 之后，OnBar 派生出一些附加的 OnBar 进程，其他的 dbspaces 将被并行地处理（基于 BAR_MAX_BACKUP）。在 OnBar 活
动日志的第 3 个位置中包含多个进程 ID。当物理恢复完成之后，就会显示那条令人容易产生误解的警告信息。在物理恢复之后执行 'onmode 
-m'（忽略逻辑恢复）将导致 online.log 中出现以下消息： 

执行 'onmode -m' 后 online.log 中的消息
17:06:54  No logical log restore will be performed.
17:06:54  Clearing the physical and logical logs has started
17:07:26  Cleared 129 MB of the physical and logical logs in 31 seconds
17:07:26  Physical Recovery Started.
17:07:26  Physical Recovery Complete: 0 Pages Restored.
17:07:26  Logical Recovery Started.
17:07:28  Logical Recovery Complete.
          0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks
17:07:29  Bringing system to On-Line Mode with no Logical Restore.
17:07:30  On-Line Mode
       

物理日志和逻辑日志完全清除之后，IDS 将处于在线模式。 
TSM 导出和导入
问题
如果您执行了一个 TSM 导出和导入操作之后，IDS 数据库服务器不能工作，于是您又执行了一次恢复操作。经过这些步骤，OnBar 请求的备份
对象在 TSM 服务器中再也找不到了。 
解决方案
对于这个问题没有直接的解决方案。每个备份对象都从 TSM 那里获得一个惟一的对象 ID。OnBar 将这个惟一的对象 ID 存储在 sysutils 数
据库中，并且还存储在 emergency bootfile 中。在一次恢复操作期间，通过执行 XBSA 调用 BSAGetObject() 并提供对象 ID 获得所需的备
份对象。 
TSM 保证对象 ID 相对于备份对象的生命周期来说具有惟一性和耐久性。这条规则的一个例外是 TSM 导出/导入操作。在导出/导入操作之后，
对象 ID 不再与存储在 sysutils 数据库或 emergency bootfile 中的值相符。 
这是一个 OnBar 设计问题。TSM API 文档建议使用 XBSA 调用 BSAQueryObject() 来定位一个对象，并执行 BSAGetObject()，同时提供第一
次调用时收到的对象 ID。OnBar 通常只执行 BSAGetObject() 调用，只是在逻辑恢复的最后，它还调用 BSAQueryObject() 来查看是否存在没
有被包含在 sysutils 数据库或 emergency bootfile 中的逻辑日志。 
数据并没有丢失。我们可以编写一个程序，该程序查询 sysutils 数据库，通过以适当的查询参数调用 BSAQueryObject() 从 TSM 获得新的对
象 ID，并将收到的对象 ID 写回到 sysutils 数据库。然后，便可以运行 'onsmsync -b' 来重新根据 sysutils 数据库生成 emergency 
bootfile。如果 sysutils 数据库不可用，那么可以解析 emergency bootfile，根据该信息获得新的对象 ID，并将其写回到 emergency 
bootfile 中。 
上述获得新的对象 ID 的过程是可行的，但肯定不容易。更好的方法是，只要有需要恢复的 IDS 备份，就不使用 TSM 导出/导入。 
导入恢复
问题
导入恢复的意思是在另一台机器上恢复 IDS 数据库服务器。在设置测试环境或灾难恢复站点时，这是常有的需求。 
解决方案
在辅助机器上使用 OnBar 和 TDP/Informix 执行恢复就称作导入恢复。对于这种恢复，应该考虑以下几点： 
确保底层操作系统和硬件架构相同。 
在两台机器上使用相同版本的 IDS。如果使用早于第 10 版的 IDS， 那么还应确保两台机器上安装了相同版本的 TDP/Informix。 
在辅助机器上创建相同的磁盘布局（至少块的大小和名称必须与主机器上一致。可以使用符号链接）。如果使用 IDS V9.4 或更高版本，那么
可以使用 Redirected Restore 特性。 该特性允许在没有相同磁盘布局的情况下执行恢复。 
将以下文件从 $INFORMIXDIR/etc 目录复制到辅助机器： 
$ONCONFIG
$INFORMIXSQLHOSTS
oncfg_.
sm_versions
ixbar.
用辅助机器的主机名替换 $INFORMIXSQLHOSTS 文件中的主机名。 
在 /etc/services 文件中创建必要的条目。 
确保 dsm.opt 和 dsm.sys 文件包含适当的条目： 
确保联系到相同的 TSM 服务器（TCPSERVERADDRESS，TCPPORT）
将 PASSWORDACCESS 设置为 GENERATE
允许辅助节点访问备份在主节点上的对象（必须在主机器上完成）： 
'dsmc set access backup /ids10/*/* informix'
检查是否使用 'dsmc query access' 授予了许可
在执行导入恢复之前，主要应该考虑这几点。上述准备工作完成之后，便可以使用适当的 OnBar 命令在辅助机器上开始恢复。 
其他要备份的重要文件
问题
灾难发生。必须在一台辅助机器上恢复 IDS 实例。但是忘了备份一些重要的文件，例如 emergency bootfile。 
解决方案
除了用 OnBar 备份的 dbspaces 和逻辑日志外，还应该不忘备份以下文件和信息。这样可以确保在紧急情况下恢复数据库服务器时，所有必需
的信息都是可用的：
$INFORMIXDIR/etc/$ONCONFIG
$INFORMIXSQLHOSTS
$INFORMIXDIR/etc/ixbar.
$INFORMIXDIR/etc/oncfg_.
$INFORMIXDIR/etc/sm_versions
inclexl.def, dsm.sys, dsm.opt
'onstat -d' output
重要的环境设置
可以使用 'dsmc archive' 命令来备份这些文件和信息。确保您使用了适当的管理类，以便在需要它们时，这些文件在 TSM 中仍然可以找得到
定期演习恢复操作。备有正确的程序，加上必要的体验，可以帮助您在紧急情况下过关。 
确保您的备份是一致的和可靠的。OnBar 通过 '-v';（表示 verify）开关提供了这个功能。使用这个有用的 OnBar 功能定期对备份进行检查 
 
 跟踪机制
如果出现运行不正常的情况，那么可以跟踪备份操作。这应该可以帮助发现问题的根源。OnBar 和 TSM API 都提供了跟踪方法。 
OnBar 跟踪
在 online.log（$ONCONFIG 参数：MSGPATH） 或 OnBar 活动日志（$ONCONFIG 参数：BAR_ACT_LOG）中都可以找到关于 OnBar 问题的有用信
息。 
如果这样的信息还不令人满意，那么可以通过设置以下两个 $ONCONFIG 参数来调试 OnBar 进程：
BAR_DEBUG_LOG 
OnBar 创建的 debug logfile 的完整路径名
BAR_DEBUG 
生成的调试信息的数量。取值范围是 1 到 9。
设置这两个参数时无需重新启动数据库服务器。OnBar 进程在下一次运行时会从 $ONCONFIG 中提取这些设置。在更新的 IDS 版本中
（V7.31.UD5 和更高版本以及 V9.40.UC1 和更高版本），OnBar 还每过 120 秒钟检查 BAR_DEBUG 是否在 $ONCONFIG 文件中。这意味着可以
在 OnBar 已经启动之后，动态地设置 BAR_DEBUG 参数。 
调试过程会生成大量的信息，同时也会显著降慢备份/恢复过程。只有在想分析一个问题的时候才去设置 BAR_DEBUG，在平时的操作中不能这样
做。一般情况下 7 级的调试应该足够了。而 9 级的调试会生成大量的信息，因为它要转储所有页的页头。 
TSM API 跟踪
关于 TSM API 的信息可以在 TSM API 日志中找到。这个日志文件的文件名是 dsierror.log，它通常是在可以启动 OnBarhas 的同一个目录中
生成的。还可以将环境变量 DSMI_LOG 设置为所需的目录。如果您不确定 dsierror.log 的位置，那么可以执行以下 find 命令：
'find / -name dsierror.log -ls'
在这里花一些时间应该可以帮助您发现所需的 dsierror.log。不过更好的方法也许是设置环境变量 DSMI_LOG。 
如果 dsierror.log 中的信息还不够，那么接下来应该跟踪 TSM API。通过设置客户机用户选项文件 dsm.opt 中的以下参数，可以启用跟踪：
tracefile 
存储跟踪信息的文件的完整路径名。 
traceflag 
不同跟踪类别列表，中间以逗号隔开。用于 IDS 的类别有： 
appl
api_detail
verbdetail 
timestamp