onbar 备份与恢复系统

onbar 备份与恢复系统概述

onbar 由各种组件组成，它与存储管理器一起使用来备份和恢复数据。

onbar 组件

onbar 组件包含命令行实用程序、目录表、活动日志和紧急引导文件。请将 onbar 与存储管理器及其 XBSA 共享库一起使用。

下图显示了 onbar 和数据库服务器组件：

数据库服务器中的存储空间（数据库空间、Blob 空间和智能大对象空间）以及逻辑日志
sysutils 数据库，其中包含 onbar 目录表
onbar 和 onbar-d 命令行实用程序
系统上存储管理器的 XBSA 共享库
用于存储备份的存储介质
onbar 活动日志
onbar 紧急引导文件

图: GBase 8s 的 onbar 组件

onbar 与数据库服务器和存储管理器进行通信。请使用 onbar 命令启动备份或恢复操作。缺省情况下，onbar 以并行方式备份和恢复存储空间。onbar 始终以串行方式处理日志文件。

对于备份会话，onbar 从数据库服务器请求存储空间和逻辑日志的内容，并将它们传递到存储管理器。存储管理器将数据存储在存储介质上。对于恢复会话，onbar 从存储管理器请求已备份的数据，然后在数据库服务器上恢复该数据。

onbar 首先备份关键数据库空间，接着是剩余存储空间，最后备份逻辑日志。关键数据库空间是 rootdbs 以及包含逻辑日志和物理日志的数据库空间。

onbar 还会在备份期间将以下关键文件放到归档中：

onconfig 文件
sqlhosts 文件
oncfg_servername.servernum 文件
onbar 紧急引导文件：ixbar.servernum

您可以恢复存储在原始文件和格式化文件中的存储空间。如果系统包含主存储空间和镜像存储空间，那么恢复（外部恢复除外）期间 onbar 将同时写入主块和镜像块。

onbar 状态和错误消息将写入活动日志文件 bar_act.log 中。

备份服务 API (XBSA)

onbar 和存储管理器通过“备份服务应用程序编程接口 (XBSA)”通信，该接口支持存储管理器为数据库服务器管理介质。通过使用存储管理器的开放式系统接口，onbar 可以与各种同样使用 XBSA 的存储管理器一起工作。

每个存储管理器建立并分配一个唯一版本的 XBSA 共享库。必须使用随存储管理器提供的 XBSA 共享库版本。例如，如果使用 GBase 8s 主存储管理器，那么还必须使用 onbar 提供的 XBSA 共享库。onbar 和 XBSA 共享库必须以相同方式（32 位或 64 位）进行编译。例如，如果使用 Storage Manager，那么还要使用 onbar 提供的 XBSA 共享库。onbar 和 XBSA 共享库必须以相同方式（32 位或 64 位）进行编译。

onbar 使用 XBSA 与存储管理器交换以下类型的信息：

控制数据

onbar 与存储管理器交换控制数据以验证 onbar 和 XBSA 是否兼容，并确保以正确顺序将对象恢复到数据库服务器的正确实例，以及跟踪备份对象的历史记录。

备份或恢复数据

在备份与恢复期间，onbar 和存储管理器使用 XBSA 交换来自指定存储空间或逻辑日志文件的数据。

onbar 使用 XBSA 事务来确保数据的一致性。包含在一个事务中的所有操作被看作是一个单元。一个事务中的所有操作必须成功，才能恢复传送给存储管理器的对象。

onbar 目录表

onbar 使用 sysutils 数据库中的目录表来跟踪备份与恢复操作。 onsmsync 实用程序使用其他目录表来跟踪其操作。

onbar 在 sysutils 数据库中使用以下目录表来跟踪备份与恢复操作：

bar_server 表跟踪数据库服务器的实例。
bar_object 表跟踪备份对象。备份对象是数据库空间、Blob 空间、智能大对象空间或逻辑日志文件的备份。
bar_action 表跟踪所有对每个备份对象进行的备份与恢复尝试，除了某些日志回收和冷恢复事件以外。
bar_instance 表描述在成功的备份尝试中备份的每个对象。

onsmsync 实用程序使用并维护以下各表来跟踪其操作：

bar_ixbar 表包含所有时间线中所有未到期的成功备份的历史记录。
bar_syncdeltab 表通常为空，但 onsmsync 正在运行时除外。

有关这些表内容的描述，请参阅 onbar 目录表。

ixbar 文件：onbar 紧急引导文件

每次备份后会自动更新紧急引导文件。该文件包含 onbar 执行冷恢复所需的信息。

重要

请勿修改紧急引导文件。如果进行了修改，将可能导致 onbar 选择错误的备份作为恢复的一部分，这可能会引起数据损坏或系统故障。

引导文件的文件名是 ixbar.servernum，其中 servernum 是 SERVERNUM 配置参数的值。

onbar 紧急引导文件位于 UNIX™ 上的 $GBASEDBTDIR/etc 目录中。您可以更改 BAR_IXBAR_PATH 配置参数中指定的信息，从而覆盖引导文件的缺省路径和名称。

bar_act.log 文件：onbar 活动日志

onbar 将参考、进度、警告、错误和调试消息写入 onbar 活动日志 bar_act.log 中。

onbar 备份和恢复错误不会出现在标准输出中。如果在您备份和恢复数据时发生错误，请检查 onbar 活动日志中的信息

还可以使用活动日志进行以下操作：

监视备份与恢复活动，例如，活动日志还将记录哪些存储空间和逻辑日志已备份或已恢复、操作的进度以及大致花了多长时间。
验证备份或恢复是否成功。
跟踪 ondblog 实用程序中的错误。
跟踪 onbar 性能统计信息

onbar 活动日志位于 UNIX™ 上的 /tmp 目录中。使用 BAR_ACT_LOG 配置参数指定 onbar 活动日志的位置。

onbar 脚本

onbar 实用程序在 UNIX™ 上包含一个 shell 脚本，用于定制备份与恢复操作。

当您随数据库服务器安装 onbar 时，将包含一个缺省脚本。该脚本的名称和位置取决于操作系统：

UNIX

onbar shell 脚本位于 $GBASEDBTDIR/bin 目录中。

当从命令行发出 onbar 命令时，自变量会传递给脚本，然后传递给 onbar_d 实用程序。

表 1. onbar 实用程序

实用程序	描述
onbar_d 实用程序	在数据库服务器和存储管理器之间传输数据。 onbar 命令会调用 onbar_d 实用程序，以启动 onbar-driver。 onbar-driver 启动并控制备份与恢复活动。
onsmsync 实用程序	同步 sysutils 数据库、紧急引导文件和存储管理器目录的内容。使用此实用程序以清除不再需要的备份。
ondblog 实用程序	更改数据库日志记录方式。ondblog 实用程序将其输出记录到 onbar 活动日志 bar_act.log 中。
archecker 实用程序	验证备份，并从归档恢复表级别数据。

onbar 的存储管理

必须使用存储管理器来通过 onbar 执行备份与恢复操作。存储管理器是管理包含备份的存储设备和介质的应用程序。存储管理器将处理所有的介质标号、安装请求以及存储卷。

Storage Manager 包含在数据库服务器中。GBase 8s 主存储管理器包含在数据库服务器中。但是，您可以选择使用受 onbar 支持且与您的存储设备兼容的另一个存储管理器。

配置存储管理器和 onbar

本节中的主题提供了您在使用存储管理器来计划和设置 onbar 时所需的信息。

配置存储管理器

onbar 备份与恢复操作需要一个通过 XBSA 共享库接口与 onbar 集成的存储管理器。

您可以选择将 GBase 8s 主存储管理器或第三方存储管理器与 onbar 一起使用。GBase 8s 主存储管理器与 GBase 8s 捆绑在一起。

GBase 8s 主存储管理器为仅使用文件设备（磁盘）而非磁带的 onbar 备份与恢复操作（包括并行备份）管理存储。缺省情况下，GBase 8s 主存储管理器是使用 GBase 8s 主存储管理器中指定的信息和一些 onbar 配置参数自动配置的。当您使用 onpsm 实用程序时，也会自动配置该存储管理器。

sm_versions 文件中的存储管理器定义

有些存储管理器（除了 GBase 8s 主存储管理器）必须在 sm_versions 文件中存在条目。

sm_versions 文件中的存储管理器的定义使用以下格式：

1|XBSA_ver|sm_name|sm_ver

在该格式中，XBSA_ver 是存储管理器的 XBSA 共享库的发行版，sm_name 是存储管理器的名称，sm_ver 是存储管理器版本。字段最大长度为 128 个字符。

在 onbar 使用第三方存储管理器启动备份或恢复进程之前，onbar 会调用当前安装的特定于存储管理器的 XBSA 共享库版本以获取其版本号。如果该版本与当前的 onbar 版本兼容，并已在 sm_versions 文件中定义，那么 onbar 开始执行所请求的操作。

配置第三方存储管理器

各种存储管理器的安装与配置要求略有不同。如果使用第三方存储管理器，请确保仔细遵循制造商的指示信息。如果难以安装和配置存储管理器，请直接与制造商联系。

有关适用于您的 onbar 版本的已认证存储管理器列表，请咨询销售代表。

重要

某些存储管理器允许您指定要备份到特定存储设备的数据。为提高备份与恢复的效率，请配置存储管理器以将逻辑日志备份到一个设备，而将存储空间备份到另一个设备。

要配置第三方存储管理器：

设置 onbar 配置参数和环境变量。
配置存储管理器使 onbar 可以正确地与之通信。

相关信息请参阅您的存储管理器文档。
遵循存储管理器文档中的指示信息来配置您的存储设备。

存储管理器必须了解它所使用的存储设备的设备名。
标记存储卷。
在存储设备上安装存储卷。
在 sm_versions 文件中创建存储管理器定义。使用第三方存储管理器的供应商提供的定义。

a. 将 sm_versions.std 模板复制到新文件 sm_versions 中，该文件位于 UNIX™ 上的 $GBASEDBTDIR/etc 目录中。

b. 通过使用 sm_versions.std 中的格式作为模板，以存储管理器的正确数据创建您自己的 sm_versions 文件。要找出第三方存储管理器的 sm_versions 中要使用哪个代码名称，请参阅存储管理器文档。

c. 停止当前运行的所有 onbar 进程（onbar_d、onbar_w 或 onbar_m），然后重新启动它们以使更改生效。
验证存储管理器的 BAR_BSALIB_PATH 配置参数是否指向正确的 XBSA 共享库。
onbar 将 SERVERNUM 配置参数值用作存储管理器中逻辑日志的存储路径的一部分。如果存储管理器未将通配符用于服务器编号，请为存储管理器设置相应的服务器编号环境变量。

配置了存储管理器和存储设备并为数据库服务器和逻辑日志备份标记了卷后，您就可以使用 onbar 启动备份或恢复操作了。

验证存储管理器

转换或还原 GBase 8s 数据库服务器时，在旧版本上使用的存储管理器可能未针对要迁移到的版本进行验证。验证存储管理器供应商是否已成功完成对数据库服务器版本和平台的 GBase 8s 验证过程。

如果尚未完成验证，那么使用 onbar 执行备份之前需要安装经过验证的存储管理器。

配置 onbar

开始第一次备份前，请复审 onconfig 文件中的缺省 onbar 参数并按需要调整这些值。

您可以通过设置 onconfig 文件中的以下配置参数来配置 onbar 的行为。

表 1. onbar 配置参数.

行为	配置参数
通过设置数据缓冲区的数量和大小以及并行进程的数量来提高 onbar 性能。	BAR_NB_XPORT_COUNT 配置参数 BAR_XFER_BUF_SIZE 配置参数 BAR_MAX_BACKUP 配置参数
设置调试级别以及调试日志文件的位置。	BAR_DEBUG 配置参数 BAR_DEBUG_LOG 配置参数
更改 onbar 引导文件的路径。	BAR_IXBAR_PATH 配置参数
保留到期的备份的历史记录。	BAR_HISTORY 配置参数
更改 onbar 活动日志的位置和内容。	BAR_IXBAR_PATH 配置参数
保留到期的备份的历史记录。	BAR_ACT_LOG 配置参数 BAR_PROGRESS_FREQ 配置参数 BAR_PERFORMANCE 配置参数
设置失败的备份或恢复的自动重试。	BAR_RETRY 配置参数
允许失败的恢复重新启动。	RESTARTABLE_RESTORE 配置参数
增大发送给存储管理器的备份大小估算值。	BAR_SIZE_FACTOR 配置参数
延长 RHAC 辅助服务器在外部备份期间等待检查点的时间。	BAR_CKPTSEC_TIMEOUT 配置参数
配置连续日志备份。	请参阅《GBase 8s 管理员参考》中的 ALARMPROGRAM
使用外部程序过滤或变换已备份的数据。	BACKUP_FILTER 配置参数 RESTORE_FILTER 配置参数

不要将 LTAPEDEV 配置参数设置为 /dev/null 或 NUL，因为这样将会禁用逻辑日志备份，而您只能恢复整个系统的备份。

onbar 安全性

缺省情况下，只有 UNIX™ 系统上的 gbasedbt 或 root 用户才能运行 onbar 命令。

要使其他用户能够运行 onbar 命令：

在 UNIX 系统上，创建 bargroup 组，并向该组添加用户。有关如何创建组的指示信息，请参阅您的 UNIX 文档。

限制

出于安全性考虑，建议不要使用 root 用户来运行 onbar 命令。

验证 onbar 和存储管理器的配置

在开始使用 onbar 和存储管理器之前，请确保 onbar 和存储管理器正确设置。

通过检查以下列表中的项来验证配置：

安装并配置了存储管理器来管理特定的存储设备。
对于 UNIX™，确保 BAR_BSALIB_PATH 配置参数正确指定了 XBSA 共享库，或未设置该参数且库位于缺省位置。
sm_versions 文件中包含一行用来标识特定于存储管理器的 XBSA 共享库的版本号。

验证 onbar 和存储管理器已正确设置后，在测试数据库上运行 onbar 以确保可以备份与恢复数据。要了解更多信息，请按照使用 onbar 备份中的指示信息操作。

使用 onbar 备份

您可以使用 onbar 实用程序来备份并验证存储空间（数据库空间、Blob 空间和智能大对象空间）以及逻辑日志文件。

要使用 onbar 执行备份：

准备备份。
使用 onbar 备份
监视备份进度。
验证备份。
备份存储管理器信息。

您可以在 shell 或批处理脚本中定制 onbar 和存储管理器命令。可以从作业调度程序调用 onbar。

准备备份数据

备份存储空间和逻辑日志之前，必须先准备系统并复制关键管理文件。

要准备备份数据：

配置 onbar 和存储管理器。
确保您有足够的逻辑日志空间。

onbar 在备份开始时检查可用的逻辑日志空间。如果日志几乎填满，onbar 在试图备份存储空间之前将备份并释放这些日志。如果日志包含充足的空间，onbar 将备份存储空间接着备份逻辑日志。
验证您是否有足够的临时磁盘空间。

数据库服务器使用临时磁盘空间来存储备份期间被覆盖以及内存中发生查询处理而溢出的之前数据映像。验证 DBSPACETEMP 环境变量和 DBSPACETEMP 配置参数指定的数据库空间是否具有满足您需要的足够空间。如果指定的数据库空间中空间不足，备份将失败，并且将使用根数据库空间，或者在填满根数据库空间之后，备份将失败。
将管理文件备份到不同的位置。
运行 oncheck -cD 命令以验证所有数据库服务器数据是否一致。

不需要在每个 0 级备份之前都检查一致性。在下次验证数据库的一致性之前，请勿放弃已知为一致的备份。

要备份的管理文件

onbar 备份不会替换重要配置文件的正常操作系统备份。必须手动备份关键管理文件。

请制作关键管理文件的当前版本的备份副本，以在紧急情况下使用。如果需要更换磁盘或者如果恢复到第二个计算机系统（导入的恢复），那么必须恢复这些文件。

备份以下管理文件：

紧急引导文件
onconfig 文件
sm_versions 文件
sqlhosts 文件 (UNIX™)
存储管理器配置和数据文件
存储在磁盘上的 Blob 空间中的简单大对象数据
存储在磁盘或光盘的 Blob 空间中的简单大对象的数据
存储于外部的数据（例如：由 DataBlade® 维护的外部表）

提示

尽管 onbar 包含 onconfig 和 sqlhosts 及其备份的文件，但较好的做法是将onconfig 和 sqlhosts 文件包含在您的系统归档中。通过将关键文件同时包含在 GBase 8s 和系统归档中，您在需要时可以有更多选择。

尽管 onbar 不备份以下项，但 onbar 将在恢复期间自动重新创建这些项。您不需要为这些文件创建备份副本：

已分配给数据库服务器但还未分配给表空间范围的数据库空间页面
镜像块，如果相应的主要块是可以访问的
临时数据库空间

onbar 不备份或恢复临时数据库空间中的数据。一旦恢复，数据库服务器重新创建空的临时数据库空间。

onbar -b 语法：备份

使用 onbar -b 命令可备份存储空间和逻辑日志。

要运行 onbar 命令，您必须是 root 用户或 gbasedbt 用户，或者是 UNIX™ 上 bargroup 组的成员。

用途

示例：备份整个系统
示例：备份所有联机存储空间和逻辑日志
示例：执行增量备份
示例：备份指定的存储空间和所有逻辑日志
示例：备份文件中指定的存储空间列表
示例：备份逻辑日志
示例：物理备份

使用 onbar 备份的语法

表 1. onbar -b 命令的选项

