分类： DB2/Informix
2008-05-31 17:19:54
用 IDS 执行恢复
在发生以下几种情况时，需要进行恢复：
前两种情况需要冷恢复。冷恢复意味着，服务器处于离线模式，在关键的 dbspace 恢复之前无法使用。第三种情况需要热恢复。（本教程后面讨论冷恢复和热恢复）。
物理（physical）恢复是恢复 0、1、2 级备份的 dbspace 和 blobspace 的过程。物理恢复过程的效率非常高，因为它只需将页面映像从备份介质复制到磁盘上。
逻辑（logical）恢复使用逻辑日志备份磁带上的事务，将服务器系统恢复到失败时的状态。逻辑恢复在物理恢复之后执行。因为逻辑恢复不复制页面，而是重新应用事务记录，所以它比物理恢复过程慢得多，并且效率也较低。
冷恢复： 当根 dbspace 或者包含物理日志或逻辑日志的 dbspace（关键 dbspace）不可访问时，进行冷恢复。数据库服务器必须处于离线模式。全系统恢复总是冷恢复，因为包括关键 dbspace 在内的所有 dbspace 都要被恢复。
热恢复： 当根 dbspace 或者包含物理日志或逻辑日志的 dbspace（关键 dbspace）可访问时，进行热恢复。服务器必须处于在线模式或静默模式。
因为要恢复的 dbspace 不包含 rootdbs、物理日志或逻辑日志的数据，所以数据库服务器处于在线模式对恢复没有大的影响。所以，在引擎在线的情况下，如果只恢复数据 dbspace，就应该执行热恢复。热恢复需要重新应用逻辑日志（逻辑恢复），让 dbspace 恢复到最新的状态，并与其他 dbspace 保持一致的状态。
混合恢复： 只对关键 dbspace 进行冷恢复，然后对非关键 dbspace 进行热恢复。混合恢复会更快地恢复关键数据，但是完整的恢复要花更长时间，因为逻辑日志要经过几次恢复和重新应用 —— 对于最初的冷恢复和以后的每次热恢复，各执行一次。
有时候需要进行混合恢复。假设一个服务器包含一个根 dbspace、一个逻辑日志 dbspace、包含业务关键金融数据的 3 个（10 GB）dbspace 和包含历史数据的 50 个（10 GB）dbspace。使用冷恢复尽可能快地恢复关键 dbspace 和包含业务关键数据的 3 个 dbspace 是有好处的。在恢复了这些 dbspace 并且系统可供用户使用之后，使用热恢复恢复不太重要的历史数据。尽管系统的整个恢复时间更长了（逻辑日志必须应用两次，而且热恢复还会与活跃用户分享资源），但是混合恢复可以让业务更快地恢复运行。
并行恢复： 在并行恢复中，生成多个进程对多个 dbspace 同时进行恢复。并行恢复也称为 dbspace 恢复。可以使用 dbspace 恢复恢复一个 dbspace、多个 dbspace 或整个 OnLine 系统。并行恢复只能用 OnBar 执行。在使用 OnBar 时，dbspace 恢复会并行执行（除非 BAR_MAX_BACKUP 设置为 1）。如果使用 onbar -r 命令执行恢复，OnBar 会并行恢复存储空间并重新应用一次逻辑日志。
顺序恢复： 在使用 ontape 时，所有恢复都是顺序恢复，即每次恢复一个 dbspace。OnBar 全系统恢复是特殊用途的恢复，需要全系统备份。全系统恢复不需要进行逻辑恢复。如果没有维护逻辑日志备份，就只能进行全系统备份和恢复。
表级恢复
可以使用 archecker 实用程序执行表级恢复。archecker 实用程序使用 DBA 提供的一个模式命令文件恢复表。模式命令文件指定要提取的源表、数据恢复到的目标表以及链接两个表的 INSERT 语句。
时间点恢复或日志点恢复
时间点（point-in-time）恢复从 0、1 和 2 级备份恢复数据，并将逻辑日志恢复恢复到特定的时间点或特定的逻辑日志。
时间点恢复可以将数据库服务器恢复到以前某个时间点的状态。时间点恢复通常用于从错误中恢复。时间点恢复总是冷恢复，可以用这种恢复取消那些无法纠正的错误操作。
这种错误操作的一个示例是意外删除了一个表。完整的恢复会在物理恢复期间恢复这个表，但是在逻辑恢复期间再次删除它。时间点恢复可以将数据恢复到删除这个表之前的那个时间点。在将数据库服务器恢复到特定时间时，在这个时间点上还未提交的所有事务都会丢失。另外，这个时间点之后的所有事务也会丢失。
在冷恢复期间，可以指定新的块路径和偏移量，从而对块重命名。如果需要在执行备份的磁盘之外的其他磁盘上恢复存储空间，这个选项就很有意义了。可以重命名任何类型的块，包括关键块和镜像块。在冷恢复期间，有一些关键的考虑因素。这种恢复会对块的重命名执行以下检验：
如果两个检验步骤之一失败了，那么重命名过程停止，OnBar 将一个错误消息写入 OnBar 活动日志。
警告：在块重命名之后，应该执行 0 级备份；否则，在下一次恢复时，重命名的块又会恢复原来的路径名，不得不再次进行重命名。
要点：如果在执行 0 级备份之后添加了一个块，那么这个块无法在恢复期间重命名。另外，无法在映射列表中为这个块指定新路径。
新的块不一定是存在的。可以以后安装新的块，并对包含它的存储空间执行热恢复。如果指定不存在的块，OnBar 或 ontape 会在块保留页面中记录重命名信息，但是不恢复数据。重命名（但是没有恢复）的块处于离线状态，在 onstat -d chunk status 命令输出中表示为 N。
新的块必须有正确的权限。如果块没有正确的权限，重命名操作就会失败。
语法：
下面是在冷恢复期间执行块重命名的 OnBar 和 ontape 语法。重命名块：
（onbar 或 ontape） -r -rename -p old_path -o old_offset -n new_path -o new_offset 或使用 -f 文件名。（可以使用文件名同时对大量的块进行重命名。文件名指定的文件包含要重命名的块的名称和偏移量以及新的位置。在这个文件中，列出旧的块路径名、旧的偏移量、新的块路径名和新的偏移量。在每项之间放一个空格或制表符。每个块的信息单占一行。空行会被忽略。注释行以 # 符号开头。）
在执行恢复之前，将（未备份的）逻辑日志文件从磁盘备份到存储介质的过程称为逻辑日志救援（logical log salvage）。在发生系统失败之后，需要进行恢复，但是有些逻辑日志数据可能还没有备份到存储介质。必须挽救这些数据，因为需要利用这些数据将系统恢复到失败时的状态。系统失败之后的冷恢复会自动地尝试救援所有日志，但是用户也可以在冷恢复之前手动救援日志。onbar 日志救援命令是 onbar -l -s。ontape 日志救援命令是 ontape -S。如果在冷恢复过程之前必须更换包含逻辑日志文件的设备，那么日志救援命令就很有意义了。如果在系统失败之后没有救援磁盘上的日志，逻辑恢复过程就会覆盖日志空间，以前记录的事务就会丢失，系统就无法恢复到失败时的状态。
如果用 OnBar 只进行物理恢复（onbar -r -p），那么 OnBar 会跳过日志救援操作。如果使用 ontape 并发出 ontape -r 命令，就会询问您是否要备份逻辑日志。这就相当于询问，在 ontape 执行恢复之前是否希望救援日志。