选项	描述
-b	指定一个备份备份存储空间和逻辑日志，包括当前逻辑日志。
dbspace_list	指定要备份的存储空间，以空格分隔。如果没有输入 dbspace_list 或 -f filename，onbar 会备份数据库服务器上所有联机的存储空间。
-c	关闭并备份当前逻辑日志和其他所有逻辑日志。
-C	启动连续日志备份。因为连续日志备份将无限期运行以等待逻辑日志填满，所以请保留专用存储设备和终端窗口。要停止连续日志备份，请使用中断命令（例如，CTRL-C 或 SIGTERM）停止 onbar 进程。
-cf	指定是否备份关键文件。有效值为： ● yes = 备份关键文件。该值为执行 0 级、1 级或 2 级备份时的缺省值。 ● no = 不备份关键文件。该值为备份逻辑日志文件时的缺省值。 ● only = 仅备份关键文件。
-f filename	备份 filename 值所指定的文本文件中列出的存储空间。使用该选项以避免每次备份时都要输入一长串存储空间。有关更多信息，请参阅文件中的存储空间列表。
-F	执行伪备份存储管理器应用程序不是必需的。实际上并没有发生备份，因此不可能从伪备份进行恢复。如果确实需要伪备份，请酌情少量使用。伪备份可能在以下情况下适用： ● 更改数据库日志记录方式 ● 将 RAW 表更改为 STANDARD 表 ● 允许用户在不执行备份的情况下使用新的日志、块或镜像 _ 在您作为管理员判定不需要备份的特殊情况下
-L	指定要在存储空间上执行的备份级别： ● 0 = 完整备份（缺省值） ● 1 = 自上次 0 级备份以来的更改 ● 2 = 自上次 1 级备份以来的更改如果您请求增量备份，而 onbar 发现没有为特定存储空间执行前一级的备份，那么 onbar会对该存储空间执行前一级的备份。例如，如果请求 1 级备份，而 onbar 未找到 0 级备份，那么它会转而进行 0 级备份。
-l	执行对所有逻辑日志文件的备份。当前逻辑日志文件未备份。如果使用的是 Storage Manager，它还会备份 Storage Manager 目录。
-O	覆盖常规备份限制。当 Blob 空间处于脱机状态时，使用该选项备份逻辑日志。如果 Blob 空间脱机时发生日志备份，返回码 178 将显示在 onbar 活动日志中。
-p	仅备份物理存储空间，而不备份逻辑日志。会将警告消息写入活动日志，以列出恢复存储空间时所需的最新日志文件的日志唯一标识。如果逻辑日志是连续进行备份的，请使用此选项。如有必要，将启动日志开关，以便可以备份此日志。如果当前的日志比最近一次存储空间的归档检查点日志新，那么不会启动日志开关。
-s	数据库服务器发生故障后，回收磁盘上现有的所有逻辑日志。当服务器处于脱机状态时，可以运行onbar -l -s 命令。如果可能，替换损坏的磁盘前请使用该选项。如果使用 onbar -r 在未损坏的磁盘上执行冷恢复，onbar 将自动回收逻辑日志。
-w	备份整个系统，其中包含基于单个检查点的所有存储空间和逻辑日志。备份的时间与备份信息存储在一起。在整个系统的备份中，所有存储空间中的数据是一致的，因此，不再需要恢复逻辑日志。如果不保存逻辑日志，您必须使用 -w 选项。

用途

在备份数据之前，请通过运行 oncheck -cD 命令来确保您的数据是一致的。

要运行 onbar 命令，您必须是 root 用户或 gbasedbt 用户，或者是 UNIX 上 bargroup 组的成员。有关更多信息，请参阅 onbar 安全性。

当数据库服务器处于联机、停顿或快速恢复方式时，可以备份存储空间和逻辑日志。

存储空间块可以存储在原始磁盘存储空间上、熟文件中。

仅备份联机的存储空间。使用 onstat -d 命令来确定哪些存储空间是联机的。备份期间，如果 onbar 遇到关闭的数据库空间，它将跳过并随后返回一个错误。如果存储空间处于脱机状态，请在存储空间回到联机状态时重新启动备份。

开始备份后，在 onbar 活动日志和数据库服务器消息日志中监视其进度。

可以单独备份逻辑日志或与存储空间一起备份。一旦逻辑日志填满，请立即对其进行备份，这样就可以复用这些日志，并防止在包含这些日志的磁盘丢失时发生数据丢失。如果日志文件填满，数据库服务器将暂停，直到备份了逻辑日志为止。可以手动备份逻辑日志，也可以运行 onbar -b -C命令来启动连续逻辑日志备份。逻辑日志备份始终是 0 级的。关闭当前逻辑日志后就可以对其进行备份。

如果执行整个系统的备份与恢复，那么无需恢复逻辑日志。但是，请在使用整个系统的备份时备份逻辑日志。这些日志备份允许您将数据恢复到整个系统备份后的某一时间，从而使数据丢失降到最低限度。

如果要运行连续的逻辑日志备份，然后启动整个系统备份，那么 onbar 进程会尝试保存逻辑日志。由于连续的逻辑日志备份正在运行，因此会返回错误消息以指示逻辑日志备份已在运行，且整个系统备份会返回非零错误代码。在这种情况下，逻辑日志只会备份一次。要避免该错误，请使用onbar -b -w -p 命令创建物理备份。

要在 onbar 中备份特定表或一组表，请将这些表存储在单独的数据库空间中，然后备份该数据库空间。或者，您也可以使用 archecker 实用程序执行表级别恢复。

示例：备份整个系统

以下命令在执行所有联机存储空间和逻辑日志的检查点后执行整个系统的 0 级备份：

onbar -b -w

以下命令执行整个系统的 1 级备份：

onbar -b -w -L 1

示例：备份所有联机存储空间和逻辑日志

以下命令执行所有联机存储空间和已用逻辑日志的标准 0 级备份：

onbar -b

示例：执行增量备份

以下命令执行标准 1 级备份：

onbar -b -L 1

示例：备份指定的存储空间和所有逻辑日志

以下命令对名为 fin_dbspace1 和 fin_dbspace2 的数据库空间以及所有逻辑日志执行 0 级备份：

onbar -b fin_dbspace1 fin_dbspace2

示例：备份文件中指定的存储空间列表

以下名为 listfile3 的样本文件包含要备份的存储空间列表：blobsp2.1、my_dbspace1、blobsp2.2、dbsl.1、rootdbs.1 和 dbsl.2。

blobsp2.1
# a comment                     ignore this text

       my_dbspace1           # back up this dbspace
; another comment
blobsp2.2                      dbsl.1
rootdbs.1      dbsl.2   ; backing up two spaces

以下命令备份 listfile3 文件中列出的存储空间：

onbar -b -f listfile3

示例：备份逻辑日志

以下命令启动手动逻辑日志备份：

onbar -b -l

以下命令备份当前逻辑日志文件：

onbar -b -l -c

示例：物理备份

以下命令备份所有存储空间，而不备份任何逻辑日志：

onbar -b -p -L 0

会将警告消息写入 onbar 活动日志文件中，说明该日志文件备份未启动。该消息还包含恢复存储空间时所需的最新日志文件的日志唯一标识。所需的最新日志文件包含最近一次备份的数据库空间的归档检查点。

示例消息：

2011-12-14 09\:30\:35 14277  14275 (-43354) WARNING: Logical logs were
     not backed up as part of this operation. Logs through log unique ID 9
     are needed for restoring this backup. Make sure these logs are backed
     up separately.

文件中的存储空间列表

您可以在文件中列出要备份或恢复的存储空间。

filename 值可以是任何有效的 UNIX™ 文件名：

简单文件名，例如：listfile_1
相对文件名，例如：../backup_lists/listfile_2 或 ..\backup_lists\listfile2
绝对文件名，例如：/usr//backup_lists/listfile3 或 c:\backup_lists\listfile3

文件的格式规则如下：

如果要恢复块，那么列出不带路径的存储空间名称。每行可以列出多个存储空间，用空格或制表符分隔。
如果要重命名块，那么列出旧块路径名、旧偏移量、新块路径名和新偏移量。在每项之间放置一个空格或一个制表符。将每个块的信息置于单独的行上。
注释以 # 或 ; 符号开头，并继续到当前行的结尾。
onbar 将忽略文件中的所有注释和空白行。

备份 Blob 空间

您可以在使用事务日志记录的数据库中备份 Blob 空间。

备份新的 Blob 空间之前，确保对 Blob 空间创建进行了记录的日志文件不再是当前的日志文件。您可以运行 onstat -l 命令来验证逻辑日志状态。

当用户更新或删除 Blob 空间中的简单大对象时，直到释放了包含删除记录的日志文件后才能释放 Blob 页以重新使用。必须备份日志文件才能将其释放。

重要

如果在更新或删除没有备份逻辑日志的 Blob 空间的数据后对该 Blob 空间执行热恢复，那么该 Blob 空间可能无法恢复。

要备份 Blob 空间：

通过运行 onstat -l 来验证逻辑日志的状态。
通过运行 onmode -l 命令来切换到下一个日志文件。
备份逻辑日志：
- 如果 Blob 空间是联机的，请运行 onbar -b -l -c 命令。
- 如果 Blob 空间是脱机的，请运行 onbar -b -l -O 或 onbar -b -O 命令。如果备份成功，onbar 将返回 178。
通过运行 onbar -b 或 onbar -b -w 命令来备份 Blob 空间。

onbar -m 语法：监视最近的 onbar 活动

您可以使用 onbar -m 命令来监视最近的 onbar 活动。只有有权执行备份与恢复操作的用户才可以使用此选项。

监视最近的 onbar 活动

表 1. onbar -m 命令的选项

选项	描述
-m	打印活动日志文件中 onbar 的最近活动。
lines	指定要输出的行数。缺省值为 20 行。
-r	使 onbar -m 命令重复。
秒	指定在重复之前等待的秒数。缺省值为 5 秒。

查看注册备份的列表

您可以为系统上执行的 onbar 注册备份创建列表。

要查看注册备份的列表：

在 sysutils 中创建一个视图，其中包含 bar_action、bar_instance 和 bar_object 目录表的信息。

在视图中包括以下字段：
- Backup_ID：内部生成的备份标识
- Type：定义备份是整个系统备份、数据库空间备份还是逻辑日志备份。
- Object_Name：所备份对象的名称。
- Ifx_Time：创建对象的时间。对于数据库空间备份，表示启动备份的检查点时间。对于逻辑日志，表示日志填满的时间。
- CopyID_HI：在存储管理器中查找对象的标识的高位部分。
- CopyID_LO：在存储管理器中查找对象的标识的低位部分。
- Backup_Start：此对象备份启动的日期和时间。
- Backup_End：此对象备份结束的日期和时间。
- Verify_Date：上次对此对象进行验证的时间（如果有）。
对视图运行 SELECT 语句。

示例

以下语句会创建包含备份信息的视图：

CREATE VIEW list_backups(Backup_ID, Type, Object_Name, Ifx_Time, CopyID_HI,
            CopyID_LO, Backup_Start, Backup_End, Verify_Date)
AS SELECT * FROM (
SELECT
        act_aid AS backup_id,
        DECODE(act_type, 5, "Whole-System", DECODE(obj_type, "L",
           "Logical log", "Dbspace")) AS Type,
        substr(obj_name,1, 8) AS Object_Name,
        min(DBINFO ('utc_to_datetime', seal_time)) AS Ifx_Time,
        ins_copyid_hi AS CopyID_HI,
        ins_copyid_lo AS CopyID_LO,
        act_start AS Backup_Start,
        act_end AS Backup_End,
        ins_verify_date AS Verify_Date

FROM
        bar_action A,
        bar_instance I,
        bar_object O
WHERE
        A.act_aid = I.ins_aid AND
        A.act_oid = O.obj_oid AND
        A.act_oid = I.ins_oid AND
        O.obj_type in ("R", "CD", "ND", "L")
GROUP BY 1,2,3,5,6,7,8,9
ORDER BY Ifx_Time, Backup_ID) AS view_list_backups

以下查询将返回所有备份：

SELECT * FROM list_backups

onbar -P 语法：打印备份逻辑日志

您可以使用 onbar -P 命令来打印已使用 onbar 实用程序备份的逻辑日志。

要运行 onbar 命令，您必须是 root 用户或 gbasedbt 用户，或者是 UNIX™ 上 bargroup 组的成员。

用途
示例：打印特定事务
示例：打印多个逻辑日志文件

打印已备份的逻辑日志

表 1. onbar -P 命令的选项

选项	用途
-b	打印与 Blob 空间 Blob 页面相关联的逻辑日志记录。数据库服务器将这些记录作为 Blob 空间日志记录的一部分存储在逻辑日志备份介质上。
-c	使用压缩字典来展开压缩的数据。
-l	打印逻辑日志记录的长列表。日志记录的长列表包含整个日志记录的复杂十六进制和 ASCII 转储。
-n starting_id-ending_id	打印包含在指定的日志文件范围中的逻辑日志记录。 starting_id 选项是要打印的第一个日志的标识。ending_id 选项是要打印的最后一个日志的标识。starting_id 选项的值必须小于 ending_id 选项的值。以连字符分隔开始和结束标识值。请勿包含空格。
-n unique_id	打印包含在指定的日志文件中的逻辑日志记录。 unique_id 选项是逻辑日志的唯一标识号。要确定特定逻辑日志文件的唯一标识，请使用 onstat -l 命令。
-P	打印已备份的逻辑日志信息
-q	不打印程序头
-ttblspace_num	打印与使用 tblspace_num 选项指定的表空间相关联的记录。以无符号整数或十六进制值的形式指定 tblspace_num 值。如果您没有使用 0x 前缀，那么值将解释为整数。整数必须大于零，并且必须存在于 systables 系统目录表的 partnum 列中。
-u username	打印特定用户的记录。用户名必须为现有登录名，并且必须符合登录名的特定于操作系统的规则。
-xtransaction_num	只打印与指定的事务相关联的记录。 transaction_num 必须是在零和 TRANSACTIONS -1 之间（包括零和 TRANSACTIONS -1）的无符号整数。其他信息：仅在前滚期间生成错误这一不太可能的情况下使用 -x 选项。当此情况发生时，数据库服务器将向包含违规事务的事务标识的消息日志发送消息。您可以将此事务标识与 -x 选项一起使用，以查找错误的原因。

用途

要查看已备份的逻辑日志，存储管理器必须正在运行。

此命令的输出将打印到 stdout。

示例：打印特定事务

以下命令打印由 gbasedbt 用户针对表空间 1048722 执行，且包含在逻辑日志文件 2 中的单个事务的相关信息：

onbar -P -n 2 -l -q -b -u "gbasedbt" -t 1048722 -x 1

此命令的输出可能为：

log uniqid: 2.
1665d0   120  DPT      1        2  0        5
         00000078 0002006c 00000010 0000fefe ...x...l ........
                  00000001 00000000 000077e3 00000000 ........ ..w.....
                  00000005 00000005 00002a24 00000001 ........ ..*$....
                  00100004 0a0c21b8 00002a48 00000001 ......!. ..*H....
                  00100006 0a0c2288 00002ea1 00000001 ......". ........
         0010001b 0a0c3810 00002bee 00000001 ......8. ..+.....
                  00100015 0a0c3a18 00002a3d 00000001 ......:. ..*=....
         00100005 0a0c57c0                   ......W.
166648   60   CKPOINT  1        0  1665d0   1
         0000003c 00000042 00000010 0000fefe ...<...B ........
         00000001 001665d0 000077e3 00000000 ......e. ..w.....
                  00010005 00000002 00000002 001665a0 ........ ......e.
                  00000007 ffffffff 00084403          ........ ..D.

示例：打印多个逻辑日志文件

以下命令打印标识为 2、3、4、5、10、11 和 12 的逻辑日志文件的逻辑日志记录：

onbar -P -n 2-5 -n 10-12

onbar -v 语法：验证备份

使用 onbar -v 命令可验证 onbar 实用程序所创建的备份是否完整且可以恢复。

要运行 onbar 命令，您必须是 root 用户或 gbasedbt 用户，或者是 UNIX™ 上 bargroup 组的成员。

必须有足够的临时空间可用。有关更多信息，请参阅用于备份验证的临时空间。

用途
示例：执行备份的时间点验证
示例：验证文件中列出的存储空间的备份
示例：onbar 活动日志验证消息
示例：archecker 消息日志验证消息

验证备份

表 1. onbar -v 命令的选项

选项	描述
-v	验证备份。服务器可以采用任何方式。如果验证成功，那么可以安全地恢复存储空间。可以验证整个系统的备份或仅物理的备份。不能验证逻辑日志。
space	要验证的存储空间的名称。如果输入多个存储空间名称，那么使用空格来分隔这些名称。
-f filename	验证由 filename 提供其路径名的文本文件中列出的存储空间。使用该选项以避免每次验证存储空间时都要输入一长串存储空间。您可以使用任何有效的 UNIX 路径名和文件名。有关该文件的格式，请参阅文件中的存储空间列表。此文件可以在每行列出多个存储空间。
-p	验证仅物理的备份。
-t "time"	指定验证数据库空间的日期和时间。必须以引号括起。如何输入时间取决于当前的 GLS 语言环境约定。如果设置了 GL_DATETIME 环境变量，那么必须根据该变量指定日期和时间。如果未设置 GLS 语言环境，请使用 ANSI 样式的日期格式：YYYY-MM-DD HH:MM:SS。
-w	验证整个系统的备份。

用途

onbar -v 命令运行 archecker 实用程序。 archecker 实用程序验证恢复备份所需的所有页面是否以正确的格式存在于介质上。成功验证备份后就可以安全恢复了。

当验证备份时，onbar 将摘要消息写入到 bar_act.log 中，它报告验证了哪些存储空间以及验证是成功的还是失败的。

onbar -v 命令仅验证智能大对象空间中智能大对象的范围。使用 oncheck -cS 命令进行完整的检查。

onbar -v 命令不能验证 Blob 空间中数据行和简单大型对象之间的链接。使用 oncheck -cD 命令作为代替来验证 Blob 空间中的链接。

示例：执行备份的时间点验证

以下命令验证某个时间点的备份：

onbar -v -t "2011-12-10 10\:20\:50"

示例：验证文件中列出的存储空间的备份

以下命令验证文件 bkup1 中列出的已备份的存储空间：

onbar -v -f /usr/backups/bkup1

示例：onbar 活动日志验证消息

以下示例显示 onbar 活动日志中有关验证的消息：

数据库空间 dbs2.2 的 0 级备份已通过验证，如下：

开始 dbs2.2 的 0 级备份验证（存储管理器复制标识：##）
成功完成 0 级备份检验。

rootdb 的 0 级备份验证失败，如下：

开始 rootdbs 的 0 级备份验证（存储管理器复制标识：##）。
错误：无法关闭物理检查：error_message。

示例：archecker 消息日志验证消息

更多详细信息可在 archecker 消息日志中获得，如下：

状态：扫描已通过
状态：控制页检查已通过
状态：开始检查数据库空间 dbs2.2.
状态：正在检查 dbs2.2:TBLSpace
.
.
状态：已验证的表/分段：1
归档验证已通过

用于备份验证的临时空间

验证备份时，必须有 15 到 25 MB 的临时空间可用。

在备份验证期间，对于中等大小的系统（40 到 50 GB），archecker 实用程序需要大约 15 MB 的临时空间，对于大型系统则需要大约 25 MB。这个临时空间存储在文件系统上由 AC_STORAGE 参数指定的目录中，而不在数据库空间中。临时文件包含关于分区页、块中的可用页和保留页的备份和复制的位图信息，（以下可选）还可以包含 Blob 空间中的可用页和调试信息。archecker 实用程序必须具有该临时目录的许可权。

如果备份验证成功，这些文件将被删除。如果备份验证失败，这些文件将继续保留。将它们复制到另一个位置，以便GBase 软件支持可以进行查看。

如果数据库服务器只包含数据库空间，请使用以下公式估算 archecker 临时文件使用的临时空间量（以 KB 为单位）：

空间 = (130 KB * number_of_chunks) + (pagesize * number_of_tables) + (.05 KB * number_of_logs)

对于 GBase 8s，如果您的数据库服务器包含 Blob 空间或智能大对象空间，那么使用以下公式估计 archecker 临时文件的临时空间大小：

空间 = (130 KB * number_of_chunks) + (pagesize * number_of_tables) + (.05 KB * number_of_logs) + (pagesize * (num_of_blobpages/252))

number_of_chunks

估计用于数据库服务器的块的最大数目。

pagesize

系统页的大小（以 KB 为单位）。

number_of_tables

估计用于数据库服务器的表的最大数目。

number_of_logs

数据库服务器上的逻辑日志数。

num_of_blobpages

Blob 空间中 Blob 页的数目或智能大对象空间的数目。（如果数据库服务器包含智能大对象空间，那么使用智能大对象空间的数目替换num_of_blobpages。）

例如，在页面大小为 2 KB 的 50 千兆字节系统上，将需要 12.9 兆字节的临时磁盘空间。该系统不包含任何 Blob 空间，如以下语句所示：

13,252 KB = (130 KB * 25 块) + (2 KB * 5000 个表) + (.05 KB * 50 个日志) + (2 KB * 0)

要将 KB 转换为 MB，请将结果除以 1024：

12.9 MB = 13,252/1024

验证失败

备份验证可能因各种原因而失败。如果备份验证失败，请不要试图恢复它。

由于 onbar 在存储管理器上找不到备份对象，因此验证失败的原因是不可预测的，从数据库服务器毁坏到恢复失败，不一而足。实际上，表面上恢复可能成功，但它隐藏了数据或介质的真正问题。

损坏页的备份

如果页面损坏，问题在于数据库而不是备份或介质。

在所有产生错误的表上运行 oncheck -cd，然后重新执行备份和验证。要检查范围和保留页，请运行 oncheck -ce 和 oncheck -cr。

损坏的控制信息的备份

在这种情况下，所有数据都是正确的，但是某些备份控制信息不正确，这可能使恢复出现问题。向 GBase 软件支持请求协助。

缺少数据的备份

当备份缺少数据时，它可能无法恢复。数据丢失后，请尝试从较旧备份中恢复。然后恢复当前逻辑日志。

数据库服务器不一致数据的备份

有时会出现以下情况：archecker 返回“成功”给 onbar，但在 archecker 消息日志中显示“失败”。当 archecker 验证 onbar 已正确备份数据，但数据库服务器数据在备份时无效或不一致时就会出现这种情况。

对备份验证失败的原因进行诊断

如果备份验证失败，您可以执行步骤来诊断并尝试修正问题。

要对备份验证失败的原因进行诊断：

验证 AC_CONFIG 环境变量和 archecker 配置文件的内容是否设置正确。

如果这些变量未正确设置，那么 onbar 活动日志将打印一条消息。
将数据备份到不同的介质。

不要复用原始的备份介质，因为它可能已损坏。

不要使用基于该备份的任何备份。如果 0 级备份验证失败，不要使用相应的 1 级和 2 级备份。
验证新备份。

如果验证成功，那么可以恢复存储空间。
使用存储管理器使验证失败的备份到期，然后在不带参数的情况下运行 onsmsync 实用程序，以从 sysutils 和紧急引导文件中除去坏的备份。
如果验证再次失败，请致电 GBase 软件支持，并向他们提供以下信息：
- 备份工具名称（onbar）
- 数据库服务器 online.log
- archecker 消息日志
- 包含备份的位图以及重要备份页副本的 AC_STORAGE 目录
如果只有备份的一部分损坏，GBase 软件支持可帮助您确定在紧急情况下可以恢复备份的哪一部分。

GBase 软件支持可能建议您针对一组表运行 oncheck 选项。

验证到期备份

可以验证到期备份，以防后续备份无效。

要验证到期备份：

检查存储管理器上备份保存集的状态。如果存储管理器使备份保存集到期，那么 archecker 实用程序无法对其进行验证。
使用存储管理器命令激活已到期的备份保存集。请参阅您的存储管理器文档。
重新运行 onbar -v 命令。

在备份缺少数据时进行恢复

如果因为缺少数据导致备份验证失败，您可以从较旧备份执行恢复。

要在备份缺少数据时进行恢复：

选择早于已失败备份的备份的日期和时间。要执行时间点验证，请使用 onbar -v -t time space 命令。
如果较旧备份通过验证，请使用相同 time 值执行时间点物理恢复，然后执行日志恢复，如下所示：
```
onbar -r -p -t time space
onbar -r -l
```
在存储管理器中使损坏的备份到期。
不带自变量运行 onsmsync 命令。

onsmsync 实用程序将从紧急引导文件和 sysutils 数据库中除去存储管理器不再保留的备份，从而防止 onbar 尝试使用此类备份。

使用 onbar 恢复数据

可以使用 onbar 实用程序来恢复由 onbar 实用程序备份的数据。

恢复数据前，请使用恢复前的核对表来确定是否需要恢复，以及准备恢复。

要使用 onbar 实用程序执行恢复：

使备份期间可用的存储设备可用于恢复。
如有必要，添加足够的临时空间来执行恢复。热恢复的逻辑日志恢复部分需要临时空间。最小临时空间量等于分配的逻辑日志空间总量与要重放的日志文件数中较小的一个。
使用合适的选项运行 onbar -r 命令以恢复数据。
监视 onbar 活动日志。
恢复完成后，运行 onstat -d 命令来验证所有存储空间是否都已恢复。flags 列中的字母 O 表示该块处于联机状态。

预恢复核对表

使用该核对表可确定是否需要恢复，并准备恢复。

要准备恢复：

决定您是否需要进行恢复操作。如果存在其中一个或多个问题，请执行恢复来修复该问题：
- 数据是否已丢失或毁坏？
- 已落实的事务错误需要撤销吗？
- 数据库服务器是停止运行了还是发生了磁盘故障？
- 存储空间或块是关闭了还是不一致？
通过使用数据库服务器监视工具来诊断问题。
如果需要恢复根数据库空间或包含物理日志和逻辑日志文件的数据库空间，必须执行冷恢复。在冷恢复期间，数据库服务器必须处于脱机状态。请要求您的客户机用户注销系统。
在执行恢复之前，联系相应的供应商以解决以下类型的问题：
- 存储管理器
- XBSA 连接
- 操作系统
- 存储介质

存储空间状态和所需操作

要确定每个存储空间及其块的状态，请检查 onstat -d 命令的输出。存储空间状态决定解决问题所需执行的操作。数据库服务器必须处于联机状态。

下表描述了有关块状态以及解决问题所需操作的 onstat -d 命令输出。块状态信息位于输出的第一部分（存储空间）和第二部分（块）中 flags 列的第二个位置处。

表 1. 块标志描述和所需操作

块标志	存储空间或块状态	需要采取的操作
（无标志）	存储空间不再存在。	对删除存储空间前的时间执行时间点冷恢复。
D	块已关闭或存储空间被禁用。	对受影响的存储空间执行热恢复。
I	块已进行物理恢复，但还需要逻辑恢复。	执行逻辑恢复。
L	存储空间在进行逻辑恢复。	请重试逻辑恢复。
N	块已重命名并且已关闭或不一致。	当物理设备可用时对块进行热恢复。
O	块是联机的。	不需要任何操作。
P	对存储空间进行物理恢复。	如果尚未进行恢复，那么执行逻辑恢复。
R	正在恢复存储空间。	执行物理或逻辑恢复。
X	存储空间或块是最近镜像的。	不需要任何操作。

存储设备可用性

验证备份中使用的存储设备和文件是否可用于恢复。

如果在 0 级备份后删除了某个数据库空间或镜像设备，那么该数据库空间或镜像设备在开始恢复时必须可用于数据库服务器。如果存储设备不可用，那么数据库服务器无法写入块中，恢复将失败。

如果在上次备份后添加了块，那么块设备在前滚逻辑日志时必须可用于数据库服务器。

onbar -r 语法：恢复数据

要执行完整的恢复，请使用 onbar -r 命令。

要运行 onbar 命令，您必须是 root 用户或 gbasedbt 用户，或者是 UNIX™ 上 bargroup 组的成员。

用途
示例：执行整个系统的恢复
示例：恢复特定存储空间
示例：分阶段执行热恢复
示例：时间点恢复
示例：法语语言环境中的时间点恢复
示例：分阶段的时间点恢复
示例：恢复已删除的存储空间和块

执行恢复

重命名块

表 1. onbar -r 命令的选项。

选项	描述
-r	指定恢复。如果数据库服务器处于脱机状态，onbar 将执行冷恢复。如果数据库服务器处于联机、停顿或快速恢复方式，onbar 将执行热恢复。在冷恢复中，-r 选项会恢复所有存储空间，回收并恢复逻辑日志。在热恢复中，-r 选项恢复所有脱机的存储空间并恢复逻辑日志。必须先指定 -r 选项。
space	指定将备份哪些存储空间，以空格分隔的一个或多个数据库空间、Blob 空间或智能大对象空间名称的列表表示。 onbar 仅恢复列出的存储空间。如果数据库服务器处于脱机状态，必须列出所有关键数据库空间。不能指定临时空间。
-C	从当前逻辑日志磁带中连续恢复逻辑日志，而不发送安装磁带的提示。服务器处于暂挂日志恢复状态，在最后一个可用日志恢复后，该命令依然存在。如果日志存在于多个磁带中，那么服务器将发出提示。配置参数 RESTARTABLE_RESTORE 不会影响连续日志恢复。
-e	指定外部恢复。在外部恢复存储空间后，运行 onbar -r -e 命令。将存储空间标记为已物理恢复，恢复逻辑日志并使存储空间联机。
-f filename	指定用于列出要恢复或重命名的存储空间的文本文件的路径和文件名。使用该选项可避免输入一长串存储空间。有关更多信息，请参阅文件中的存储空间列表。
-l	指定仅逻辑恢复。恢复并前滚逻辑日志。逻辑恢复仅应用于已物理恢复的存储空间。重要：为提高性能，在热恢复期间以并行方式重放逻辑日志事务。使用 ON_RECVRY_THREADS 配置参数来设置并行线程数。要在冷恢复期间以并行方式重放逻辑日志事务，请使用 OFF_RECVRY_THREADS 配置参数。有关更多信息，请参阅《GBase 8s 性能指南》。
-n log	指示冷恢复中要恢复的最后一个逻辑日志的唯一标识。数据库服务器必须处于脱机状态。要查找唯一标识，请使用 onstat -l 命令。日志点恢复是特殊的时间点恢复。必须在日志点恢复中恢复所有存储空间以保持数据的一致性。如果指定的日志后存在任何逻辑日志，onbar 不会恢复这些日志，它们的数据将丢失。如果特定逻辑日志应用于多个时间线，那么 onbar 将使用最新的时间线。不能与 -p 选项一起使用。
-n new_path	指定块的新路径。与 -rename 选项一起使用。
-O	覆盖内部错误检查。允许联机存储空间的恢复。强制重新创建不再存在的块文件。用来覆盖内部错误检查以执行以下任务： ● 强制联机存储空间的恢复。如果要恢复的存储空间的列表中某个存储空间是联机的，那么 onbar 将使该存储空间脱机，然后将其恢复。如果此操作成功，那么 onbar将完成并带有退出码 177。 ● 强制创建不存在的块文件。如果所恢复的存储空间的块文件不再存在，那么 onbar将重新创建该文件。新创建的块文件是格式化的磁盘空间，不是原始磁盘空间。如果onbar 成功地重新创建了缺少的块文件，那么 onbar 将完成并带有退出码 179。 ● 如果缺少关键存储空间，那么强制冷恢复继续进行。在冷恢复中，onbar 将检查每个关键空间是否正在恢复。此检查偶尔会引起假警告。如果警告有效，那么恢复失败。如果警告为 false 并且 onbar 成功恢复了服务器，那么 onbar 将完成并带有退出码 115。对整个系统的恢复使用 -O 选项仅仅是为了重新创建丢失的块文件。当数据库服务器处于联机状态时不能使用 onbar -r -w -O 命令，因为在整个系统恢复期间无法让根数据库空间脱机。
-o new_offset	指定已重命名的块的偏移量。与 -rename 选项一起使用。
-o old_offset	指定要重命名的块的偏移量。与 -rename 选项一起使用。
-p	指定仅物理恢复。除非您使用整个系统的恢复，否则在可以访问数据之前必须在逻辑恢复后执行物理恢复。该选项关闭冷恢复前的自动日志回收。如果 LTAPEDEV 配置参数设置为 /dev/null 或 NUL，那么必须在恢复期间使用 -p 选项。不能与 -n 选项一起使用。
-p old_path	指定要重命名的块的路径。与 -rename 选项一起使用。
-rename	在冷恢复期间重命名一个或多个块。数据库服务器必须处于脱机状态。如果需要将存储空间恢复到与完成备份的磁盘不同的磁盘上，该选项很有帮助。可以重命名任意类型的块，包括关键块和镜像块。您可以重命名具有 0 级备份的块。
-t "time"	指定在冷恢复中要从逻辑日志恢复的最后一个事务的时间。数据库服务器必须处于脱机状态。指定的所有存储空间都将恢复到相同的时间点。但是，如果先执行物理恢复，然后执行逻辑恢复，那么该逻辑恢复可以恢复到更晚的时间点。例如，您可能检测到当前备份损坏，且需要恢复先前备份。在这种情况下，请使用先前备份的时间戳记启动物理恢复，然后将逻辑恢复启动到更新的时间戳记。时间点恢复通常用来从错误恢复。例如：如果您意外删除了数据库，那么可以将服务器恢复到删除数据库之前的时间点。要确定时间点恢复的相应日期和时间，请使用 onlog 实用程序。onlog实用程序输出显示了逻辑日志中已落实事务的日期和时间。在恢复命令中指定的时间后发生的所有数据事务将丢失。使用引号括起日期和时间。英语语言环境的格式是 yyyy-mm-dd hh:mm:ss。如果设置了GL_DATETIME 环境变量，那么必须根据该变量指定日期和时间。
-w	从上次整个系统的备份对所有存储空间和逻辑日志执行整个系统的恢复。数据库服务器必须处于脱机状态。整个系统的恢复完成后，服务器处于停顿方式。如果指定 onbar -r -w 而不带整个系统的备份，将返回返回码 147，因为 onbar 找不到作为整个系统的备份一部分而备份的任何存储空间。
-X	停止连续逻辑日志恢复。将服务器保留在逻辑恢复暂挂状态中的停顿方式下，而不恢复其他日志。

用途

您可以恢复存储在原始文件和格式化文件中的存储空间。如果系统包含主存储空间和镜像存储空间，那么恢复（外部恢复除外）期间 onbar 将同时写入主块和镜像块。不能指定恢复临时空间。恢复关键数据库空间（例如根数据库空间）时，数据库服务器重新创建临时数据库空间，但它们为空。

如果 BAR_MAX_BACKUP 配置参数设置为大于 1 的值，那么 onbar 将并行恢复存储空间。要加速恢复，您可以添加更多 CPU 虚拟处理器。

在以下情况下，当数据库服务器处于联机状态时，可以在热恢复中恢复非关键存储空间：

存储空间处于联机状态，但它的一个块处于脱机、正在恢复或不一致状态。
存储空间处于脱机或关闭状态。

您无法同时执行多个热恢复。如果您需要恢复多个存储空间，请对 onbar 指定要恢复的存储空间集，或通过不显式指定任何空间来允许 onbar恢复所有关闭的存储空间。

提示

要在恢复中得到更快的性能，请为备份存储空间和逻辑日志指定不同的存储设备。如果物理备份和逻辑备份在存储介质上混合在一起，这将花费较长的时间用于在恢复期间扫描介质。

在某些情况下，您可能想分阶段地执行恢复。如果有多个设备可用于恢复，那么可以分别或同时恢复多个存储空间，然后再执行单一的逻辑恢复。

缺省情况下，onbar 恢复最新的备份。如果不希望恢复最新的备份，可以从较旧备份中进行恢复：例如，在备份验证失败或备份介质丢失时。您可以执行时间点恢复或日志点恢复。或者，您也可以使存储管理器中的错误备份到期，运行 onsmsync 命令，然后从较旧备份中恢复。如果意外删除了某存储空间，您可以使用时间点恢复或日志点恢复来将其恢复。

通过使用 -O 选项，可以强制执行联机存储空间的恢复（除了关键数据库空间以外）。数据库服务器开始恢复每个存储空间之前会自动将其关闭。让存储空间脱机以确保在恢复进程中用户不会试图更新该空间中的表。

可以在冷恢复期间使用 onbar 指定新块路径和偏移量来重命名块。如果需要将存储空间恢复到与完成备份的磁盘不同的磁盘上，该选项很有帮助。可以重命名任意类型的块，包括关键块和镜像块。

示例：执行整个系统的恢复

整个系统的恢复是冷恢复，必须在服务器处于脱机状态时执行。以下命令恢复整个系统的备份：

onbar -r -w

示例：恢复特定存储空间

以下示例恢复两个特定存储空间 fin_dbspace1 和 fin_dbspace2：

onbar -r fin_dbspace1 fin_dbspace2

示例：分阶段执行热恢复

以下命令执行物理恢复，备份逻辑日志，然后执行逻辑恢复：

onbar -r -p
onbar -b -l
onbar -r -l

示例：时间点恢复

以下命令将数据库服务器数据恢复到其在特定日期和时间的状态：

onbar -r -t “2011-05-10 11\:35\:57”

在此示例中，恢复将重放在指定时间或指定时间之前落实的事务，包括带有落实时间 11:35:57 的所有事务。正在处理但未在 11:35:57 之前落实的事务将回滚。

示例：法语语言环境中的时间点恢复

法语语言环境 fr_fr.8859-1 的缺省日期和时间格式使用格式“%A %.1d %B %iY %H:%M:%S”。

以下命令将数据恢复到针对法语语言环境格式化的特定时间点：

onbar -r -t "Lundi 6 Juin 2011 11:20:14"

可以将 GL_DATETIME 设置为使用日期、月份、两位数表示的年份、小时、分钟和秒的不同日期和时间格式。例如：

%.1d %B %iy %H:%M:%S

以下命令通过为法语语言环境指定两位数年份来恢复到特定时间点：

onbar -r -t "6 Juin 11 11:20:14"

示例：分阶段的时间点恢复

以下命令执行到相同时间点的物理恢复和逻辑恢复：

onbar -r -p -t "2011-05-10 11\:35\:57"
onbar -r -l -t "2011-05-10 11\:35\:57"

示例：恢复已删除的存储空间和块

假设某个事务删除了名为 dbspace1 的存储空间，并在时间 2011-05-10 12:00:00 删除了块。以下命令在服务器处于脱机状态时恢复该存储空间并重新创建已删除的块：

onbar -r -t "2011-05-10 11\:59\:59" -O

避免回收逻辑日志

onbar -r 命令自动回收逻辑日志。但是，在某些情况下需要避免回收逻辑日志。

使用 onbar -r -p 和 onbar -r -l 命令跳过日志回收。

如果将 LTAPEDEV 配置参数设置为 /dev/null（UNIX™ 上），那么不会在任何 onbar 恢复中回收逻辑日志（例如，onbar -r 或 onbar -r -w）。

应在以下情况下避免回收逻辑日志：

执行导入的恢复时

在源数据库服务器而不是在目标数据库服务器上回收逻辑日志。
执行冷恢复前重新初始化数据库服务器 (oninit -i)

重新初始化将创建新逻辑日志，而其中不包含您要恢复的数据。
为包含逻辑日志的数据库空间安装新磁盘

从旧磁盘而不是新磁盘回收日志。

执行冷恢复

如果关键存储空间由于磁盘故障或毁坏的数据而受损，您必须执行冷恢复。如果磁盘出故障，那么须在可以执行冷恢复之前替换该磁盘以恢复数据。

如果在没有备份的情况下尝试执行冷恢复，那么未备份的存储空间中的数据将丢失。

要执行冷恢复：

通过运行 onmode -ky 命令来关闭服务器。
如果必须更换或维修包含逻辑日志文件的磁盘，请使用 onbar -b -l -s 命令回收损坏磁盘上的逻辑日志文件。

否则，onbar 将自动回收逻辑日志。
如有必要，请维修或更换损坏的磁盘。
如果 GBASEDBTDIR 中的文件已损坏，请将管理文件的备份复制到其原始位置。

否则，不需要复制管理文件。
通过运行 onbar -r 命令来恢复关键和非关键存储空间。

恢复完成后，数据库服务器处于停顿方式。
通过运行 onmode -m 命令来启动服务器。
通过运行 onsmsync 命令来同步存储管理器。

通过使用 onbar 来配置连续日志恢复

使用连续日志恢复可保持辅助系统（热备份）可用，以在主系统发生故障时替换主系统。

主系统和辅助系统上的 GBase 8s 版本必须相同。

要使用 onbar 配置连续的日志恢复：

在主系统上，使用 onbar -b -L 0 命令执行 0 级备份。
导入已在辅助服务器存储管理器中创建的备份对象。
在辅助系统上，使用 onbar -r -p 命令执行物理恢复。

在辅助系统上完成物理恢复后，数据库服务器将在快速恢复方式下等待恢复逻辑日志。
在主系统上，使用 onbar -b -l 命令备份逻辑日志。
将备份的逻辑日志传输到辅助系统，然后使用 onbar -r -l -C 命令将其恢复。
对可用于备份与恢复的所有逻辑日志重复步骤 4 和 5。
如果您要在紧急备用的辅助系统上执行连续日志恢复，请运行以下命令来完成逻辑日志恢复并停顿服务器：
- 如果逻辑日志可用于恢复，请运行 onbar -r -l 命令。
- 在恢复所有可用逻辑日志之后，运行 onbar -r -l -X 命令。

使用混合恢复来恢复数据

在您需要恢复服务器时，紧急数据处于联机状态并且为可用之前，您可以使用混合恢复来减少时间。紧急数据是您认为对于业务运营很关键的数据。

在混合恢复中，您首先对关键数据库空间（根数据库空间以及包含物理日志和逻辑日志的数据库空间）和包含紧急数据的数据库空间执行冷恢复。由于您并不恢复所有数据库空间，因此可以使服务器更快联机。然后在一个或多个热恢复中恢复剩余的存储空间。

要执行混合恢复：

通过运行 onmode -ky 命令来关闭数据库服务器。
通过使用关键和紧急数据库空间名称列表运行 onbar -r 命令来对关键和紧急数据库空间执行冷恢复。

可以指定从较旧备份进行恢复的时间点。
通过运行 onmode -m 命令来启动服务器。
通过运行 onsmsync 命令来同步存储管理器。
通过运行 onbar -r 命令来对剩余存储空间执行热恢复。

您可以执行多个热恢复以对某些存储空间划分优先级。

示例

示例 1：简单混合恢复

一个数据库服务器除根数据库空间之外，还有以下五个数据库空间：logdbs、dbs_1、dbs_2 和 dbs_3 和 dbs_4。逻辑日志存储在logdbs 中，物理日志位于根数据库空间中。必须在初始冷恢复期间恢复的关键数据库空间为 rootdbs 和 logdbs。包含紧急数据的数据库空间是 dbs_1。以下命令将关闭数据库服务器，对关键和紧急数据库空间执行冷恢复，然后重新启动数据库服务器：

onmode -ky
onbar -r rootdbs logdbs dbs_1
onmode -m

数据库服务器启动后，rootdbs、logdbs 和 dbs_1 数据库空间中存储的任何数据都可访问。

以下命令同步存储管理器，并对剩余数据库空间 dbs_2、dbs_3 和 dbs_4 执行热恢复：

onsmsync
onbar -r

示例 2：时间点混合恢复

以下命令在初始冷恢复中对存储空间的子集（包括所有关键数据库空间）执行冷恢复，对 dbspace_2 和 dbspace_3 执行热恢复，接着对dbspace_4 和 dbspace_5 执行热恢复，最后对所有剩余的存储空间执行热恢复：

onbar -r -t "2011-05-10 11\:35\:57" rootdbs logspace_1 dbspace_1
onmode -m
onsmsync
onbar -r dbspace_2 dbspace_3
onbar -r dbspace_4 dbspace_5
onbar -r

针对使用混合恢复的策略

要实现混合恢复策略，请仔细选择在创建数据库和数据库对象时要将其放置到的数据库空间集。

onbar 会备份与恢复物理实体而非逻辑实体。因此，onbar 无法恢复特定数据库或一组特定的表。相反，onbar 将恢复一组特定的存储空间。跟踪这些存储空间中存储的内容将取决于您。

例如：考虑数据库空间 cat_dbs 中的带有目录的数据库：

create database mydb in cat_dbs with log;

在数据库空间 tab_dbs_1 和 tab_dbs_2 之间将对该数据库中的某个表进行分段：

create table mytab (i integer, c char(20))
fragment by round robin in tab_dbs_1, tab_dbs_2;

表的索引存储在数据库空间 idx_dbs 中：

create index myidx on mytab(i) in idx_dbs;

如果您需要恢复服务器，那么只有在恢复包含数据库目录、表数据和索引的数据库空间之后，您才能访问示例数据库中的所有数据：在本例中，为数据库空间 cat_dbs、tab_dbs_1、tab_dbs_2 和 idx_dbs。

要简化数据的管理和跟踪，请将数据库空间集划分为用于存储特定紧急程度的数据的子集。当您创建数据库对象时，请将这些数据库对象放置在适合其紧急程度的数据库空间中。例如，如果您有三个紧急程度级别的数据，可能希望将与最紧急数据相关联的所有对象（数据库目录、表和索引）放置在特定的数据库空间集内：例如，urgent_dbs_1、urgent_dbs_2、...urgent_dbs_n。您会将与紧急程度较低的数据相关联的所有对象放置在不同的数据库空间集内：例如，less_urgent_dbs_1、less_urgent_dbs_2、... less_urgent_dbs_k。最后，您会将其余数据放置在不同的数据库空间集内：例如，non_urgent_dbs_1、non_urgent_dbs_2、.... non_urgent_dbs_r。

如果您需要恢复服务器，那么您应首先对所有关键数据库空间和包含紧急数据的数据库空间（从 urgent_dbs_1 到 urgent_dbs_n）执行冷恢复。例如，假设在 logdbsp_1 和 logdbsp_2 这两个数据库空间之间分发逻辑日志，并且物理日志在 rootdbs 中。因此，关键的数据库空间就是rootdbs、logdbsp_1 和 logdbsp_2。

通过发出以下 onbar 命令来执行初始冷恢复：

onbar -r rootdbs logdbsp_1 logdbsp_2 urgent_dbs_1 ... urgent_dbs_2

您可以使服务器联机，并且所有业务紧急数据都可用。

接下来，对不怎么紧急的数据执行热恢复：

onsmsync
onbar -r less_urgent_dbs_1 less_urgent_dbs_2 ..... less_urgent_dbs_k

最后，您可以通过发出以下命令来对服务器的剩余部分执行热恢复。

onbar -r

在具有几十个数据库空间的更大型系统中，可以将混合恢复的热恢复部分划分为几个热恢复，每个热恢复只恢复系统中剩余要恢复的数据库空间的其中一小部分。

恢复期间重新创建块文件

如果磁盘或文件系统发生故障，数据库空间中可能会缺少一个或多个块文件。使用 -O 选项可在恢复期间重新创建缺少的块文件以及任何必要的目录。

如果文件系统上存在的空间不足，恢复会失败。新创建的块文件是经过格式化的文件，并为 UNIX™ 上的组 gbasedbt 所有。

在使用熟块时恢复

可以在恢复期间重新创建缺少的熟块文件。

限制

如果逻辑日志中包含块创建记录，那么 onbar 不会在逻辑恢复期间重新创建块文件。

要在使用熟块时恢复：

安装新磁盘。
基于您的系统，执行以下某个任务：
- 在 UNIX™ 上将设备作为文件系统安装。
为块文件分配磁盘空间。
运行 onbar -r -O space 命令来重新创建块文件并恢复数据库空间。

在使用原始块时恢复

可以在恢复期间重新创建缺少的原始块文件。

要在使用原始块时恢复：

安装新磁盘。
对于 UNIX™，如果使用原始设备的符号链接，那么为脱机块创建指向新安装的磁盘的新链接。

onbar 恢复符号链接指向的块文件。
发出 onbar -r space 命令来恢复数据库空间。

重新初始化数据库服务器并恢复数据

重新初始化磁盘空间将毁坏数据库服务器管理的所有现有数据。但是，您可以根据重新初始化之前执行的备份来恢复数据。

您必须拥有所有存储空间的当前 0 级备份。

初始化期间，onbar 将紧急引导文件保存到其他地方，并启动一个全新的空紧急引导文件。因此，重新初始化数据库服务器之前执行的任何备份都无法识别。必须使用在初始化之前保存的紧急引导文件的副本来恢复先前的数据库服务器实例。

要重新初始化数据库服务器并恢复旧数据：

将紧急引导文件、oncfg 文件和 onconfig 文件复制到不同的目录。
在 onconfig 文件中将 FULL_DISK_INIT 配置参数设置为 1。
关闭数据库服务器。
通过运行 oninit -i 命令来重新初始化数据库服务器。
将管理文件移至数据库服务器目录。

如果管理文件不可用，将它们从最近一次备份复制到数据库服务器目录中。
通过运行 onbar -r -p -w 命令来执行恢复。

不要回收逻辑日志。
验证是否恢复了关键和非关键存储空间的正确实例。

恢复期间更换磁盘

您可以在恢复期间通过重命名块来更换磁盘。在使用 onbar 进行冷恢复期间，通过指定新块路径和偏移量来重命名块。如果需要将存储空间恢复到与完成备份的磁盘不同的磁盘上，该选项很有帮助。可以重命名任意类型的块，包括关键块和镜像块。

旧块必须包含在上一个 0 级备份中。

以下准则适用于新块：

新块不需要存在。可以以后安装新块并对包含它的存储空间执行热恢复。如果指定不存在的块，onbar 将重命名信息记录在块保留页中，但不恢复数据。已重命名（但未恢复）的块处于脱机状态，在 onstat -d 命令的输出中由 N 标志指示。
新块必须有正确的许可权。
新块必须包含在上一个 0 级备份中。
新块路径名不能与现有块相同，且偏移量不能重叠。

提示

如果使用块名称的符号链接，可能不需要重命名块；而只需编辑符号名称定义即可。

要在恢复期间重命名块：

关闭数据库服务器。
使用 -rename 选项和块信息选项来运行 onbar -r 命令。

如果要对主根块或镜像根块进行重命名，那么 onbar 将更新 ROOTPATH 和 ROOTOFFSET 或者 MIRRORPATH 和 MIRROROFFSET 配置参数的值。旧版本的 onconfig 文件将另存为 $ONCONFIG.localtime。
执行 0 级归档，以便您可以恢复重命名的块。

示例

下表列出在本部分的示例中使用的两个块的示例值。

元素	第一个块的值	第二个块的值
旧路径	/chunk1	/chunk2
旧偏移量	0	10000
新路径	/chunk1N	/chunk2N
新偏移量	20000	0

示例 1：通过在命令中提供块信息来重命名块

以下命令将块 chunk1 重命名为 chunk1N，将块 chunk2 重命名为 chunk2N：

onbar -r -rename -p /chunk1 -o 0 -n /chunk1N -o 20000
         -rename -p /chunk2 -o 10000 -n /chunk2N -o 0

示例 2：通过在文件中提供块信息来重命名块

假设您有一个名为 listfile 的文件，其中包含以下内容：

/chunk1 0 /chunk1N 20000
/chunk2 10000 /chunk2N 0

以下命令将块 chunk1 重命名为 chunk1N，将块 chunk2 重命名为 chunk2N：

onbar -r -rename -f listfile

将块重命名到不存在的设备上

要将块重命名到不存在的设备，请指定新的路径名，但在安装该物理设备之后再恢复存储空间。该选项在您需要重命名块时很有用，便于您在安装新设备前执行冷恢复。当新块设备就绪后，您可以在它上面执行存储空间的热恢复。

可以在同一个重命名操作中将重命名块与现有设备结合在一起，以及将重命名块与不存在的设备结合在一起。本示例显示如何将单个块重命名到不存在的设备名上。

下表列出本示例中使用的块的示例值。

存储空间	旧块的路径	旧偏移量	新块的路径	新偏移量
sbspace1	/chunk3	0	/chunk3N	0

要将块重命名到不存在的设备上：

使用以下命令重命名块：onbar -r -rename -p /chunk3 -o 0 -n /chunk3N -o 0

当您看到以下提示时，请输入 y 以继续：

块 /chunk3N 不存在。如果继续，那么对包含该块

的数据库空间的恢复操作稍后可能会失败。

在不创建该块的情况下，是否继续？(y/n)

块 /chunk3 被重命名为 /chunk3N，但数据还未恢复到 /chunk3N。

执行 0 级归档。
为 /chunk3N 添加物理设备。
使用 onbar -r sbspace1 命令来执行 sbspace1 的热恢复。
执行 0 级归档。

恢复到其他计算机

您可以备份一台计算机上的数据并在另一台计算机上恢复该数据。对于灾难恢复或升级数据库服务器，导入恢复很有用。备份数据并移至存储管理器对象上之后，可以执行导入的恢复。导入的恢复涉及将源计算机中的文件复制到目标计算机，以及以多种方式之一执行恢复。

先决条件：

您的存储管理器必须支持导入的恢复。
整个系统的备份必须包含所有存储空间；逻辑日志是可选的。

0 级备份必须包含所有存储空间和逻辑日志。

源计算机和目标计算机都必须在相同的 LAN 或 WAN 上，并且必须具有以下属性：
- 相同的硬件和操作系统
- 相同的数据库服务器版本
- 相同的配置和 ROOTPATH 信息，但服务器名称和数量可以不同。
- 相同的存储管理器版本
- 兼容的 XBSA 库

重要

要完成导入恢复，源计算机和目标计算机上的每个块（包括镜像）的大小、位置和偏移量都必须精确匹配。

要执行导入的恢复：

在目标计算机上安装数据库服务器和存储管理器。
在目标数据库服务器实例上安装存储管理器。

a. 设置必要的环境变量。

b. 定义与源实例上类型相同的存储设备。

c. 用正确的池名标记存储介质。

d. 安装存储设备。

e. 用存储管理器的版本更新目标计算机上的 sm_versions 文件。
对于与源计算机上的设备和链接匹配的块，确保目标计算机已将这些设备和链接准备就绪
对源数据库服务器上的所有存储空间执行 0 级备份（onbar -b 或 onbar -b -w）。

限制：不要执行增量备份。
如果在使用 Storage Manager，请遵循以下步骤：

a. 关闭两台计算机上的存储管理器。

b. 在源计算机上创建存储管理器目录的 tar 文件。

c. 将这个 tar 文件复制到目标计算机上并解包。

如果使用其他存储管理器，您可以使用备份磁带或通过网络导入存储管理器目录。要了解更多信息，请参阅您的存储管理器文档。
安装传送的存储卷。
- 如果备份文件在磁盘上，请将它们从源计算机复制到目标计算机上。
- 如果备份位于磁带上，请在连接到目标计算机的存储设备上安装传输的卷。源计算机和目标计算机都必须使用相同类型的存储设备，如 8 毫米磁带或磁盘。
- 如果备份位于备份服务器上，请从该备份服务器检索该备份。
使用存储管理器命令将源主机名作为客户机添加到目标计算机上。
将以下文件从源计算机复制到目标计算机上。

表 1. 要复制的管理文件

文件	操作
紧急引导文件	用目标数据库服务器编号重命名紧急引导文件。例如：将 ixbar.51 重命名为 ixbar.52。紧急引导文件只需要来自源计算机上 0 级备份的条目。文件名为 ixbar.servernum。
oncfg 文件：oncfg_servername.servernum	onbar 需要让 oncfg 文件知道要检索哪些数据库空间。用目标数据库服务器的名称和编号重命名 oncfg 文件。例如：将 oncfg_bostonserver.51 重命名为 oncfg_chicagoserver.52。该文件名必须与目标计算机上的 sqlhosts 文件中的 dbservername 条目和 SERVERNUM 相匹配。
onconfig 文件	在 onconfig 文件中，使用目标数据库服务器编号更新 SERVERNUM 参数。
存储管理器配置文件，如果有该文件	存储管理器配置文件可能需要更新。

使用以下方法之一恢复数据：

表 2. 恢复数据选项

选项	操作
如果未在目标服务器上启动 GBase 8s 实例	使用 onbar -r 命令来恢复数据。
如果要导入整个系统备份	使用 onbar -r -w -p 命令来恢复数据。
如果已在目标服务器上启动了 GBase 8s 实例。	分阶段恢复数据： _ 使用 onbar -r -p 命令来恢复物理数据。 _ 使用 onbar -r -l 命令来恢复逻辑日志。此过程可避免回收日志和对实例的任何潜在破坏。

在您使用 onsmsync 实用程序使目标计算机和存储管理器上的对象到期之前，请执行以下某个任务。

否则，onsmsync 将使错误对象到期。
- 手动编辑目标计算机上的 $GBASEDBTDIR/etc 目录中的紧急引导文件 viz ixbar.servernum。将源计算机上使用的 GBase 8s 服务器名称替换为目标计算机的 GBase 8s 服务器名称。
- 在目标计算机上以 gbasedbt 用户身份运行 onsmsync -b 命令，以只从 sysutils 数据库重新生成紧急引导文件。重新生成的紧急引导文件反映了目标计算机的服务器名称。

使用 onbar 和 Storage Manager 执行导入的恢复的示例

此示例显示如何使用 onbar、Storage Manager 和归档的文件设备来设置实例的导入恢复。

有多种方式可执行导入的恢复。此示例显示的是 Storage Manager 目录复制方法。

此示例的先决条件：

带有相同配置的源机器和目标机器。但是，服务器名称和编号可以不同。
在两台机器上相同的 ROOTPATH。
目标机器已为块准备好设备和链接，并且这些设备和链接与源机器上的设备和链接相匹配。
Storage Manager 已在两台计算机上初始化。
设备目录路径、卷名称和池名称在两台机器上都相同。
root 用户和 gbasedbt 用户是两台机器上的 Storage Manager 管理员。

在此示例中，数据库空间和日志备份的目录如下：

<目录路径>/dbspaces1

<目录路径>/logfiles1

源环境中设置的其他环境参数如下：

ISM_server = source computer

export IDS_server

目标机器上设置的其他环境参数如下：

ISM_client = source computer

export IDS_client

SM_server = target computer

export ISM_server

以 gbasedbt 用户身份，在源机器上执行 0 级备份。
以 root 用户身份，通过运行以下命令来停止两台计算机上的 Storage Manager：%ism_shutdown
以 root 用户身份，压缩源机器上的相应 Storage Manager 目录，如下所示：
```
%cd /nsr
%tar -cvf nsr.tar index mm
```
将上一步中的 nsr.tar 文件以二进制方式通过 FTP 传输至目标机器。
以 root 用户身份，解压缩目标机器上的 nsr.tar 文件，如下所示：
```
%cd /nsr
%tar -xvf nsr.tar
```
以 root 用户身份，在源机器上以 tar 格式压缩备份目录（设备），如下所示：
```
%tar -cvf logfiles1.tar logfiles1
%tar -cvf dbspaces1.tar dbspaces1
```
将上一步中的归档目录以二进制方式通过 FTP 传输至目标机器。
以 root 用户身份，在目标机器上将现有日志和归档目录覆盖为源机器中的目录，如下所示：
```
%tar -xvf logfiles1.tar
%tar -xvf dbspaces1.tar
```
以 root 用户身份，在目标机器上

通过运行以下命令来启动 Storage Manager：ism_startup 运行 ism_show -devices 命令以将设备显示为已安装。

在目标机器上，使用以下内容创建一个文件（例如，nsr.txt）：

create type: NSR client; name: source_machine;
remote access: root@target_machine, gbasedbt@target_machine;

以 gbasedbt 用户身份，在目标机器上运行以下命令：
```
%nsradmin -s target_machine -i nsr.txt
```
该命令返回以下输出：created resource id
以 gbasedbt 用户身份，将源机器上 $GBASEDBTDIR/etc 目录中的以下文件通过 FTP 传输至目标机器上的 $GBASEDBTDIR/etc 目录

ixbar,servernum

oncfg_servername,servernum
在目标机器上，将上一步中的文件的文件名更改为本地服务器的对应名称。
运行恢复命令。

onbar -RESTART 语法：重新启动失败的恢复

如果在恢复期间数据库服务器、介质、存储管理器或 onbar 发生故障，可以从发生故障之处重新启动该恢复。要重新启动失败的恢复，当恢复失败时，onconfig 文件中的 RESTARTABLE_RESTORE 配置参数必须设置为 ON。

重新启动恢复

表 1. onbar -RESTART 命令.

选项	描述
-RESTART	在数据库服务器、存储管理器或 onbar 发生故障后重新启动恢复。当恢复失败时，RESTARTABLE*RESTORE 配置参数必须设置为 ON。可以重新开始以下类型的恢复： ● 整个系统 ● 时间点 ● 存储空间 ● 冷恢复的逻辑部分如果在热逻辑恢复期间发生故障，请勿使用 -RESTART 选项。

用途

当您启用可重新启动的恢复时，如果恢复的逻辑日志很多，逻辑恢复将会变慢。但是，如果恢复失败后重新启动恢复，可以节省时间。恢复是否可重新启动不会影响物理恢复的速度。

物理恢复在发生故障的存储空间和级别处重新启动。当恢复了存储空间的某些块而不是所有块时，如果恢复失败，那么将恢复该存储空间的所有块。失败前如果存储空间和增量备份已成功恢复，那么不会再次恢复它们。

如果 BAR_RETRY 配置参数设置为 2，那么 onbar 会自动再次尝试恢复任何失败的存储空间和逻辑日志。如果恢复成功，那么不需要重新启动恢复。

如果 BAR_RETRY 配置参数设置为 0 或 1，那么 onbar 不会再次尝试恢复任何失败的存储空间和逻辑日志。如果数据库服务器还在运行，onbar跳过失败的存储空间并尝试恢复剩余的存储空间。要完成恢复，请运行 onbar -RESTART 命令。

下图显示如果物理恢复 dbspace2 期间恢复失败，可重新启动的恢复是如何工作的。rootdbs 的 0 级、1 级和 2 级备份，dbspace1 和dbspace2 的 0 级备份和 1 级备份都已成功恢复。恢复 dbspace2 的 1 级备份时数据库服务器出现故障。重新启动恢复时，onbar 将恢复dbspace 1 的 2 级备份，dbspace2 的 1 级和 2 级备份以及逻辑日志。

图: 可重新启动的物理恢复

如果恢复在逻辑阶段期间失败，然后您重新启动该恢复，那么 onbar 会验证存储空间是否已恢复，跳过物理恢复并重新启动逻辑恢复。下图显示在恢复逻辑日志 LL-3 时冷恢复失败的情况。当重新启动冷逻辑恢复时，从最近的恢复检查点开始重放日志。在本示例中，最近的检查点在逻辑日志 LL-2 中。

如果在冷逻辑恢复期间发生故障，onbar 将在发生故障之处重新启动该恢复。

重要

如果在热逻辑恢复期间发生故障，请从头重新启动该恢复。如果数据库服务器仍在运行，请运行 onbar -r -l 命令来完成恢复。

图: 可重新启动的冷逻辑恢复

解决失败的恢复

解决失败的恢复的方式取决于失败的原因。

即使可重新开始的恢复被关闭，您仍然可以挽救某些失败的恢复。例如：如果恢复由于存储管理器或存储设备错误而失败，您可以修复磁带机或存储管理器的问题，重新安装磁带，然后继续进行恢复。

下表显示当物理恢复失败并且 BAR_RETRY 配置参数的值 > 1 时预期的结果。

表 1. 失败的物理恢复方案

错误类型	RESTARTABLE_ RESTORE 设置	物理恢复失败时采取什么措施？
数据库服务器、onbar 或存储管理器错误（数据库服务器仍在运行）	ON 或 OFF	onbar 重试每个失败的恢复。如果存储管理器失败，请修复存储管理器的错误。如果尝试的恢复失败，请发出 onbar -r spaces 命令，其中 spaces 是还没有恢复的存储空间列表。使用 onstat -d 获取需要恢复的存储空间列表。onbar 恢复每个存储空间的 0 级备份，接着是 1 级和 2 级备份（如果备份存在）。
onbar 或存储管理器错误（数据库服务器仍在运行）	启用	发出 onbar -RESTART 命令。如果存储管理器失败，请修复存储管理器的错误。恢复将从第一个恢复失败的存储空间和备份级别处重新启动。如果成功恢复存储空间的 0 级备份，重新启动的恢复将跳过 0 级备份并恢复 1 级和 2 级备份（如果备份存在）。
数据库服务器故障	ON 或 OFF	由于数据库服务器已关闭，所以执行冷恢复。使用 onbar -r 恢复关键数据库空间以及第一次未恢复的所有非关键空间。
数据库服务器故障	启用	发出 onbar -RESTART 命令。恢复将从第一个恢复失败的存储空间和备份级别处重新启动。如果成功恢复存储空间的 0 级备份，重新启动的恢复将跳过 0 级备份并恢复 1 级和 2 级备份（如果备份存在）。

下表显示当逻辑恢复失败时将出现的结果。

表 2. 失败的逻辑恢复方案

错误类型	RESTARTABLE_ RESTORE 设置	逻辑恢复失败时采取什么措施？
冷恢复中数据库服务器或 onbar发生错误（数据库服务器仍在运行）	启用	发出 onbar -RESTART 命令。逻辑恢复在最近的检查点处重新启动。如果该恢复失败，关闭并重新启动数据库服务器来启动逻辑日志的快速恢复。所有未恢复的逻辑日志将会丢失。
数据库服务器或 onbar 错误（数据库服务器仍在运行）	ON 或 OFF	发出 onbar -r -l 命令。恢复将在失败的逻辑日志处重新启动。如果 onbar -r -l 仍然失败，关闭并重新启动数据库服务器。数据库服务器将完成快速恢复。所有未恢复的逻辑日志将会丢失。如果快速恢复不起作用，您必须执行冷恢复。
数据库服务器错误	启用	如果冷逻辑恢复失败，那么发出 onbar -RESTART。如果热逻辑恢复失败，那么发出 onbar -r -l 命令。如果该命令失败，从头开始重新启动整个恢复。
存储管理器错误	ON 或 OFF	onbar 重试每个失败的逻辑恢复。如果重试的恢复失败，那么逻辑恢复将暂挂。请修复存储管理器的错误。然后发出 onbar -r -l 命令。恢复将在失败的逻辑日志处重新启动。

外部备份与恢复

这些主题讨论使用外部备份与恢复来恢复数据的方法。

外部备份与恢复概述

外部备份与恢复会消除系统的停机时间，因为备份与恢复操作都是在 GBase 8s 系统外部执行的。

在备份或物理恢复期间 onbar 不移动数据。外部备份使您不必使用 onbar 就可以复制包含存储空间块的磁盘。当磁盘发生故障时，将其更换并使用供应商软件来恢复数据，然后使用 onbar 进行逻辑恢复。有关更多信息，请参阅在外部恢复中恢复数据。

以下是外部备份与恢复的典型情况：

磁盘镜像的可用性

如果使用硬件磁盘镜像，与使用常规的 onbar 命令相比，使用外部备份与恢复可以使系统更快地联机。
克隆

可以使用外部备份与恢复来克隆现有的生产系统，以在不干扰生产系统的情况下对其进行测试或迁移。

下图显示如何使用镜像来执行备份。

图: 使用镜像执行备份

在此配置中，除了数据库服务器被阻塞而中断镜像的短时间之外，数据库服务器持续运行。镜像磁盘包含数据库服务器存储空间的副本。要创建备份，请阻塞数据库服务器以停止事务并禁用镜像。已镜像的磁盘现在包含位于特定时间点的一致数据的副本。在禁用镜像之后，请对数据库服务器取消阻塞以允许事务重新开始，然后备份逻辑日志。使用外部命令将数据从脱机的镜像磁盘复制到备份介质中。现在您可以重新开始制作镜像了。

备份前阻塞

开始外部备份之前，需要阻塞数据库服务器。阻塞将强制设置检查点，清空缓冲区、将其中的内容都保存到磁盘，并阻塞包含临时表的用户事务。

在阻塞操作期间，用户可采用只读方式访问数据库服务器。接着您可以使用操作系统或第三方的工具以物理方式将数据备份或复制到另一组磁盘或存储介质上。完成外部备份后，取消阻塞数据库服务器以使事务能继续进行。在外部备份中应包含每个存储空间中的所有块文件、管理文件（例如onconfig）以及紧急引导文件。

重要

要使跟踪备份更加容易，您应该在每个外部备份中备份所有存储空间。

onbar 将外部备份当做 0 级备份同等对待。不能执行外部备份后接着使用 onbar 执行 1 级备份，反之亦然，因为 onbar 没有外部备份的任何记录。有关更多信息，请参阅在未对块进行镜像时执行外部备份。

外部备份的规则

开始外部备份之前，请查看执行外部备份的规则。

必须遵循的规则为：

外部备份期间数据库服务器必须处于联机状态或停顿方式。
用 onbar 备份包括当前日志在内的所有逻辑日志，这样您就可以在外部恢复结束时恢复逻辑日志。
阻塞数据库服务器以进行外部备份之前请暂挂连续逻辑日志备份。外部备份完成后，恢复连续逻辑日志备份。

要停止连续逻辑日志备份，请使用 CTRL-C 命令。要恢复连续逻辑日志备份，请使用 onbar -b -l -C 命令。
等到所有 onbar 备份会话完成后再阻塞数据库服务器。如果有任何备份会话是活动的，阻塞命令将显示错误消息。
当数据库服务器阻塞时，所有 OLTP 工作或查询都将暂挂。直到数据库服务器取消阻塞后它们才会继续进行。
数据库服务器实例中所有关键的数据库空间必须使用同一个 onmode -c block … onmode -c unblock 命令编组一同进行备份。在不同时间对不同的关键数据库空间所做的备份无法恢复到一致的系统中。
在 AIX® 操作系统上，如果由于 DIRECT_IO 配置参数设置为启动并发 I/O，而由此服务器运行时使用的是并发 I/O，那么联机的外部备份程序也必须使用并发 I/O。

重要

由于外部备份不受 onbar 的控制，因此必须手动跟踪这些备份。有关更多信息，请参阅跟踪外部备份。

准备进行外部备份

这些主题描述了用于准备外部备份的命令。有关过程的信息，请参阅在未对块进行镜像时执行外部备份。

阻塞和取消阻塞数据库服务器

本主题显示了 GBase 8s 上阻塞和取消阻塞命令的语法。

元素	用途	关键注意事项
onmode -c	执行检查点并阻塞或取消阻塞数据库服务器	无。
block	阻止数据库服务器执行任何事务	设置数据库服务器以进行外部备份。当数据库服务器被阻塞时，用户可采用只读方式进行访问。样本命令：onmode -c block
unblock	取消阻塞数据库服务器，从而允许数据事务和正常的数据库服务器操作可以继续进行	在外部备份完成前请勿取消阻塞。样本命令：onmode -c unblock

跟踪外部备份

数据库服务器和 onbar 不会跟踪外部备份。要跟踪外部备份数据，请使用第三方存储管理器或手动跟踪数据。

下表显示了建议您在外部备份中跟踪的项。onbar 保留有限的外部恢复历史记录。

表 1. 使用外部备份与恢复时要跟踪的项

要跟踪的项	示例
每个已备份存储空间的各个块文件的完整路径名	/work/dbspaces/rootdbs (UNIX™)
对象类型	关键数据库空间、非关键存储空间
ins_copyid_hi 和 ins_copyid_lo	存储管理器分配给每个备份对象的副本标识
备份日期和时间	阻塞和取消阻塞数据库服务器的时间
备份介质	磁带卷编号或磁盘路径名
数据库服务器版本	从中进行备份的数据库服务器版本。

在未对块进行镜像时执行外部备份

外部备份期间数据库服务器必须处于联机状态或停顿方式。

要在未对块进行镜像时执行外部备份：

要获取外部备份，请使用 onmode -c block 命令来阻塞数据库服务器。

系统将获取一个检查点并暂挂所有更新事务。用户能以只读方式访问数据库服务器。
要备份存储空间和管理文件，请使用复制命令（如 UNIX™ 上的 cp、dd 或 tar）或文件备份程序。

必须备份存储空间中的所有块。
要允许正常操作继续，请使用 onmode -c unblock 命令来取消阻塞数据库服务器。
备份包括当前日志在内的所有逻辑日志，这样就可以将检查点信息用于外部恢复。

重要
由于外部备份并不是通过 onbar 完成的，因此必须确保具有从执行 onmode -c block 命令时开始的当前逻辑日志的备份。没有该逻辑日志文件的备份，外部备份将是不可恢复的。
执行外部备份后，使用 onbar -b -l -c 命令来备份当前日志。

如果丢失了磁盘或整个系统，现在便可以执行外部恢复。

RHAC 辅助服务器外部备份

您可以为 RHAC 辅助服务器执行外部备份。执行 RHAC 辅助服务器的备份会阻塞该 RHAC 辅助服务器，但不会阻塞主服务器。

您可以从主实例备份的日志中执行逻辑恢复。从辅助服务器获取的备份无法使用 1 级或 2 级备份进行恢复。

重要

如果数据库实例包含以下任一项，那么表明外部备份未完成：

非日志记录的智能大对象
常规 Blob 空间
非日志记录数据库
原始表

如果在包含上述任一项的实例中执行了外部备份，那么该备份将无法完成且无法用于恢复主服务器。

如果由于主服务器检查点超时而导致备份失败，那么可以使用 BAR_CKPTSEC_TIMEOUT 配置参数来增加执行外部备份时 RHAC 辅助服务器应等待检查点从主服务器到达的时间量（以秒计）。

为 RHAC 辅助服务器执行外部备份

要为 RHAC 辅助服务器执行外部备份，不能启用 STOP_APPLY 配置参数。如果启用 STOP_APPLY，那么会返回错误。在 RHAC 辅助服务器上执行备份时，服务器会切换为 STOP_APPLY 方式。处理归档检查点之后，RHAC 辅助服务器会停止应用逻辑日志，但继续从主服务器接收日志。

要对 DELAY_APPLY 配置参数值大于 0 的 RHAC 辅助服务器执行外部备份，可能需要暂时减小此参数的值。执行备份需要 RHAC 处理逻辑日志中的检查点，如果在以下过程第二步中 onmode -c block timeout 命令指定的时间长度内看不到任何检查点，那么不允许进行备份。可以通过 onmode -wf DELAY_APPLY=setting 命令来减小 DELAY_APPLY 配置参数。

外部备份期间主数据库服务器必须处于联机状态或静默方式。

要执行外部备份：

确保 RHAC 辅助服务器上的 LOG_STAGING_DIR 配置参数设置为有效的登台目录。
要获取外部备份，请使用 onmode -c block timeout 命令来阻塞数据库服务器。

timeout 参数指示 RHAC 辅助服务器等待接收检查点的秒数。仅当在 RHAC 辅助服务器上运行 onmode -c block 命令时，timeout 参数有效。在继续外部备份之前，您必须等待 onmode -c block 命令成功返回。
要备份存储空间和管理文件，请使用复制命令（如 UNIX™ 上的 cp、dd 或 tar）或文件备份程序。
必须备份存储空间中的所有块。
要恢复正常操作，请使用 onmode -c unblock 命令来取消阻塞数据库服务器。
执行外部备份之后，使用 onbar 或 ontape 实用程序来备份当前日志和任何新日志。

重要

只能在主服务器上进行逻辑日志备份。

如果设置了 DELAY_APPLY 配置参数，那么恢复进程所需的日志并不一定是当前在主服务器上处于活动状态的那些日志，因为某些日志可能已归档。

备份完成后，如果之前减小了 RHAC 辅助服务器上的 DELAY_APPLY 设置，现在可以通过 onmode -wf DELAY_APPLY=setting 命令将其设置为原始值。执行外部备份之后，如果磁盘或整个系统发生故障，可以执行外部恢复。

在外部恢复中恢复数据

仅当您在外部备份数据后，才能够在丢失磁盘或整个系统的情况下从外部进行恢复。必须对外部备份与恢复使用相同的第三方实用程序。要从外部恢复存储空间，请将已备份的数据复制到磁盘。使用 onbar -r -e 命令将存储空间标记为已物理恢复，接着重放逻辑日志并让存储空间回到联机状态。如果未指定外部恢复命令，数据库服务器认为这些存储空间仍然是关闭的。

可以执行以下这些类型的外部恢复：

外部热恢复

将非关键存储空间标记为已物理恢复，然后对这些存储空间执行逻辑恢复。
外部冷恢复

将存储空间标记为已物理恢复，然后对所有存储空间执行逻辑恢复。还可以选择执行时间点外部冷恢复。

限制

当执行外部冷恢复时，onbar 并不首先从数据库服务器尝试回收逻辑日志文件，因为外部备份已经复制了所有逻辑日志数据。

要回收逻辑日志，请在复制外部备份之前执行 onbar -l -s，接着执行外部恢复 (onbar -r -e)。

重命名块

您可以使用其他恢复方法的重命名选项语法，对外部冷恢复中的块进行重命名。恢复过程中使用以下命令指定新的块名称：

onbar -r -e -rename -f filename

或

onbar -r -e rename -p old_path -o old_offset-n new_path-o new_offset

外部恢复命令

使用 onbar -r -e 命令来执行热或外部冷恢复。该命令将存储空间标记为已物理恢复并恢复逻辑日志。下图显示外部恢复语法。

使用 onbar 来执行外部恢复

元素	用途	关键注意事项
onbar -r	指定一个恢复	在冷恢复中，如果未指定存储空间名称，那么所有存储空间都将标记为已恢复。
-e	指定外部恢复	必须与 -r 选项一起使用。在外部热恢复中，除非指定 -O 选项，否则将关闭的存储空间标记为已恢复。
dbspace_list	在热恢复中指定要标记为已恢复的一个或多个存储空间	如果未输入 dbspace_list 或 -ffilename，并且数据库服务器处于联机状态或停顿方式，那么 onbar 仅将关闭的存储空间标记为已恢复。如果输入多个存储空间名称，那么使用空格来分隔这些名称。
-ffilename	恢复文本文件中列出的存储空间，该文件的路径名由filename 提供	要避免每次输入一长串存储空间，请使用该选项。filename 可以是任何有效的 UNIX™ 文件名。
-n last_log	指示要恢复的最后一个日志的编号	如果该日志后还存在任何逻辑日志，onbar 将不恢复它们并且它们的数据也将丢失。-n 选项不能与 -p 选项一起使用。
-O	恢复联机存储空间	无。
-p	仅指定外部物理恢复。	物理恢复完成后，您必须执行逻辑恢复。
-t time	恢复指定的时间点之前的最近一次备份。如果选择该时间点后所做的备份，那么恢复将失败。	只能在冷恢复中使用时间点恢复。必须恢复所有的存储空间。如何输入时间取决于当前的 GLS 语言环境约定。如果未设置 GLS 语言环境，请使用英语样式的日期格式。
-w	自上次整个系统备份以来对所有的存储空间和逻辑日志执行整个系统的恢复	必须在冷恢复中指定 -w 选项。如果不是对整个系统的备份指定 onbar -r -w，将出现返回码 147，因为onbar 找不到任何作为整个系统备份的一部分而备份的存储空间。

外部恢复的规则

外部恢复具有特定规则。

以下规则适用于外部恢复：

必须从外部备份进行外部恢复。尽管外部备份被视为 0 级备份，但它实际上可能是与 GBase 8s 无关的增量备份。
外部热恢复仅恢复非关键存储空间。
不能从外部恢复临时数据库空间。
不能从常规 onbar 备份进行外部恢复。
如果使用 onbar，您无法验证是否在从正确的备份进行恢复以及存储介质是否可读。
如果多个外部备份在不同的时间进行，那么外部恢复将使用最早的备份中的开始逻辑日志。
您不能执行混合恢复。如果必须恢复关键数据库空间，那么必须执行完整的冷恢复。

以下规则适用于外部冷恢复：

在切换包含关键存储空间的磁盘之前回收逻辑日志 (onbar -b -l -s)。
如果正在恢复关键数据库空间，那么数据库服务器必须处于脱机状态。
时间点外部恢复必须是冷恢复并且恢复所有存储空间。
数据库服务器实例的所有关键数据库空间的外部备份必须同时进行。必须在同一组 onmode -c block … onmode -c unblock 命令中备份所有关键数据库空间。

执行外部恢复

本部分描述了执行冷和外部热恢复过程。

执行外部冷恢复

如果在冷恢复中指定 onbar -r -e 命令，那么必须恢复所有的存储空间。使用 onbar -r -e -p 命令来恢复所有的或特定的存储空间。

要执行外部冷恢复：

使用 onmode -ky 命令来关闭数据库服务器。
使用 onbar -b -l -s 命令来回收逻辑日志。
要从外部备份恢复存储空间，请使用复制命令，例如 UNIX™ 上的 cp、dd 或 tar，或使用文件备份程序。

必须将存储空间恢复到与原始数据相同的路径中，并包含所有的块文件。
要执行所有存储空间和逻辑日志的外部恢复，请使用 onbar -r -e 命令。
要执行所有存储空间的时间点外部恢复，请使用 onbar -r -e -t datetime 命令。

这一步让数据库服务器转入快速恢复方式。

onbar 和数据库服务器将前滚逻辑日志并使存储空间处于联机状态。

执行外部热恢复

在外部热恢复期间数据库服务器处于联机状态。外部热恢复仅涉及非关键存储空间。

要执行外部热恢复：

要从外部备份恢复存储空间，请使用复制命令，例如 UNIX™ 上的 cp、dd 或 tar，或使用文件备份程序。

必须将存储空间恢复到与原始数据相同的路径中，并包含每个已恢复存储空间的所有块文件。
对非关键存储空间执行外部热恢复以使它们处于联机状态。
- 要恢复选定的存储空间和所有逻辑日志，请使用 onbar -r -e dbspace_list 命令。
- 要分步恢复关闭的非关键存储空间（名为 dbsp1）和逻辑日志，请使用以下命令：
```
onbar -r -e -p dbsp1
onbar -r -l dbsp1
```
- 要恢复所有非关键存储空间和逻辑日志，请使用 onbar -r -e -O 命令。

外部恢复命令的示例

下表包含外部恢复命令的示例。

外部恢复命令	操作	注释
onbar -r -e	完整的外部恢复	在冷恢复中恢复所有内容。在热恢复中，恢复所有关闭的非关键存储空间。
onbar -r -e -p onbar -r -l	物理外部恢复和单独的逻辑恢复	如果各个外部备份来自不同的时间，那么必须执行逻辑恢复。系统从最早的外部备份恢复逻辑日志。
onbar -r -e dbspace_list	选定的存储空间和逻辑日志的外部恢复	仅在外部热恢复中使用该命令。
onbar -r -e -p dbspace_list onbar -r -l	选定存储空间外部恢复和单独的逻辑恢复	仅在外部热恢复中使用该命令。
onbar -r -e -t datetime	外部时间点（冷）恢复	确保选择指定时间之前的备份集。
onbar -r -e rename -p old_path -o old_offset -n new_path -o new_offset	重命名块的外部（冷）恢复	仅在外部冷恢复中使用该命令对块进行重命名。
onbar -r -e -w onbar -r -e -p -w	整个系统外部恢复	使用 onbar -r -e -w -p 时，在一个阻塞和取消阻塞会话中备份所有的存储空间。那样，所有的存储空间将具有相同的检查点。

使用外部备份与恢复来初始化 HAC

您可以使用外部备份来初始化“高可用性数据复制”(HAC)。

要使用外部备份与恢复来初始化 HAC：

使用 onmode -c block 命令来阻塞源数据库服务器。
在外部备份源数据库服务器上的所有块。
备份完成时，使用 onmode -c unblock 命令来取消阻塞源数据库服务器。
使用以下命令来使源数据库服务器成为主服务器：onmode -d primary secondary_servername
在目标数据库服务器上，通过复制或文件备份程序从外部备份恢复数据。
在目标数据库服务器上，使用 onbar -r -e -p 命令恢复所有块的外部备份。

在 HAC 上，辅助服务器只能恢复 0 级归档。
使用以下命令来使目标数据库服务器成为辅助服务器：onmode -d secondary primary_servername
如果从步骤 1 以来写入到主数据库服务器中的逻辑日志记录仍然驻留在主数据库服务器磁盘上，那么辅助数据库服务器将读取这些记录以执行逻辑恢复。否则，使用 onbar -r -l 命令来执行逻辑恢复。

数据库服务器可操作消息将显示在主服务器和辅助服务器上的消息日志中。

定制和维护 onbar

这些主题讨论以下内容：

使用 onbar 脚本定制 onbar 和存储管理器命令
手动启动 onbar-worker 进程
使备份历史记录到期和同步

定制 onbar 和存储管理器命令

您可以编辑与 onbar 一起安装的脚本，以定制备份与恢复命令以及存储管理器命令。

在 UNIX™ 操作系统上，onbar shell 脚本位于 $GBASEDBTDIR/bin 目录中。

编辑脚本并备份原始文件的副本，以便在需要时还原。

重要

请小心编辑脚本并测试更改。请勿更改脚本底部的清除代码。这样做可能导致意外行为，例如，在备份验证期间遗留临时文件。

该脚本包含用于 Storage Manager 的命令，并备份 Storage Manager 目录。如果要使用不同的存储管理器，请删除特定于 Storage Manager 的行，并（可选）为所使用的存储管理器添加命令。

脚本包含以下部分：

此处添加启动处理

如果需要，使用这一部分初始化存储管理器，并且设置环境变量。
此处结束启动处理

这一部分启动 onbar_d 驱动程序并检查返回码。将这一部分用于 onbar_d 和存储管理器命令。
此处添加清除处理

这部分中的代码在备份操作完成后将 Storage Manager 目录备份到 ISMData 卷池中。如果使用第三方存储管理器，请删除特定于 Storage Manager 的信息。

如果对卷池使用不同于 ISMData 的名称，请将其更改为在 ISM_DATA_POOL 配置参数中指定的名称。

这部分会除去 archecker 临时文件。
此处结束清除处理

使用这一部分返回 onbar_d 错误代码。

在重新安装期间更新 onbar 脚本

重新安装数据库服务器后，可能需要更新与 onbar 一起安装的脚本。安装过程备份了现有定制脚本，以便您可以复用其内容。

安装程序在 UNIX™ 上安装缺省 onbar shell 脚本。如果缺省脚本与本地脚本不同，那么安装程序将备份本地脚本，并发出消息通知您本地脚本已被重命名。重命名的文件的命名约定为 onbar.date，其中 date 是重命名文件时的日期。例如，文件 onbar.2012.05.15 于 2012 年 5 月 15 日重命名。

您可以通过从重命名的脚本向缺省脚本添加信息来更新缺省脚本。

打印备份引导文件

当备份成功时，使用下面示例的方法向 onbar 脚本添加命令来打印紧急引导文件。每次发出 onbar -b 命令时，都将打印紧急引导文件。

以下示例适用于 UNIX™：

onbar_d "$@"    # receives onbar arguments from command line return_code = $?
# check return code

# if backup (onbar -b) is successful, prints emergency boot file
if [$return_code -eq 0 -a "$1" = "-b"]; then
   servernum=‘awk '/^SERVERNUM/ {print $2}' $GBASEDBTDIR/etc/$ONCONFIG '
   lpr \$GBASEDBTDIR/etc/ixbar.$servernum
    fi
exit $return_code

将备份的逻辑日志迁移到磁带

可以将存储管理器设置为将逻辑日志备份到磁盘上，接着编写脚本自动将这些逻辑日志从磁盘迁移到磁带，以便进行工作环境之外的保存。编辑onbar 脚本使其在 onbar_d 进程完成后调用该迁移脚本。以下示例显示了调用迁移脚本的脚本：

以下示例适用于 UNIX™：

onbar_d "$@" # starts the backup or restore
EXIT_CODE=$?         # any errors?

PHYS_ONLY=false      #if it's physical-only, do nothing
for OPTION in $*; do
    if [$OPTION = -p]; then
        PHYS_ONLY = true

        fi
done
if ! PHYS_ONLY; then   # if logs were backed up, call another
     migrate_logs      # program to move

使备份目录到期和同步

onbar 在 sysutils 数据库中为备份与恢复操作保留一份历史记录，并在紧急引导文件中保留备份历史记录的另一个副本。当只有部分数据丢失时，onbar 将在热恢复中使用 sysutils 数据库。由于 sysutils 数据库无法访问，因此 onbar 将在冷恢复中使用紧急引导文件。您可以使用 onsmsync 来重新生成紧急引导文件和使旧备份到期。

根据您提供的命令选项，onsmsync 实用程序可从 sysutils 数据库以及紧急引导文件中除去以下各项：

存储管理器已终止的备份
基于备份存在时间的旧备份
基于已备份次数的旧备份

在数据库服务器处于联机状态或停顿方式下使用 onsmsync，以同步 sysutils 数据库与紧急引导文件。

要同步 sysutils 数据库：

使数据库服务器处于联机状态或停顿方式。
不带任何选项运行 onsmsync 实用程序。

onsmsync 实用程序按照如下方式同步 sysutils 数据库、存储管理器和紧急引导文件：

将备份历史记录添加到 sysutils 中，紧急引导文件中有该备份历史记录，但已从 sysutils 数据库中丢失。
从 sysutils 数据库中除去恢复的记录、整个系统恢复的记录、伪备份记录、成功和失败的备份的记录。
使不再需要的旧逻辑日志到期。
从 sysutils 数据库再次生成紧急引导文件。

选择到期策略

可从以下三个到期策略中选择：

保留时间日期 (-t)

在特定日期和时间之前删除所有备份。

保留时间的时间间隔 (-i)

删除早于指定时段的所有备份。

保留时间生成 (-g)

为每个备份保留一定数目的版本。

onbar 始终为每个存储空间保留最新的 0 级备份。它让所有早于指定时间的 0 级备份到期，除非从所保留的最早 1 级备份恢复时需要这些 0 级备份。

onbar 让所有早于指定时间的 1 级备份到期，除非从所保留的最早 2 级备份恢复时需要这些 1 级备份。

onbar 将保留从指定的保留时间之前开始以及指定的保留时间之后结束的整个系统备份。

onsmsync 实用程序

使用 onsmsync 实用程序可通过存储管理器目录来同步 sysutils 数据库和紧急引导文件。

如果您的存储管理器是 GBase 8s 主存储管理器，那么还可以使用 onsmsync 实用程序的导出和导入选项来将 GBase 8s 主存储管理器备份对象导出至外部设备，并将外部设备中的对象导入到 GBase 8s 主存储管理器管理的设备。不能对其他存储管理器使用导出和导入选项。

下表列出了所有 onsmsync 命令元素，但用于导入和导出备份生成的元素除外。用于导入和导出的命令元素在表 2中列出。

表 1. onsmsync 命令的元素

元素	用途	关键注意事项
-b	将紧急引导文件 (ixbar.servernum) 和sysutils 数据库通过对方重新生成。	如果 ixbar 文件为空或不存在，那么 onsmsync -b 会重新创建 ixbar 文件并从sysutils 表填充该文件。如果 ixbar 文件不为空且包含对象数据，那么 onsmsync -b 会更新 sysutils 数据库和 ixbar 文件，以使其同步。如果 ixbar 文件具有条目，并且 sysutils 数据库已重新构建，但由于不包含数据而为空，那么 onsmsync -b 会从 ixbar 文件重新创建 sysutils 数据。请不要将 -b 元素与其他 onsmsync 选项一起使用。 -b 元素不与存储管理器同步。
dbspace	指定要使其到期的一个或多个存储空间	如果输入多个存储空间的名称，请使用空格来分隔这些名称。
-f filename	指定包含要到期存储空间列表的文件的路径名	使用该选项可避免输入一长串存储空间。文件名可以是任何有效的 UNIX™ 文件名。
-g generation	指定每个 0 级备份要保留的版本数	保留最近生成的备份并使此前的所有备份都到期。
-i interval	指定保留备份的时间间隔。	实用程序： ● 保留在此时间间隔之后创建的备份。 ● 使在此时间间隔之前创建的备份到期，并在到期的对象也被除去时除去这些备份。如果从该间隔后的其他备份恢复时需要在此间隔之前的备份，那么该间隔之前的备份不会到期。使用 ANSI 或 GLS 格式来表示 interval：YYYY-MM 或 DD HH:MM:SS
-O	覆盖内部错误检查，并强制实施到期策略	如果与 -t、 -g 或 -i 选项一起使用，即使从发生在此到期日期之后的备份进行恢复时需要所有级别的备份中的一部分，也要使所有级别的备份到期。-O 选项不影响逻辑日志到期。请参阅使所有备份到期。
-s	跳过对到期的备份的同步	如果提供了 -s 选项，那么对象到期取决于其他参数。
-t timestamp	在特定日期和时间之前让所有备份到期	保留在指定时间戳记后完成的备份。如果从该时间戳记后发生的其他备份恢复时需要在该时间戳记之前发生的备份，那么后者不会到期。使用 ANSI 或 GLS_DATETIME 格式来表示时间戳记。
-cf value	指定是否备份关键文件在与 -g、-i 或 -t 一起使用时，从GBase 8s 主存储管理器删除关键文件备份	有效值为： ● Yes。备份关键文件。该值为 0 级、1 级或 2 级备份的缺省值。 ● No。不备份关键文件。该值为备份逻辑日志文件的缺省值。 ● Only。仅备份关键文件。

表 2. onsmsync 导出和导入命令的元素

元素	用途	关键注意事项
-E	将单一备份生成导出至 GBase 8s 主存储管理器外部池	仅当设置 GBase 8s 主存储管理器外部池时使用此选项。如果导出备份生成，那么必须指定前缀，以标识导出的备份。onsmsync 实用程序会在外部池中创建一个包含该前缀的子目录，并将导出的对象放入该目录。
-g generation	指定要导出的备份生成。	缺省值是当前备份。
-I	从外部 GBase 8s 主存储管理器池导入单一备份生成。	如果从外部池导入备份生成，那么必须指定导出的备份的前缀。该前缀用于标识要导入的备份生成。
-l log_ID	导出包含逻辑日志标识的备份生成。
-p prefix	指定要分配给将导出的备份生成的前缀，或用于标识要导入的备份的前缀。	当 onsmsync 实用程序导出备份生成时，它会使用该前缀作为放置该备份的子目录的名称。
-t timestamp	指定包含特定日期和时间的备份生成（仅用于导出）。	使用 ANSI 或 GLS_DATETIME 格式。当您推出应用程序的新版本时，可能希望包含日期和时间。

用途

如果不指定任何选项，那么 onsmsync 命令会使用存储管理器目录来同步 sysutils 数据库和紧急引导文件。onsmsync 实用程序会将 sysutils 数据库和紧急引导文件中的备份与存储管理器目录中的备份进行比较，然后从 sysutils 数据库和紧急引导文件中除去存储管理器目录内不存在的所有备份。

提示

要控制 sysutils 数据库是否保留已到期的备份与恢复的历史记录，请使用 BAR_HISTORY 配置参数。有关信息，请参阅BAR_HISTORY 配置参数。

除了存储空间名或文件名必须放在最后之外，命令的顺序无关紧要。

命令的顺序无关紧要，但以下情况除外：

存储空间名称或文件名必须放在最后。
导出或导入时，-E 或 -I 选项必须放在最前。例如，指定 onsmsync -E -g 2，而不是 onsmsync -g 2 -E。

在不同计算机上导入和导出备份生成的先决条件如下：

在源计算机和目标计算机上必须具有相同版本的 GBase 8s，并且这些计算机必须使用相同的操作系统。
在源计算机和目标计算机上必须设置 GBase 8s 主存储管理器并创建一个外部池。

当您使用 -E 或 -I 选项导出或导入备份生成时，必须指定用于标识放置备份生成的子目录的前缀。

如果使用 -E 或 -I 选项导出或导入备份生成，那么不能使用与导出或导入操作无关的任何 onsmsync 命令选项。例如，不能同时导出备份生成并重新生成紧急引导文件。

onsmsync -I 命令重命名当前 ixbar 文件，并创建仅包含恢复导入的备份所必需信息的新文件

您可以将 -cf 选项与 -g、-i 或 -t 选项一起使用，以从存储管理器删除关键文件备份。

如果应用 -g 选项，并且 onsmsync 实用程序的对象列表仅包含逻辑日志而不包含任何空间备份，那么这些日志备份不会到期。在此情况下，请使用 -t 或 -i 选项来使逻辑日志备份到期。

示例

以下示例使 2012 年 11 月 30 日前开始的备份到期：

onsmsync -t "2012-11-30 00\:00\:00""

以下命令将最后一个备份生成导出到外部池中名为 gen 的目录：

onsmsync -E -p gen -g 1

以下命令将按最新程度排名第 4 位的备份生成导出到外部池中名为 gen 的目录：

onsmsync -E -p gen -g 4

以下命令将当前备份生成导出到外部池中名为 gen 的目录：

onsmsync -E -p gen

以下命令将生成 2 中的所有备份对象导出到外部池中名为 gen 的目录：

onsmsync -E -p gen -g 2

以下命令将时间戳记为 2012-12-31 12:00:00 的所有备份对象导出到外部池中名为 gen 的目录：

onsmsync -E -p gen -t “2012-12-31 12\:00\:00“

以下命令导入以前缀 gen 标识的子目录中的所有对象：

onsmsync -I -p gen

以下命令导入使用前缀 gen 和时间戳记 2012-12-31 12:00:00 导出的所有备份对象。由于前缀用于标识备份生成，因此不用指定时间戳记。

onsmsync -I -p gen

以下命令将除了最后两次生成的关键文件备份之外的所有内容删除：

onsmsync -g 2 -cf yes

使 Storage Manager 上的旧备份到期

Storage Manager 和某些第三方存储管理器不允许 onsmsync 实用程序从存储管理器删除备份。

必须手动使存储管理器中的旧备份到期或将其删除。然后，不带任何参数运行 onsmsync。

要使 Storage Manager上的旧备份到期：

要手动使 Storage Manager 中的旧备份到期，请使用 ism_config -retention #days 命令。
不带任何选项运行 onsmsync。

重新生成紧急引导文件

要只重新生成紧急引导文件，请使用 onsmsync -b 命令。

onsmsync -b 命令将旧的紧急引导文件另存为 ixbar.server_number.system_time，并将其重新生成为 ixbar.server_number。

重新生成 sysutils 数据库

如果丢失 sysutils 数据库，请使用 UNIX™ 上的 $GBASEDBTDIR/etc 中的 bldutil 实用程序，以重新创建带有空表的 sysutils 数据库。

接着使用 onsmsync 实用程序重新创建备份并在 sysutils 中恢复数据。

限制

如果 sysutils 数据库和紧急引导文件都已丢失，那么不能使用 onsmsync 重新生成它们。一定要将紧急引导文件与其他操作系统文件一起备份。

删除坏备份

onsmsync 实用程序无法分辨哪些备份未能通过验证。如果最近的备份未能通过验证，但前面的某一备份却是成功的，那么必须手动从存储管理器中删除失败的备份记录，然后不带任何选项运行 onsmsync 以同步 onbar。有关更多信息，请参阅 onbar -v 语法：验证备份。

基于保留时间日期使备份到期

以下示例使 2006 年 11 月 24 日前开始的备份以及所有伪备份、失败的备份与恢复都到期：

onsmsync -t "2006-11-24 00\:00\:00"

使生成的备份到期

以下示例保留最新的三组 0 级备份以及相关的增量备份，同时使所有之前的备份和所有恢复、伪备份和失败的备份到期：onsmsync -g 3

基于保留时间的时间间隔使备份到期

以下示例让三天以前的所有备份以及所有伪备份、失败的备份与恢复到期：

onsmsync -i "3 00:00:00"

以下示例使 18 个月前的所有备份到期（写作 1 年 + 6 个月）：

onsmsync -i "1-6"

使用多个时间点恢复使备份到期

如果您执行多个时间点恢复，那么将存在多个备份的时间线。

下图显示了三条时间线及其备份。

图: 备份的多条时间线

在此示例中，第二条时间线从对备份 1 的时间点恢复开始。第二条时间线包含备份 1、5、6、7 和 8。第三条时间线（粗体显示）包含备份 1、5 和 9。第三条时间线被视为当前时间线，因为它包含最新的备份。

在运行 onsmsync 实用程序以使旧备份到期时，onsmsync 将从当前时间线中除去旧备份，并确保当前时间线可从保留的备份对象中恢复。不在当前时间线中的所有其他备份也将过期，但是 onsmsync 将不确保其他时间线可从保留的对象中恢复。

onsmsync 实用程序以以下顺序应用到期策略，以确保根据指定的到期策略使当前时间线中的对象到期，并且确保当前时间线可恢复：

在所有备份对象的集合上应用到期策略。
不使属于当前时间线的备份对象到期。
在当前时间线上应用到期策略，以确保当前时间线可恢复。

同时，将到期策略应用于其他时间线中的备份。

例如，如果在上图的示例上执行 onsmsync -g 2 命令，那么当前时间线中的备份 1 将到期，第一和第二个时间线中的备份 2、3、4、6 和 7 也将到期。当前时间线中的备份 1、5 和 9 将保留。其他时间线中的备份 8 将保留。

使所有备份到期

除非使用 -O 选项，否则 onsmsync 实用程序将保留最新的 0 级备份。如果使用 -O 和 -t 选项，即使恢复还需要所指定时间前的所有备份，也会将那些备份全部除去。如果使用 -O 和 -i 选项，即使恢复还需要所指定时间间隔前的所有备份，也会将那些备份全部除去。

例如：要使所有备份到期，请指定以下选项：

onsmsync -O -g 0

重要

如果将 -O 选项与 -t、-i 或 -g 选项一起使用，您可能会意外删除某些关键备份，从而使恢复无法进行。

监视 onbar 和存储管理器的性能

您可以监视 onbar 和存储管理器的性能。可以指定性能监视的级别并将统计信息写入到 onbar 活动日志。BAR_PERFORMANCE 配置参数指定是否收集统计值。收集的统计值如下：

XBSA 调用所耗用的总时间。
归档 API 调用所耗用的总时间。
onbar 在与 XBSA（存储管理器调用）相互传输数据时所耗用的时间。
onbar 在 onbar 与 GBase 8s 之间传输数据时所耗用的时间。
与 XBSA API 之间的数据传送量。
与归档 API 之间的数据传送量。

设置 onbar 性能统计信息级别

要指定写入到 onbar 活动日志的性能统计信息的级别，请在 onconfig 文件中设置 BAR_PERFORMANCE 配置参数。

例如，BAR_PERFORMANCE 1 设置显示了在 GBase 8s 实例与存储管理器之间传输数据时所耗用的时间。

有关此参数选项的信息，请参阅 BAR_PERFORMANCE 配置参数。

查看 onbar 备份与恢复性能统计信息

要查看 onbar 性能结果，请打开 onbar 活动日志。

要确定活动日志的位置，请参阅 BAR_ACT_LOG 配置参数。

当 BAR_PERFORMANCE 设置为 1 或 3 时，活动报告显示传输率报告：

图: onbar 活动日志中的样本传输速率性能。

 2009-06-03 15\:38\:02 8597  8595 Begin restore logical log 310 (Storage Manager
                                copy ID: 28206 0).
 2009-06-03 15\:38\:03 8597  8595 Completed restore logical log 310.
 2009-06-03 15\:38\:08 8597  8595 Completed logical restore.
 2009-06-03 15\:38\:19 8597  8595 PERFORMANCE INFORMATION

                                                        TRASFER RATES
------------------------------------------------------------------------------------------------------------------------
|       OBJECT     |                   XBSA API                      |                  SERVER API                     |
|        NAME      | xfer-kbytes   xfer-time RATIO(kb/s)    API-TIME | xfer-kbytes   xfer-time RATIO(kb/s)    API-TIME |
------------------------------------------------------------------------------------------------------------------------
| 309              |          62       0.479         129       1.078 |          62       0.019        3310       0.310 |
| 310              |          62       0.407         152       1.098 |          62       0.025        2522       0.025 |
| rootdbs          |        5828       0.618        9436       1.864 |        5828       8.922         653       8.931 |
| datadbs01        |          62       0.488         127       1.768 |          62       0.004       17174       0.004 |
| datadbs02        |          62       0.306         203       1.568 |          62       0.008        8106       0.008 |
| datadbs03        |          62       0.304         204       1.574 |          62       0.007        8843       0.007 |
| datadbs04        |          62       0.306         202       1.563 |          62       0.007        8664       0.007 |
| datadbs05        |          62       0.315         197       1.585 |          62       0.007        8513       0.007 |
| datadbs06        |          62       0.310         200       1.583 |          62       0.002       25348       0.002 |
---------------- ----------------------------------- ... ---------------------------------------------------------------
| PID =       8597 |       14722      26.758         550     107.476 |       14756      10.678        1382      15.829 |
------------------------------------------------------------------------------------------------------------------------
 2009-06-03 15\:38\:19 8597  8595 PERFORMANCE INFORMATION

                                                       PERFORMANCE CLOCKS
------------------------------------------------------------------------------------------------------------------------
|                       ITEM DESCIRPTION                              |                  TIME SPENT                     |
------------------------------------------------------------------------------------------------------------------------
| Time to Analyze ixbar file                                         |                                           0.000 |
-------------------------------- ---------------------------------------------------------------------------------------

当 BAR_PERFORMANCE 设置为 2 或 3 时，活动报告使用微秒时间戳记（如以下示例所示）：

图: onbar 活动日志中的样本处理速率（以微秒计）。

 2009-06-03 16\:34\:04 15272  15270 /usr/gbasedbt/bin/onbar_d complete,
                                   returning 0 (0x00)
 2009-06-03 16\:45\:11.608424 17085  17083 /usr/gbasedbt/bin/onbar_d -r -w
 2009-06-03 16\:46\:07.926097 17085  17083 Successfully connected to Storage Manager.
 2009-06-03 16\:46\:08.590675 17085  17083 Begin salvage for log 311.
 2009-06-03 16\:48\:07.817487 17085  17083 Completed salvage of logical log 311.
 2009-06-03 16\:48\:08.790782 17085  17083 Begin salvage for log 312.
 2009-06-03 16\:48\:10.129534 17085  17083 Completed salvage of logical log 312.
 2009-06-03 17\:06\:00.836390 17085  17083 Successfully connected to Storage Manager.
                                    ...
 2009-06-03 17\:07\:26.357521 17085  17083 Completed cold level 0 restore datadbs07.
 2009-06-03 17\:07\:28.268562 17085  17083 Begin cold level 0 restore datadbs08
   (Storage Manager copy ID: 28122 0).
 2009-06-03 17\:07\:29.378405 17085  17083 Completed cold level 0 restore datadbs08.

onbar 目录表

这些主题描述存储在 sysutils 数据库中的 onbar 表。

onbar 使用这些表跟踪备份并执行恢复。

可以对这些表查询备份与恢复数据，以评估性能或标识某个恢复的对象实例。

bar_action 表

bar_action 表列出试图对某个对象执行的所有备份与恢复操作，除了在某些类型的冷恢复期间执行的操作之外。请使用该表中的信息跟踪备份与恢复历史记录。

表 1. bar_action 表列

列名	类型	解释
act_aid	SERIAL	操作标识。表中的唯一编号。可以与 act_oid 列一起使用以连接 bar_instance 表。
act_oid	INTEGER	对象标识。标识备份或恢复操作所针对的备份对象。可以与 act_aid 一起使用以连接bar_instance。bar_action 表的 act_oid 列等同于 bar_object 表的 obj_oid 列。
act_type	SMALLINT	标识已尝试的操作：1 表示备份，2 表示恢复，3 表示外部或导入的恢复，4 表示伪备份，5 表示整个系统的备份，6 表示整个系统的恢复，7 表示到期的或已删除的对象，8 表示外部恢复。
act_status	INTEGER	标识操作的结果：如果成功则为 0，否则是特定于 onbar 的错误代码。有关更多信息，请参阅 onbar 消息和返回码。
act_start	DATETIME YEAR TO SECONDS	操作开始的日期和时间。
act_end	DATETIME YEAR TO SECONDS	操作完成的日期和时间。

bar_instance 表

bar_instance 表包含备份的每个对象的描述。

onbar 为每个成功的备份向 bar_instance 表中写入一条记录。onbar 可能稍后使用该信息进行恢复操作。例如：如果指定 2 级备份，onbar将使用该表以确保先前已成功执行 1 级备份。

表 1. bar_instance 表列

列名	类型	解释
ins_aid	INTEGER	操作标识。标识创建该备份对象实例的成功操作。可以与 ins_oid 结合起来用于连接bar_action 表。
ins_oid	INTEGER	对象标识。标识受影响的对象。可以用于连接 bar_object 表。可以与 ins_aid 结合起来用于连接 bar_action 表。
ins_prevtime	INTEGER	时间戳记（实时时间）。此值指定先前对象的时间戳记。此值代表 1970 年 1 月 1 日午夜（格林威治标准时间）以后的秒数。
ins_time	INTEGER	时间戳记（实时时钟时间）。数据库服务器创建下级备份时将使用该值。该值代表自 1970 年 1 月 1 日午夜（格林威治标准时间）以来的秒数。 ins_time 的值是 0。
rsam_time	INTEGER	备份检查点时间戳记。不是时钟时间。数据库服务器创建下级备份时使用该值。
ins_level	SMALLINT	备份操作的级别：0 表示完整备份，1 表示自上次 0 级备份以来对该对象所做的所有更改的备份，2 表示自上次 1 级备份以来所有更改的备份。对于逻辑日志备份，该值始终是 0。
ins_copyid_hi	INTEGER	实例副本标识的高位。它是存储管理器分配的唯一值，与 ins_copyid_lo 结合在一起，用于将 onbar 对象标识与存储管理器对象标识连接在一起。
ins_copyid_lo	INTEGER	实例副本标识的低位。它是存储管理器分配的唯一值，与 ins_copyid_hi 结合在一起，用于将 onbar 对象标识与存储管理器对象标识连接在一起。
ins_req_aid	INTEGER	存储备份对象必需的操作标识。在恢复中使用，以确定与 1 级备份相伴的 0 级备份，以及与 2 级备份相伴的 1 级备份。对于 0 级备份，ins_req_aid 的值与表中 ins_aid的值相同。例如：如果备份是 1 级的，ins_req_aid 保留该对象相应的 0 级备份的操作标识。
ins_first_log	INTEGER	在标准备份中，标识从该备份恢复必需的第一个逻辑日志。
ins_verify	INTEGER	如果备份已验证则该值为 1。如果备份未验证则该值为 0。
ins_verify_date	DATETIME YEAR TO SECOND	验证备份时插入当前日期。如果该备份尚未验证，那么用短划线表示每个日期和时间。

bar_object 表

bar_object 表包含每个备份对象的描述。该表是来自每个数据库服务器的所有存储空间和逻辑日志（数据库服务器至少已对它们进行了一次备份尝试）的列表。

表 1. bar_object 表列

列名	类型	解释
obj_srv_name	VARCHAR(128,0)	数据库服务器名。用于确保将对象恢复到正确的数据库服务器上。当节点上有多个数据库服务器时，用于确保对象在所属的数据库服务器实例中恢复。数据库服务器名最多可有 128 个字符。
obj_oid	SERIAL	对象标识。表中的唯一编号。可用于连接 bar_action 和 bar_instance 表。
obj_name	VARCHAR(128,0)	对象的用户名。该名称最多可以有 128 个字符。
obj_type	CHAR(2)	备份对象类型： CD 关键数据库空间 L 逻辑日志 ND 非关键数据库空间或智能大对象空间 R 根数据库空间 B Blob 空间

bar_server 表

bar_server 表在安装中列出数据库服务器。该表用于确保备份对象在恢复期间返回到它们的正确位置。

表 1. bar_server 表列

列名	类型	解释
srv_name	VARCHAR(128,0)	sqlhosts 文件中的 dbservername 条目指定的 dbservername 值。数据库服务器名称最多可有 128 个字符。
srv_node	CHAR(256)	数据库服务器驻留的计算机的主机名。主机名最多可有 256 个字符。
srv_synctime	INTEGER	onsmsync 运行的时间。

onbar 目录映射

本主题包含 onbar 表之间的映射示例。

下图映射 GBase 8s 上的 onbar 表。在该图中，灰线显示表之间的关系。箭头显示 ins_req_aid 的值必须是有效的 ins_aid 值。

图: GBase 8s 上的 onbar 目录映射

onbar 消息和返回码

onbar 将参考、进度、警告和错误消息打印到 onbar 活动日志文件中。onbar 返回码指示命令的状态。

有关每个 onbar 参考、进度、警告和错误消息的完整描述，请搜索 finderr 或 Error Messages 实用程序，或者搜索 GBase 8s Error Messages。

消息格式

onbar 活动日志文件中的消息具有以下格式：

timestamp process_id parent_process_id message

下表描述了消息中的每个字段。onbar 活动日志中没有出现错误消息号。

表 1. onbar 消息格式

消息字段	描述
timestamp	onbar 写入消息的日期和时间。
process_id	操作系统用来标识此 onbar 实例的编号。
parent_process_id	操作系统用来标识执行此 onbar 实例的进程的编号。
message	onbar 消息文本。

以下示例举例说明了 onbar 活动日志中的一个典型条目：

1999-08-18 10\:09\:59 773 772 已完成逻辑恢复。

重要

如果收到 XBSA 错误消息，请查阅存储管理器日志获取关于更多详细信息。

消息编号

onbar 消息编号的范围从 -43000 到 -43421。

下表列出 onbar 消息组。由于活动日志中不显示消息编号，因此要查找有关 onbar 消息的信息，最佳方法是在 $GBASEDBTDIR/msg 目录下您语言环境的子目录中的错误消息文件中搜索消息文本。

onbar 消息类型	消息编号
onbar 用法	-43000 到 -43007 和 -43357
选项检查	-43010 到 -43034
权限检查	-43035 到 -43039
紧急引导文件接口	-43040 到 -43059
onconfig 文件接口	-43060 到 -43074
操作系统接口	-43075 到 -43099
数据库服务器接口	-43100 到 -43229
备份与恢复状态	-43230 到 -43239
onbar-worker 进程	-43240 到 -43254
XBSA 接口	-43255 到 -43301
onsmsync	-43302 到 -43319
archecker	-43320 到 -43334
ondblog	-43400 到 -43424

onbar 返回码

您可以通过查看适用于特定返回码的活动日志消息来对问题进行故障诊断。

下表显示所有 GBase 8s 数据库服务器的 onbar 返回码。这些返回码都与 onbar 活动日志中的消息一起出现。有关错误的详细信息，请在致电技术支持前查看活动日志。

表 1. 公共 onbar 返回码

十进制值	onbar 返回码描述
2 到 34	这些返回码由 XBSA 产生。要了解更多信息，请查阅您的存储管理器文档和日志文件。
100	onbar 在 sysutils、紧急引导文件或处理时需要的存储管理器目录中找不到某些内容。请检查 onbar 活动日志中表示未找到内容的消息并尝试解决该问题。如果问题再次发生，请联系技术支持。
104	Adstar Distributed Storage Manager (ADSM) 处于生成密码方式中。 onbar 不支持 ADSM 在生成密码的方式下运行。有关更改 ADSM 安全配置的信息，请查看您的 ADSM 手册。
115	正在冷恢复的数据库空间集中缺少一个关键数据库空间。
116	onsmsync 实用程序已在运行。
117	sysutils 数据库和紧急引导文件中包含的信息不一致。
118	尝试向存储管理器提交备份对象时出错。
120	自该对象上次备份以来传送缓冲区大小已经改变。该对象无法恢复。将传输缓冲区大小设置为原始值并重试恢复。
121	onbar 无法确定数据库空间的列表。
122	检测到死锁。 onbar 命令与另一个进程发生争用。重试 onbar 命令。
123	根数据库空间不在冷恢复中。在不恢复根数据库空间的情况下无法执行冷恢复。要解决问题，请尝试以下过程之一： ● 让数据库服务器处于停顿或联机方式，这样只需要恢复存储空间。 ● 如果数据库服务器处于脱机状态，请发出 onbar -r 命令来恢复所有的存储空间。 ● 确保根数据库空间和其他关键数据库空间在命令行或 -f filename 中列出。
124	缓冲区在备份期间有不完整的页。要获取帮助，请联系技术支持。
126	处理紧急引导文件出错。检查 onbar 活动日志以获取对问题的描述，并查看紧急引导文件以获取毁坏的情况，例如非 ASCII 字符或列数不同的行。如果问题来源不明显，请联系技术支持。
127	无法写入紧急引导文件中。通常，操作系统错误消息将与该问题一起出现。检查以下文件和目录的许可权： ● UNIX™ 上的 $GBASEDBTDIR/etc ● 紧急引导文件
128	对象描述中的数据丢失。要获取帮助，请联系技术支持。
129	onbar 接收到要进行恢复的对象不是预期的对象。（备份对象不匹配。）请求的备份对象可能已被删除或对于存储管理器已到期。运行 onsmsync 让 sysutils 数据库、紧急引导文件和存储管理器目录同步。要获取帮助，请联系技术支持。
130	数据服务器未响应。在备份或恢复期间数据库服务器可能已失败。运行 onstat - 命令检查数据库服务器状态，接着： ● 如果操作是冷恢复，重新启动该操作。 ● 如果操作是备份或热备份，请重新启动数据库服务器并重试备份或热恢复。
131	在 onbar 和数据库服务器的接口中发生故障。要获取帮助，请联系技术支持。
132	函数不在 XBSA 共享库中。请验证是否为存储管理器使用了正确的 XBSA。相关信息请查阅存储管理器手册。
133	装入 XBSA 库函数失败。请验证是否为存储管理器使用了正确的 XBSA。确保 onconfig 文件中的 BAR_BSALIB_PATH 值指向 XBSA 共享库的正确位置。相关信息请查阅存储管理器手册。
134	用户希望恢复的逻辑日志文件太早。您可能在执行单独的物理恢复后尝试了日志点恢复 (onbar -r -l -n)。指定的逻辑日志太旧而无法与物理恢复中使用的备份相匹配。请执行以下两个步骤之一： ● 从一组较旧的物理备份重新运行物理恢复。 ● 当您重新运行日志点恢复时，在 -n 选项中指定较晚的逻辑日志。要查找您可以使用的最早的逻辑日志，请查看紧急引导文件。要获取帮助，请联系技术支持。
136	onbar 无法对关键数据库空间执行热恢复。请执行以下两个步骤之一： ● 不列出任何关键数据库空间的情况下重新发出热恢复命令。 ● 关闭数据库服务器并执行冷恢复。
137	超过了 MAX_DBSPACE_COUNT。要获取帮助，请联系技术支持。
138	发生了 XBSA 错误。请验证是否为存储管理器使用了正确的 XBSA。同时还检查 bar_act.log 中的 XBSA 错误消息。相关信息请查阅存储管理器手册。
139	可能是 XBSA 版本不在 sm_versions 文件中或 sm_versions 文件中存在不正确的 XBSA 版本。将正确的 XBSA 版本插入到 sm_versions 文件中。要了解更多信息，请查阅存储管理器手册。
140	伪备份失败。使用 onbar -b -F 命令重试该伪备份。仅 GBase 8s 支持伪备份。如果伪备份再次失败，请与技术支持联系。
141	onbar 接收到操作系统信号。最可能的情况是，用户输入 Ctrl-C 命令停止了 onbar 进程。修复导致中断的问题，然后重试 onbar 命令。
142	onbar 无法打开文件。请验证指定的文件存在并且许可权也是正确的。检查 onbar 活动日志中操作系统的错误消息。
143	onbar 无法创建子进程。如果 BAR_MAX_BACKUP 不是 0，onbar 将无法创建子进程来执行并行备份或恢复。很可能操作系统的资源已用尽。可能是没有足够的内存可用于启动新进程或进程表中没有空槽。检查操作系统日志、onbar 活动日志或控制台。
144	日志备份由于一个或多个 Blob 空间关闭而停止。尝试恢复 Blob 空间。如果恢复失败，请使用 onbar -l -O 命令重试日志备份。执行此命令可能使 Blob 空间无法恢复。
145	onbar 无法获取更多的内存空间。等待系统资源释放出空间，然后重试 onbar 命令。
146	onbar 无法连接到数据库服务器。网络或数据库服务器可能已关闭。要获取帮助，请联系技术支持。
147	onbar 找不到任何要进行备份或恢复的存储空间或逻辑日志。例如：如果指定时间点恢复但使用第一次标准备份前的 datetime 值，那么 onbar 将无法构建要恢复的存储空间列表。如果指定了整个系统的恢复而没有执行整个系统的备份，也将显示该返回码。请验证数据库服务器和存储空间是否针对备份或恢复请求而处于正确的状态。请与技术支持联系。
148	发生内部 SQL 错误。将来自 onbar 活动日志的信息提供给技术支持。
149	在命令行上输入了错误的 onbar 语法，或者为 GLS 环境输入了无效或错误的 datetime 值。根据 onbar 活动日志中的用法消息检查您尝试过的命令。如果没有用，请将 datetime 值放在引号中，然后重试该命令。如果您的数据库语言环境不是英语，请使用 GL_DATE 或 GL_DATETIME 环境变量来设置日期和时间格式。
150	从 onconfig 文件收集数据时出错。检查 onconfig 文件中的许可权、格式和值。
151	对于该备份或恢复请求数据库服务器处于不正确的状态，或在确定数据库服务器状态时发生错误。可能是尝试了与数据库服务器方式不兼容的操作，或者可能是 onbar 无法确定数据库服务器状态。例如：无法在数据库服务器处于恢复方式时执行物理备份。检查 onbar 活动日志中的错误消息。如果发生了 ASF 错误，那么在 onbar 活动日志中显示以下消息：初始化 ASF 时发生致命错误；asfcode = code 要确定 ASF 错误的原因，请参阅该消息中 ASF 错误代码并重复备份或恢复命令。如果未发生 ASF 错误，请更改数据库服务器状态并重复备份或恢复命令。
152	onbar 无法备份逻辑日志。可能由于以下原因之一无法备份逻辑日志： ● 当前正在运行另一个日志备份。 ● 您所执行的逻辑日志备份中 LTAPEDEV 参数设置为了 /dev/null (UNIX) 。没有日志备份完成时您将接收到该返回码。要启用日志备份，请将 LTAPEDEV 参数更改为有效值。
153	onbar 无法设置进程组标识。如果将 BAR_MAX_BACKUP 设置为除 1 以外的任意值，并且 onbar 在设置进程组标识时发生错误，将返回该值。该消息是对可能的操作系统问题的警告。
154	onbar 用户没有正确的许可权。要执行 onbar 命令，您必须是 root 用户、gbasedbt 用户、UNIX 上 bargroup 组的成员。
156	未执行备份或恢复，因为 LTAPEDEV 参数值无效。如果未设置 LTAPEDEV 或在 UNIX 中设置为 /dev/null，那么将不备份逻辑日志，并且 onbar 会返回警告 152。
157	试图将 GBASEDBTSHMBASE 环境变量设置为 -1 出错。 onbar 无法将 GBASEDBTSHMBASE 设置为 -1。要获取帮助，请与系统管理员或技术支持联系。
158	发生内部 onbar 错误。请与技术支持联系。
159	发生意外错误。请与技术支持联系。
160	外部恢复失败。要确定外部恢复失败的原因，请查看 bar_act.log 和 online.log 文件。确保已执行外部恢复的手动部分，然后再重试onbar-r -e 命令以完成外部恢复。如果不起作用，请尝试从不同的外部备份进行外部恢复。
161	重新启动的恢复失败。请验证 RESTARTABLE_RESTORE 是否设置为 ON 并重试原始恢复。要了解更多信息，请查看 onbar 活动日志和数据库服务器消息日志。
162	onbar 日志文件不能是符号链接。除去符号链接或更改 onconfig 文件，使 onbar 参数 BAR_DEBUG_LOG 或 BAR_ACT_LOG 指向非符号链接文件。
163	onbar 日志文件的所有者必须是 gbasedbt 用户。将日志文件的所有者更改为 gbasedbt 用户或者更改 onconfig 文件中 BAR_ACT_LOG 或 BAR_DEBUG_LOG 的值以指向不同的日志文件。
164	无法打开文件。由于该文件或其目录的许可权问题，无法创建或打开该文件。验证该文件及其目录的许可权。
177	联机的数据库空间已恢复。该返回码通知用户 -O 选项在 onbar 中重设了内部检查。您不需要采取任何操作。
178	当一个或多个 Blob 空间关闭时备份了逻辑日志。该返回码通知用户 -O 选项在 onbar 中重设了内部检查。检查 Blob 空间中的数据以确定需要重新创建哪些简单大对象。这些 Blob 空间可能无法恢复。要获取帮助，请联系技术支持。
179	onbar 创建了恢复数据库空间所需要的块。该返回码通知用户 -O 选项在 onbar 中重设了内部检查。您不需要采取任何操作。
180	onbar 无法创建恢复数据库空间所需要的块。请手动创建块文件。不带 -O 选项重试该恢复。
181	onbar 使备份或恢复所需的对象到期。 onsmsync 实用程序使恢复可能需要的对象到期。您可能使用 -O 指定了 onsmsync。如果错误地使用了 -O 选项，请与技术支持联系以便从存储管理器恢复对象。
183	onbar 无法从存储管理器获得逻辑日志的唯一标识。缺少指定逻辑日志的备份。查询存储管理器以确定指定的逻辑文件的备份是否存在，是否可恢复。
247	在 UNIX 上，请查看 /tmp/bar_act.log 以及由 BAR_ACT_LOG 参数指向的文件，以获得线索。（onbar-merger 向/tmp/bar_act.log 中写入直到它有足够的信息来读取 onconfig 文件。）解决 bar_act.log 描述的问题并重试冷恢复。如果冷恢复仍然失败，请联系技术支持。
252	要获取帮助，请联系技术支持。