内容


IBM DB2 UDB 与 Oracle 的备份和恢复

对比指导

Comments

简介

通常,只有在丢失重要数据时,才会认真考虑数据库的备份和恢复。但对于每个生产系统,有必要设计和部署适当的备份和恢复策略,以避免数据丢失。

如果您在转向 DB2 时就已经具备 Oracle 技能,那么您随时可以学习如何在 DB2 UDB 中进行备份和恢复。在本文中,我将讨论如何在 DB2 UDB for Linux、UNIX 和 Windows 上进行备份的恢复,并将对照和比较在 Oracle 中如何实现这些功能。

在本文中,您将探索 Oralce 和 DB2 UDB 的备份和恢复的以下方面:

备份和恢复的概念

数据库的备份是数据库的副本以及一些控制信息,在出现故障的情况下,可以随时用它进行恢复。数据库备份最小化了数据丢失,能够让您使用恢复过程,从备份副本中重新构造失败的数据库。

有多种类型的失败导致需要恢复数据库。但不是所有类型的失败需要进行人工交互。下面是您可能会碰到的各种类型的失败:

  • 语句失败

    当应用程序中存在逻辑错误时,就会出现语句错误。出现这种失败可能有许多不同的原因,例如,语句无限循环运行、用户不具备执行某些任务所需的正确特权(导致有效的语句失败),或者由于空间不足而导致的插入失败等。

    在 Oracle 中,除了执行少量的任务以外,解决语句失败通常不要求具备管理员权限,这些任务包括添加更多的磁盘空间、修复应用程序逻辑,或者分配恰当的用户特权。 在 DB2 UDB 中,语句失败的处理方式与此类似。在备份和恢复方面,解决语句失败不需要管理员权限。

  • 用户错误

    对于数据库应用程序,有效但具破坏性的语句(比如删除整个工资单表中的记录、删除索赔(claims)表,或者意外删除整个数据库)可能导致长期的停机时间。要避免这些错误,就需要更多的正确培训和指导。数据定义语言(DDL)语句是不能回滚的语句。因此,如果用户的错误涉及 DDL,那么将需要采取正确的措施来恢复数据库。

    例如,如果错误删除了表,那么作为管理员,您有两种选择。您可以使用备份映射的副本,并将它前滚至删除表之前的某个时间点(时间点恢复),或者您可以通过 exp 实用程序恢复逻辑备份。这两种选择都可能潜在地导致数据丢失。

    当用户删除 DB2 UDB 中的表时,您可以执行数据库级时间点恢复,前滚至删除表之前的时间点;或者最好仍然使用表空间级的前滚操作。这样,您就不必让数据库停止服务,您的用户仍可以访问数据。在 场景一节,我们将看到这一点。

  • 进程失败

    用户、服务器或后台进程的失败是由于这些进程的异常终止,或者是因为从这些进程中断开连接。失败的进程将导致无法继续完成任务。

    对于 Oracle 上的进程失败,无需任何人工干预,就像 Oracle PMON 后台进程会定期监视这些异常终止的进程那样。而对于用户和服务器进程,PMON 将释放用户持有的锁,回滚每个未提交事件,并释放该进程正在使用的所有资源。如果异常终止一个 Oracle 后台进程,那么常常需要重启实例。

    在 DB2 UDB 上,像 db2agent 失效这样的进程失败会导致应急恢复。在应急恢复中,把提交的数据刷新到磁盘时,将回滚没有提交的事务。要启用这种自动应急恢复特性,需要验证是否把数据库配置参数 autorestart 设为 ON。默认情况下,autorestart 被设为 ON。

  • 数据库实例失败

    数据库实例失败通常是由操作系统崩溃或停电引起的。

    当 Oracle 上的数据库实例失败时,不需要人工干预,因为只要您重启计算机,Oracle SMON 后台进程就会检测问题。然后,SMON 将开始进行实例恢复。

    在 DB2 中,当数据库管理器和内存结构由于电源故障、磁盘损坏或网络故障而不能正常工作时,将需要通过应急恢复将 DB2 恢复到一致可用的状态。要启用自动应急恢复特性,需要验证是否将数据库配置参数 autorestart 设为 ON。默认情况下,autorestart 被设为 ON。 您也可以发出 RESTART DATABASE 命令来手工重启数据库。RESTART DATABASE 命令使用活动日志对尚未提交的更改进行回滚。已经提交但尚未刷新到磁盘的更改将被刷新到磁盘。

  • 媒介失败

    当有人无意从文件系统删除了数据库文件时,就会发生媒介失败,这时,整个硬盘及其数据文件都无法正常工作,从而导致无法访问数据,有时系统还会发生纯粹的数据损坏。相对于我们已经讨论的类型,这是更加严重的一类失败。

    在 Oracle 中,不要求由管理员来恢复媒介失败。通常,导致媒介失败的原因是数据文件的完全丢失,或者 SCN 时间戳与数据库的其余部分不同步。从这类失败中进行恢复的情况会根据具体条件有所不同,这主要取决于归档的模式及已经被损坏的数据文件。

    在 DB2 UDB 和 Oracle 中,这些失败的处理方式大致是一样的,都是通过脱机或联机备份并使用前滚操作恢复日志来完成的。

因为在所有类型的失败中,媒介失败是最复杂的,所以您必须有一个经过周密考虑的策略来计划它。本文的其余部分将致力于最后一种形式的失败的计划和恢复。

用于备份和恢复的数据结构

Oracle 和 DB2 UDB 都有一组组成备份和恢复机制的组件。您在 图 1图 2 中看到的体系结构图对提供 Oracle 和 DB2 的备份和恢复的主要组件进行了概述。

图 1. Oracle 体系结构
Oracle 体系结构
Oracle 体系结构

Oracle 的内存结构

  • 缓冲区缓存 —— 为存储从物理数据文件读取的数据块而分配的内存。
  • 共享池 —— 为存储解析的 SQL 语句、PL/SQL 过程的数据字典信息而分配的内存。
  • 日志缓冲区 —— 为存储更改数据的前后映像而分配的内存。里面记录的数据项是连续的。
  • 大型池 —— 分配给 RMAN 用于备份和恢复的内存。

Oracle 后台进程

  • 数据库读写器(DBWr)—— 异步地将缓冲区的脏数据写到物理数据文件中。
  • 日志读写器(LGWr)—— 从日志缓冲区写入项目,以便重做日志文件。
  • 检查点(CKPt)—— 将数据文件头和控制文件头与当前重做日志和检查点数同步。
  • 归档器(ARCH)—— 自动化重做日志的复制。如果没有打开归档器,那么需要对重做日志进行手动归档。

Oracle 数据库结构

  • 数据文件 —— 存储数据的物理文件。
  • 控制文件 —— 包含数据库物理结构和状态的文件,比如包含绝对路径的数据文件和日志文件的名称、文件的大小、块大小、数据文件的联机或脱机状态等。它还包含日志文件的名称和路径、文件大小和块大小。
  • 重做日志 —— 包含更改数据的前后映像的文件。对于恢复,重做日志是必需的。
  • 参数文件 —— 存储实例启动的参数的文件。您可以有多种启动实例的方式。Oracle 首先搜索 spfile_SID.ora 是否存在。如果该文件不存在,Oracle 接着会搜索 Spfile.ora 参数文件。如果 spfile_SID.ora 和 spfile.ora 都不存在,Oracle 将使用 init_SID.ora 参数文件。
  • 归档日志 —— 联机重做日志的物理副本。在联机恢复中,归档日志是必需的。

接下来我们将看到 DB2 UDB 体系结构和结构。

图 2. DB2 UDB 体系结构
DB2 UDB 体系结构
DB2 UDB 体系结构

DB2 UDB 内存结构

  • 包缓存 —— 为存储静态和动态 SQL 语句而分配的内存。
  • 缓冲池 —— 在将数据刷新到磁盘之前,为存储数据而分配的内存。
  • 日志缓冲区 —— 在将所有对数据库的更改刷新到磁盘上的日志之前,用来存储这些更改的内存。
图 3. DB2 UDB 数据库结构
 DB2 UDB 数据库结构
DB2 UDB 数据库结构
  • 驱动器/目录 —— 在 CREATE DATABASE 命令中指定的驱动器或目录。
  • DB2 实例名称 —— DB2 实例所有者的名称。
  • NODE0000 —— 数据库的分区数。0 表示非分区的数据库。
  • SQL00001 —— 从 1 开始的数据库 ID。
  • SQLOGDIR —— 数据库的默认日志目录。
  • SQLT0000.0 —— 目录表空间 SYSCATSPACE。
  • SQLT0001.0 —— 临时表空间 TEMPSPACE1。
  • SQLT0002.0 —— 用户表空间 USERSPACE1。

备份和恢复选择

对于 Oracle 和 DB2 UDB 数据库,有两种备份和恢复模式:脱机和联机。可以用任何一种模式来进行完全和不完全恢复。

脱机备份要求所有应用程序断开与数据库的连接,联机备份允许在备份的过程中继续执行事务。在选定备份模式的恢复方面,存在隐含关系,因为备份模式决定了恢复模式。我们在下面几节中会看到这一点。

顾名思义,完全恢复能够完全地恢复所有提交的事务,而不完全恢复在恢复事务时会丢失一些数据。Oracle 和 DB2 UDB 都能让您恢复到当前时间,而且没有数据丢失,或者恢复到当前时间以前的时间,但要丢失一些数据。

通常,恢复的目标是用选定的恢复模式在业务需求与操作需求之间达成某种妥协。例如,如果数据库不是任务关键型和 24X7 型的,那么停机上一段时间和丢失一些数据可能是可以接受的,对于媒介错误,重新键入数据也可能是一种可以接受的方法。采用什么样的恢复取决于可用的备份和可用的日志,可能有时候除了执行不完全恢复以外别无选择。

有两种类型的 DB2 日志记录,每种日志记录方法支持特定的恢复选项。这两种类型的日志记录是 循环归档日志记录。当选择使用循环日志记录(默认情况下选择这种日志记录)时,惟一的选择是执行脱机备份和版本恢复。如果您选择使用归档日志记录,并执行联机备份和前滚恢复,那么您可以恢复到数据丢失最少的那个时间点,或者恢复到结束日志的时候。

下面我们将详细分析这两种备份和恢复模式。

脱机(冷)备份

在 Oracle 中,所有备份当中的最简单形式是执行脱机或冷备份。脱机备份是正常关闭数据库之后,对所有物理数据库文件执行的备份。这种备份方法最常见。使用这种形式来备份数据库是在 NOARCHIVELOG 模式下进行的,在这种模式中,如果需要进行媒介恢复,那么备份之后对数据库进行的任何更改都将是不可恢复的。正如名称 NOARCHIVELOG 所暗示的那样,没有对重做日志进行归档,也就无法像联机重做日志那样支持前滚。在数据库文件的任何部分出现媒介失败的情况下,只需恢复所有数据库文件就可以实现备份,当然,备份之后所做的所有更改是不可恢复的。每当数据库的模式发生更改,或者进行像添加或删除数据文件、添加或删除表空间这样的更改时,建议管理员执行脱机备份。

可以将数据库文件从磁盘复制到磁盘,也可以将数据库文件从磁盘复制到磁带,这取决于选定的备份过程。像 Unix 的 cpio、tar 和 dd,以及 Windows 的备份管理器或 ocopy 这样的操作系统命令,都可以将物理数据库文件复制到备份媒介。数据库文件包括:

  • 数据文件。
  • 控制文件。
  • 联机重做日志。

如果您坚持使用 Oracle 的 Optimal Flexible Architecture (OFA),那么可以定位到这些文件。请参见 图 4

图 4. Optimal Fexible Architecture
Optimal Flexible Architecture
Optimal Flexible Architecture

在本例中,我们将 Oracle_BASE 设置为值 /u01/app/oracle,将 ORACLE_HOME 设置为 /u01/app/oracle/product/8.0.4 或者 /u01/app/oracle/product/8.1.7。

在 Oracle 上执行脱机备份的步骤是:

  • 在正常模式中关闭数据库。
  • 将所有数据文件、控制文件和联机重做日志文件复制到备份媒介。

在 DB2 UDB 中,脱机备份也是最简单的备份。脱机备份要求采取完全数据库备份,显然,在备份的过程中,数据库是脱机的。换言之,当执行脱机备份时,用户无法访问数据库。

如果您正在使用循环日志记录,脱机备份是惟一受支持的备份类型。当首先创建一个数据库的时候,这是默认的日志记录方法。对于循环日志记录,log retain for recovery status 和 user exit for logging status 都被设为 NO。LOGRETAIN 和 USEREXIT 两个参数都被设为 OFF。

图 5. LOGRETAIN OFF
LOGRETAIN OFF
LOGRETAIN OFF

在循环日志记录中,日志是以循环方式使用的,这非常像 Oracle 在 NoArchiveLog 模式中使用重做日志。只需将日志中的事务刷新到磁盘,就可以重用日志。但在长期运行的事务期间,可能发生日志已满的情形,在这种情形中,主要日志是活动的。当发生这种情形时,需要动态分配二级日志。DB2 配置参数 LOGSECOND 指定了在需要时可以动态分配的二级日志的最大数量(高达 254)。只有在数据库处于非激活状态时,才能删除二级日志。

图 6. 主要日志和二级日志
主要日志和二级日志
主要日志和二级日志
图 7. 数据库配置 LOGSEC
数据库配置 LOGSEC
数据库配置 LOGSEC

注意,如果决定使用循环日志记录和脱机恢复作为您的备份策略,那么最后一次脱机备份以后的所有事务都将丢失。

您可以从 Control Center 或者使用命令行处理器来执行脱机备份。 要执行 Control Center 备份,请执行以下步骤:

  • 打开 Control Center。
  • 转到想执行备份的数据库(例如 Sample),右击 Backup,如 图 8 所示。
    图 8. 在 DB2 UDB 中从 Control Center 备份
    在 DB2 UDB 中从 Control Center 备份
    在 DB2 UDB 中从 Control Center 备份
  • 注意,屏幕上显示了日志记录的状态。
    图 9. 循环日志记录
    循环日志记录
    循环日志记录
  • 单击 Next以继续。选择 FileSystem 作为媒介类型。单击 Add 并填写路径(比如e:\tmp)。然后单击 Next
    图 10. 选择媒介类型
    选择媒介类型
    选择媒介类型
  • 注意,屏幕上显示了您的惟一选择 Full Backup(完全备份)。单击 Next
    图 11. 备份选择屏幕
    备份选择屏幕
    备份选择屏幕
  • 接受默认值。然后单击 Next
    图 12. 选择备份参数
    选择备份参数
    选择备份参数
  • 输入用户 id 和口令,接受其余的默认值。
    图 13. 选择立即运行或作为任务运行
    选择立即运行或作为任务运行
    选择立即运行或作为任务运行
  • 如果选择作为任务运行,您将看到 图 14所示的屏幕:
    图 14. 任务创建摘要
    任务创建摘要
    任务创建摘要
  • 您可以从 DB 2 Task Center 立即运行它,或者让它根据计划的时间触发。完成的任务将像您在 图 15中看到的显示那样:
    图 15. Task Center 中的任务
    Task Center 中的任务
    Task Center 中的任务

如果选择从 DB2 命令行运行 backup,那么 backup 命令的语法是:

清单 1. 命令行 backup 语法
BACKUP DATABASE database-alias [USER username [USING password]]
      [TABLESPACE (tblspace-name [ {,tblspace-name} ... ])] [ONLINE]
      [INCREMENTAL [DELTA]] [USE {TSM | XBSA} [OPEN num-sess SESSIONS]] |
   TO dir/dev [ {,dir/dev} ... ] | LOAD lib-name [OPEN num-sess SESSIONS]]
      [WITH num-buff BUFFERS] [BUFFER buffer-size] [PARALLELISM n]
      [WITHOUT PROMPTING]

要在脱机模式下执行备份,只需发出以下 DB2 命令即可:

清单 2. 简单的脱机备份示例
backup database sample to e:\tmp

或者您可以有更多的选项,比如:

清单 3. 具有某些参数的脱机备份示例
backup database sample to e:\tmp
backup database sample to e:\tmp1, e:\tmp2
with 4 buffers
buffer 4096
parallelism 2

当发出 backup 命令时,将创建备份映像。注意,对于 UNIX 和 Windows,备份文件名称有点不同。对于 Windows,路径和文件名将具有以下格式:

图 16. Windows 中的备份文件
备份文件
备份文件

UNIX 备份文件看起来将像这样:

图 17. UNIX 备份文件
UNIX 备份文件
UNIX 备份文件

表 1展示了 Oracle 和 DB2 UDB 中脱机备份的相似和不同之处。

表 1. 比较脱机备份:Oracle 和 DB2 UDB
脱机备份(Oracle)脱机备份(DB2 UDB)
  • 不需要特定授权
  • 在 NoArchiveLog 模式(默认模式)下操作
  • 重做日志包含提交和未提交的数据
  • 日志以循环方式写入,也就是当最后一个日志已满,它将重写日志 1
  • 对于长期运行的事务,当所有的日志是活动时,日志写入将以循环方式进行重写
  • 如果重做日志没有被重新写入,您就可以通过前滚操作来执行恢复
  • 在备份前需要关闭所有事务
  • 最后一次备份以后的所有事务都将丢失
  • 使用操作系统(OS)级实用程序将数据库文件复制到其他磁盘或媒介
  • SYSADM、SYSCTRL 或 SYSMAINT 授权是必需的
  • 在 LOGRETAIN 和 USEREXIT 两个参数都被设定为 OFF 时执行操作
  • 循环日志包含提交和未提交数据
  • 日志以循环的方式写入,也就是当最后一个日志已满,它将重写日志 1
  • 对于长期运行的事务,当所有的日志是活动时,将根据参数 LOGSECOND 分配二级日志
  • 禁止前滚
  • 禁止连接。如果有一个活动连接,您将获得“SQL1035N:数据库目前在使用中。SQLSTATE=57019”错误
  • 最后一次备份以后的所有事务都将丢失
  • 发出 Backup Database 命令来进行备份

在 Oracle 中从脱机(冷)备份中恢复

关于在 Oracle 中恢复脱机备份,没有什么特殊的地方。只需将物理数据库文件复制回正确的位置即可。在您需要重新定位数据文件的情形下,您需要通过发出下面的命令来更新控制文件。

清单 4. 用来在 Oracle 中重定位数据文件的命令
alter database rename file <oldpath> to <newpath>

对于 DB2 UDB,每个备份都将创建一个时间戳。因此,恢复要基于备份时间戳以确保能够恢复最后的备份映像,这样,就可以最小化数据丢失。注意,如果非常频繁地进行备份,数据丢失的可能性就会比较小。

图 18 用一个示例进行了说明。在工作单元 4 中,出现了一个被损坏和不可访问的目录导致了执行失败。您可以将它恢复到 Backup DB4 或更早备份。想像一下,如果没有 Backup DB4 这个备份映像,除了获取一个比 2004062510 时所作的备份映像更早的备份映像以外,您将别无选择。

图 18. 脱机备份和恢复
脱机备份和恢复
脱机备份和恢复

对于 DB2 UDB,还有两种可供您选择的恢复方法。您可以使用 Control Center 或命令行处理器(command line processor,CLP)。要从 Control Center 恢复,请执行这些步骤:

  • 从 Control Center 选择数据库(比如 Sample),右击该数据库来执行恢复。您可以看到一些如下所示的选项。单击 Next
    图 19. 脱机恢复选项
    脱机恢复选项
    脱机恢复选项
  • 高亮显示备份映像,并移动到右边的面板。然后单击 Next
    图 20. 备份映像选择
    备份映像选择
    备份映像选择
  • 如果需要,可以选择重定向容器:
    图 21. 容器重定向选项
    容器重定向选项
    容器重定向选项
  • 注意,屏幕上显示了您的惟一选项 Full Backup。单击 Next
    图 22. 选择恢复参数
    选择恢复参数
    选择恢复参数
  • 接受默认值。然后单击 Next
    图 23. 选择更多的恢复参数
    选择更多的恢复参数
    选择更多的恢复参数
  • 接受默认值或选择立即运行。输入用户 id 和密码。单击 Next
    图 24. 任务计划
    任务计划
    任务计划
  • 单击 Finish
  • 一旦完成恢复,您将在 Task Center 中看到像这样的内容:
    图 25. 任务创建摘要
    任务创建摘要
    任务创建摘要

要执行脱机备份的 CLP 恢复,清单 5 中展示了命令语法:

清单 5. 恢复数据库的命令
RESTORE DATABASE source-database-alias
   { restore-options | CONTINUE | ABORT }
restore-options:
  [USER username [USING password]] [{TABLESPACE [ONLINE] |
  TABLESPACE (tblspace-name [ {,tblspace-name} ... ]) [ONLINE] |
  HISTORY FILE [ONLINE]}] [INCREMENTAL [AUTOMATIC | ABORT]]
  [{USE {TSM | XBSA} [OPEN num-sess SESSIONS] |
  FROM dir/dev [ {,dir/dev} ... ] | LOAD shared-lib
  [OPEN num-sess SESSIONS]}] [TAKEN AT date-time] [TO target-directory]
  [INTO target-database-alias] [NEWLOGPATH directory]
  [WITH num-buff BUFFERS] [BUFFER buffer-size]
  [DLREPORT file-name] [REPLACE EXISTING] [REDIRECT] [PARALLELISM n]
  [WITHOUT ROLLING FORWARD] [WITHOUT DATALINK] [WITHOUT PROMPTING]

例如,要从 E:\tmp 恢复特定的映像,您需要指定要恢复的备份映像。 清单 6 中的命令将恢复 6 月 17 日 10:00 AM 左右取得的映像。

清单 6. 简单恢复数据库命令
db2 restore database sample from e:\tmp taken at 2004061710
图 26. 使用 CLP 恢复数据库
使用 CLP 恢复数据库
使用 CLP 恢复数据库

在媒介失败的情况下,恢复到原始目录是不可能的。这时您可以使用 RESTORE DATABASE…REDIRECT 来使用不同的容器。如果目录和文件容器都已不存在,该命令会自动创建它们。例如,如果需要重定向编号为 0 的表空间,那么可以发出以下命令:

清单 7. 使用 CLP 重定向的容器
db2 restore database sample from e:\tmp taken at 2004061710 replace existing
db2 set tablespace containers for 0 using (path 'E:\tmp\0')
     (note if it’s a DMS tablespace, you will need a set  tablespace containers for 0
     using (file 'e:\tmp\0.dms' <SIZE>)
db2 restore database sample continue

表 2 比较了 DB2 UDB 和 Oracle 的脱机恢复。

表 2. 比较 Oracle 和 DB2 UDB 的脱机恢复
脱机备份(Oracle)脱机备份(DB2 UDB)
  • 不需要特殊的特权
  • 执行备份的管理员需要为它们贴上正确标签,以便在恢复的过程中,不会恢复备份的错误副本
  • 可以用 Alter Database Rename File <oldpath> to <newpath> DDL 语句来重命名和重新定位数据文件
  • 不能恢复到不同的数据库
  • 恢复到现有的数据库需要 SYSADM、SYSCTRL 或 SYSMAINT 特权。恢复到新数据库将需要 SYSCTRL 或 SYSADM 特权
  • 在恢复的过程中,管理员可以从某些时间戳中挑出备份。来自 Control Center 和 CLP 的备份命令会为备份创建时间戳简化恢复过程
  • 通过调用 RESTORE DATABASE 命令,并指定 REDIRECT 参数,您可以重定义表空间容器
  • 可以恢复到现有数据库或新的数据库

联机(热)备份

Oracle 联机备份

在 Oracle 中,联机备份要求在 ARCHIVELOG 模式中执行对数据库的操作。在一个在线商店中,数据库必须是 24x7 都处于打开状态的,所以,让用户进行脱机备份而不访问数据库是不可能的。在这种场景中,应该在 ARCHIVELOG 模式下运行数据库,在该模式中,事务将继续运行,同时,备份处理也在继续。

与脱机备份不一样,联机备份只要求备份数据文件和控制文件。脱机数据库的备份单位是整个数据库,而联机备份的备份单位是一些或全部表空间。

在 Oracle 中,联机备份的全部思想是,当用户执行事务时,将对数据库所做的所有更改(提交或未提交的)都存储到重做日志缓冲区中,随后由 LGWr 进程把它们写到联机重做日志文件中。重做日志是以循环的方式写入的;因此,在重写它们之前,需要通过启动 ARCH 进程来手动或自动对重做日志进行归档。当记录了所有事务并在以后通过多路复用进行归档时(使用参数 LOG_ARCHIVE_DUPLEX_DEST),如果需要进行媒介恢复,那么可以使用这些归档的重做日志进行恢复。

注意,使用联机备份本身无法保证您不丢失数据。像通过多路复用(放在不同的位置)控制文件使数据库免疫、使用联机重做日志和归档重做日志这样的步骤,都是避免单点故障所必需的。

在 Oracle 中,要从默认的脱机备份切换到具有自动归档的联机备份,您需要执行下面的操作:

  • 在 init.ora 中,用适当的值填写参数 LOG_ARCHIVE_START、LOG_ARCHIVE_DEST、LOG_ARCHIVE_FORMAT 和 LOG_ARCHIVE_DUPLEX_DEST 和 LOG_ARCHIVE_DEST_N。
  • 关闭和启动装入(Mount)。
  • 在 archivelog 模式下操作数据库。
  • 打开数据库。
  • 验证归档日志清单。
  • 归档所有日志。
  • 备份所有新创建的日志。

通过执行命令“Alter Tablespace ts_name Begin Backup”,将任何或所有联机表空间置于联机备份模式来启动联机备份。当发出这个命令时,处于联机备份模式的所有数据文件都将被发放检查点 SCN。换句话说,将把数据缓冲区的所有脏位刷新到数据文件。在初始检查点 SCN 后,就不会再发放新的检查点 SCN。对于没有处在联机备份模式的那些数据文件,随后的检查点将在它们的文件头中添加 SCN。当发出 “Alter Tablespace ts_name End Backup”时,在联机备份数据文件的的文件头中再次记录了检查点 SCN。Begin Backup 和 End backup 命令让 Oracle 知道要重做什么操作,及在前滚会在什么地方终止。

Oracle 建议在 Begin backupEnd backup命令之间耗用最少的时间。此外,应该在这段时间内尽量少进行用户活动,这是由于 Oracle 会在第一次更改块时记录下整个块的映像。对于联机备份数据文件,这将导致生成大量的重做日志。实际上,在执行 Begin backup后,接下来应该立刻执行系统复制,然后由 End backup 来快速结束操作。备份是严格按照顺序进行的,这意味着在备份了表空间 1 中的数据文件后,将继续备份表空间 2 中的数据文件。

对于联机备份,需要特别注意 SYSTEM 表空间和回滚段表空间。同时,还需要确保只要对数据库的模式进行了更改,就要对控制文件进行备份。备份脚本应该反映最新的模式。

DB2 UDB 联机备份

DB2 UDB 执行时间点恢复的机制类似于 Oracle。要了解 DB2 UDB 联机备份和恢复,就需要了解归档日志记录。有三种我们需要熟悉的日志定义:

  • 活动日志 —— 该日志包含没有提交或回滚的事务,或者已提交但尚未刷新到磁盘的事务。
  • 联机归档日志 —— 该日志包含已提交并且被记录到硬盘的事务的信息,和活动日志位于同一目录。
  • 脱机归档日志 —— 如果将联机归档日志从活动日志所在目录移动到其他目录或磁带中,就成为了脱机归档日志。

有许多与日志记录有关的配置参数:

  • LOGFILSIZ —— 每个日志文件的大小,默认值是 250,单位为 4KB。
  • LOGPRIMARY —— 主日志文件的个数(默认值是 3)。
  • LOGSECOND —— 主日志文件占用满时,可以分配的二级日志文件的个数。当把这个参数设为 -1 时(版本 8),可以使用无限数量的活动日志。
  • NEWLOGPATH —— 用来更改日志文件的存储位置。要想使该参数生效,需要重新激活数据库。
  • MIRRORLOGPATH —— 日志文件的镜像路径,以避免单点故障。
  • OVERFLOWLOGPATH —— 指定前滚期间可以在哪些目录搜索需要的日志,以允许前滚操作能访问多个目录中的日志。
  • USEREXIT——用于启动用户出口功能,进行日志的自动归档。
  • BLK_LOG_DSK_FUL——当 DB2 无法在活动日志路径中创建新日志文件时,防止生成磁盘已满错误。

为了使用联机备份,必须打开归档日志记录。通过将 LOGRETAIN 设为 ON,可以打开归档日志记录。

归档日志记录是一种不同于循环日志记录的日志记录机制,因为循环日志记录重写了提交的日志,而归档日志记录归档了提交的日志。

在归档日志记录中,不能重用已经变成归档日志的日志。要移动那些联机归档日志,您需要手动移动它们或者使用用户出口程序(user exit)来移动它们。 图 27举例说明了归档日志记录机制:

图 27. 活动、联机和归档的日志记录
活动、联机和归档的日志记录
活动、联机和归档的日志记录

图中的 LOG (n+1)是活动日志,log (n) 和 log (n-i)(其中 i<=n)都是联机归档日志。这些归档日志既可以位于存储活动日志的路径中,也可以使用用户出口程序来指定将保存它们的目录或媒介。

默认情况下,活动和联机归档日志保存在 SQLOGDIR 目录中。NEWLOGPATH 数据库配置参数确定了将在哪里存储未来的活动归档日志。要想使 NEWLOGPATH 参数生效,需要停用数据库(目的是关闭所有活动日志文件)。然后,重新激活数据库将导致在新路径中创建新日志文件,原来的归档日志将留在原来的路径中。

当进行联机备份时,将记录所有的数据库事务。在完成联机备份之后,DB2 将强行关闭当前活动日志,并对其进行归档,如 图 28 所示:

图 28. 正在关闭的活动日志
正在关闭的活动日志
正在关闭的活动日志

要防止脱机归档日志的单点故障,比如媒介失败,则应该使用日志镜像。MIRRORLOGPATH 是用来指定镜像路径的配置参数,它允许 DB2 将相同日志文件的第二份副本写入不同目录中。您需要重新激活数据库,以使 MIRRORLOGPATH 配置参数变得有效。

如果将副本写入镜像日志路径时发生问题,那么 DB2 将在管理通知日志中写入消息,指出已经碰到错误。DB2 将继续把日志记录写入能工作的日志路径中。不需要同步日志路径。要确定哪个日志是活动的,哪些日志是归档的,请使用 DB2 命令 GET DB CFG 来查看“第一个活动日志文件”。该命令提供了目前活动的日志文件,因此被归档的日志将是那些比当前日志更早的日志。

此外,诸如数据库、表空间或增量的备份的每个备份操作都将包括恢复历史文件(RHF)的一个副本。您可以使用历史文件中提供的信息,将整个数据库或数据库的一部分恢复到某个时间点。每个数据库都会创建一个恢复历史文件,并且在下列情况下会自动对该文件进行更新:

  • 备份数据库或表空间。
  • 恢复数据库或表空间。
  • 前滚数据库或表空间。
  • 创建表空间。
  • 修改表空间。
  • 休止表空间。
  • 重命名表空间。
  • 删除表空间。
  • 加载表。
  • 删除表。
  • 重组表。

要查看恢复历史文件,可以发出下面的命令,用对应的数据库名称替换“sample”:

清单 8. 列出备份历史
db2 list history backup all for sample
图 29. 列出备份历史
列出备份历史
列出备份历史

对于联机备份,有两种可以采用的备份级别:表空间级和数据库级联机备份。并且有两种执行联机备份的方法。您可以使用 Control Center GUI 或 CLP 命令行提示来执行联机备份。

要使用 Control Center 来执行联机表空间级和数据库级备份,请执行这些步骤:

  • 要通过 Control Center 打开 LOGRETAIN,需要高亮显示该数据库,然后右击它来修改配置参数。将 LOGRETAIN 从默认值 NO 更改为 RECOVERY。关闭然后再次启动数据库,使配置更改生效。
    图 30. 用 Control Center 修改 LOGRETAIN
    用 Control Center 修改 LOGRETAIN
    用 Control Center 修改 LOGRETAIN
  • 还需要执行完全脱机备份。如果没有执行该备份,您将收到下面尝试连接数据库的错误。
    图 31. 备份挂起的消息
    备份挂起的消息
    备份挂起的消息
  • 现在,使用 CLP 命令执行完全脱机备份
    图 32. 完全脱机备份
     完全脱机备份
    完全脱机备份
  • 导航到数据库 sample,右击该数据库来执行备份。您看到的第一个屏幕将如下所示。选择 Backup selected table spaces,然后单击 Next
    图 33. 联机备份选择
    联机备份选择
    联机备份选择
  • 选择要备份的表空间 Userspace1。然后单击 Next
    图 34. 选择要备份的表空间
    选择要备份的表空间
    选择要备份的表空间
  • 出于测试的目的,选择文件系统。然后添加路径,比如 E:\tmp。最后单击 Next
    图 35. 媒介类型选择
    媒介类型选择
    媒介类型选择
  • 接受默认值,然后单击 Next
    图 36. 选择脱机备份
    选择联机备份
    选择联机备份
  • 接受默认值,然后单击 Next
    图 37. 指定备份参数
    指定备份参数
    指定备份参数
  • 接受默认值。然后输入用户 id 和口令。单击 Next
    图 38. 立即运行或保存为任务
    立即运行或保存为任务
    立即运行或保存为任务
  • 单击 Finish
    图 39. 任务创建摘要
    任务创建摘要
    任务创建摘要

    如果您决定执行数据库级备份(对于大小有限的数据库,这是理想的),那么您需要执行以下操作:

  • 导航到数据库 sample,右击该数据库来执行备份。您看到的第一个屏幕将如下所示。选择 Backup entire database,然后单击 Next
    图 40. 备份整个数据库
    备份整个数据库
    备份整个数据库
  • 选择路径。然后单击 Next
    图 41. 选择媒介类型
    选择媒介类型
    选择媒介类型
  • 接受默认值。然后单击 Next
    图 42. 联机备份
    联机备份
    联机备份
  • 接受默认值。然后单击 Next
    图 43. 备份参数
    备份参数
    备份参数
  • 接受默认值。输入用户和口令。然后单击 Next
    图 44. 计划任务
    计划任务
    计划任务
  • 单击 Finish

要通过 CLP 命令行提示执行联机表空间级和数据库级备份,请执行下面这些步骤。

  • 打开 LOGRETAIN。关闭然后再次重启数据库,以使配置更改生效。
    图 45. 打开 LOGRETAIN
    打开 LOGRETAIN
    打开 LOGRETAIN
  • 一旦配置参数生效,您将看到 LOGRETAIN = RECOVERY。
    图 46. LOGRETAIN = RECOVERY
    LOGRETAIN = RECOVERY
    LOGRETAIN = RECOVERY
  • 还需要执行完全脱机备份。如果没有执行该备份,您将收到下面尝试连接数据库的错误。
    图 47. 挂起的备份
    挂起的备份
    挂起的备份
  • 现在使用 CLP 命令来执行完全脱机备份。
    图 48. 完全脱机备份
    完全脱机备份
    完全脱机备份
  • 要执行表空间级联机备份,可以发出以下命令:
    清单 9. 通过 CLP 联机备份表空间
    db2 backup database sample tablespace(userspace1) online to e:\tmp
    图 49. 通过 CLP 联机备份表空间
    通过 CLP 联机备份表空间
    通过 CLP 联机备份表空间
  • 要执行数据库级联机备份,可以发出以下命令:
    清单 10. 通过 CLP 联机备份表空间
    db2 backup database sample online to e:\tmp
    图 50. 通过 CLP 联机备份数据库
    通过 CLP 联机备份数据库
    通过 CLP 联机备份数据库

表 3 比较了 DB2 UDB 和 Oracle 的联机备份。

表 3. 比较 Oracle 和 DB2 UDB 的联机备份
联机备份(Oracle)联机备份(DB2 UDB)
  • 需要 SYSDBA 特权
  • 在 ArchiveLog 模式下进行操作
  • 重做日志包含提交和未提交的数据。Oracle 使用归档日志来前滚到一致状态,并撤销表空间来回滚任何未提交数据
  • 联机重做日志以循环的方式进行写入,也就是当最后一个日志已满时,将重写日志 1。在日志切换期间,将归档联机重做日志
  • 对于长期运行的事务,当所有日志都处于活动状态时,如果手动对非活动联机重做进行归档,或者让 ARCH 进程来为您完成这项工作,那么只需重写联机重做日志即可。上述任何一项工作失败都将导致 Oracle 挂起
  • 可以使用 LOG_ARCHIVE_DUPLEX_DEST、LOG_ARCHIVE_DEST_N 来指定 Oracle 写入日志的多个位置。LOG_ARCHIVE_DEST_N 的最大值是 10。当路径有问题时,只要有一条路径可以工作,Oracle 就会忽略有问题的路径继续工作。不过,会有一条消息记录在审核跟踪中。不需要对这些路径进行同步
  • 启用 ArchiveLog 模式需要一个数据库回弹(database rebounce),以及严格、干净的完全备份
  • 控制文件包含数据库的名称、日志序列和检查点信息、物理文件结构等
  • 表空间级备份
  • 备份所有数据块(更改和未更改的)。不适合大型仓库环境
  • 在备份中没有压缩
  • 数据库恢复和前滚不一定要求关闭数据库
  • 连续备份 —— 一个接一个地备份表空间
  • 发出“Alter Tablespace ts_name Begin Backup”命令
  • SYSADM、SYSCTRL 或 SYSMAINT 特权是恢复现有数据库所必需的。要通过恢复创建新的数据库,就需要有 SYSADM 和 SYSCTRL 特权
  • 在 LOGRETAIN=ON 中操作
  • 日志包含提交和未提交的数据。在 DB2 中,使用日志进行前滚和回滚
  • 日志没有使用循环的方式写入。因此不用重写归档的日志。在 DB2 关闭活动日志之后,活动日志将变成归档日志
  • 对于长期运行的事务,当所有的日志都处于活动状态时,将根据参数 LOGSECOND 来分配二级日志
  • MIRRORLOGPATH 配置参数可用于多路复用日志。MIRROLOGPATH 的最大值是 1。当一条路径不通时,只要有另一条路径可以工作,DB2 就会在 DB2 管理通知日志中写入一条消息并继续工作。但是,在完成当前日志时,DB2 会连续地尝试写到坏的路径。不需要将这些路径进行同步
  • 在重启 DB2 数据库之后,LOGRETAIN 将是惟一有效的参数。您需要进行完全脱机备份
  • 恢复历史文件包含像下面的一些信息:数据库或表空间的备份和恢复、从数据库或表空间进行前滚恢复、修改和停止表空间、REORG 和 RUNSTATS、删除表等
  • 表空间级和数据库级的备份
  • 备份所有的数据块(更改的和未更改的)。不适合大型仓库环境
  • 已经将备份压缩作为一个选项添加到 BACKUP DATABASE 命令和 db2Backup API 中
  • 数据库恢复和前滚必须脱机完成。表空间级的恢复和前滚不要求脱机操作
  • 允许并行操作
  • 发出 Backup Database 命令进行备份。例如 Backup database sample tablespace(userspace1) online to e:\tmp 或 Backup database sample to e:\tmp

从联机(热)备份中恢复

Oracle 联机恢复很大程度上取决于实际丢失了什么,例如,在联机重做日志上丢失了一个组、丢失了回滚段数据文件或者 SYSTEM 表空间的数据文件的损坏。实际上,可以从两种情形对数据进行完全恢复或部分恢复。有关的更详细的示例,请参考 情形场景一节。

要在 DB2 UDB 中执行前滚恢复,必须使用归档日志记录。在数据库的恢复期间,该记录的使用具有排它性。您可以在数据库级或表空间级上进行恢复。您将可以恢复备份映像和前滚来完成恢复处理,或者让数据库停留在挂起状态。有两种类型的前滚:

  • 前滚到日志结束。
  • 前滚到某个时间点。

在 DB2 UDB 中,有两个选项来执行恢复:Control Center 和 CLP。下面一些步骤向您展示了如何进行整个数据库的恢复。

  • 在 Control Center 中右击 Sample 数据库并选择 Restore
    图 51. 从 Control Center 进行恢复
    从 Control Center 进行恢复
    从 Control Center 进行恢复
  • 注意,有三个选项:恢复到现有数据库、恢复到新数据库或者只恢复 RHF。在本例中,我们要恢复到现有数据库。单击 Next
    图 52. 恢复选择
    恢复选择
    恢复选择
  • 要恢复整个数据库,请接受默认值。然后单击 Next
    图 53. 恢复整个数据库
    恢复整个数据库
    恢复整个数据库
  • 选择要恢复的备份映像。
    图 54. 选择要恢复的备份映像
    选择要恢复的备份映像
    选择要恢复的备份映像
  • 保留默认值。当容器遭受破坏时,需要用到重定向。选择重定向会将您的数据库置于恢复挂起状态。单击 Next
    图 55. 选择要恢复的备份映像
    选择要恢复的备份映像
    选择要恢复的备份映像
  • 您可以选择是否进行前滚。前滚所需要的日志可以从默认日志目录或溢出路径中选择。在我们的示例中,我们选择恢复到按照本地时间计算的时间点。
    图 56. 前滚选项
    前滚选项
    前滚选项
  • 您可以让数据库停留在挂起状态或活动状态。挂起状态适合于容器重定向。在这里我们选择活动状态。单击 Next
    图 57. 数据库的最终状态
    数据库的最终状态
    数据库的最终状态
  • 接受默认值。单击 Next
    图 58. 参数选项
    参数选项
    参数选项
  • 接受默认值。然后单击 Next
    图 59. 更多的参数选项
    更多的参数选项
    更多的参数选项
  • 现在,在没有保存任务历史的情况下运行恢复。单击 Finish。注意如果数据库不处于排它模式,您将看到下面的一些错误:
    图 60. 在联机恢复期间的非排它使用
    在联机恢复期间的非排它使用
    在联机恢复期间的非排它使用

在 CLP 中,您将发出下面的命令来执行恢复,并前滚整个数据库。

清单 11. 恢复并前滚整个数据库
RESTORE DATABASE SAMPLE FROM "e:\tmp" TAKEN AT 20040629152131
   WITHOUT PROMPTING;
ROLLFORWARD DATABASE SAMPLE TO 2004-06-29-15.23.09.000000 USING
   LOCAL TIME AND COMPLETE;

但有时候,对较大的数据库执行表空间级备份会更经济。而且恢复表空间将只要求排它使用某个表空间。其余的表空间仍可以访问。您可以一次恢复多个表空间。下面步骤展示了如何从表空间进行恢复(假定 USERSPACE1 被破坏了):

  • 不是选择恢复整个数据库,而是选择 Restored selected table spaces。然后单击 Next
    图 61. 选择恢复表空间而不是恢复整个数据库
    选择恢复表空间而不是恢复整个数据库
    选择恢复表空间而不是恢复整个数据库
  • 选择要使用的备份映像。然后单击 Next
    图 62. 选择要恢复的备份映像
    选择要恢复的备份映像
    选择要恢复的备份映像
  • 其余的步骤与从整个数据库进行恢复的步骤相同。
  • 在 Restore Option 页面上,您可以联机恢复表空间。记住,完全数据库恢复将要求整个恢复操作具有排它性,而表空间的联机恢复将只要求表空间处于排它模式中。
    图 63. 选择恢复选项
    选择恢复选项
    选择恢复选项

在 CLP 中,可以发出以下命令来执行恢复,并前滚表空间:

清单 12. 恢复和前滚整个数据库
RESTORE DATABASE SAMPLE TABLESPACE (USERSPACE1)
    ONLINE FROM "e:\tmp" TAKEN AT 20040629152131 WITHOUT PROMPTING;
ROLLFORWARD DATABASE SAMPLE TO END OF LOGS AND COMPLETE
    TABLESPACE (USERSPACE1) ONLINE;

表 4 比较了 DB2 UDB 和 Oracle 的联机恢复

表 4. 比较 Oracle 和 DB2 UDB 的联机恢复
联机恢复(Oracle)联机恢复(DB2 UDB)
  • 从数据库文件恢复
  • 数据库和表空间恢复得到支持
  • RECOVER DATABASE UNTIL 命令被用于支持不完全恢复
  • 从备份映像恢复
  • 数据库和表空间恢复得到支持
  • 完全和不完全恢复都将使用备份映像,可以启用或不启用前滚操作

增量备份和恢复

当数据库大小增长到 GB 和 PB 级时,所需的时间和硬件资源将极大的增长。通常,备份整个数据库或一次备份几个表空间是不可行的。例如,在数据仓库环境中,数据中可能只有少数几个地方做了修改。在这种情形中,只备份更改的页面而不是备份整个数据库或表空间会更好一些。

在 Oracle 中,可以用 Recovery Manager 进行增量备份。Oracle 提供了两种类型的增量备份。

  • 差异增量(默认)。
  • 累积增量。

差异增量备份用来在级别 n 或更低级别上备份最近备份后更改的所有块。可以为差异增量指定级别 0-4。下图阐述了差异增量备份的概念。

图 64. Oracle 差异增量备份
Oracle 差异增量备份
Oracle 差异增量备份

下面是差异增量备份的说明:

  • 对于第一个星期天,采用基本级别 0 备份来复制所有数据块。
  • 星期一使用级别 2,由于 0 比 2 低,所以 RMAN 将备份星期天以后的更改。
  • 星期二使用级别 2,由于星期一处于相同的级别,所以 RMAN 将备份星期一以后的更改。
  • 星期三使用级别 2,由于星期二处于相同的级别,所以 RMAN 将备份星期二以后的更改。
  • 星期四使用级别 1,由于星期一、二、三都高于级别 1,所以 RMAN 将备份星期天以后的更改,因为星期天的级别是 0,这是一个较低的级别。
  • 星期五使用级别 2,由于星期四使用级别 1 —— 较低的级别,所以 RMAN 将备份星期四以后的更改。
  • 星期六使用级别 2,RMAN 将备份星期五以后的更改。
  • 第二个星期天(这里指定了级别 0),RMAN 将备份自最后一个级别 0 以后的更改,因为自上个星期天以来,没有等于或小于级别 0 的。
  • 重复这个过程。

另一方面,累积增量备份将备份自最近在级别 n-1 或更低级别上进行备份以后使用的所有数据块。 图 65 阐述了累积增量备份的概念。

图 65. Oracle 累积增量备份
Oracle 累积增量备份
Oracle 累积增量备份

下面是累积增量备份的一些说明:

  • 第一个星期天使用级别 0。RMAN 将备份已经在数据库中使用的所有数据块。
  • 星期一使用级别 2。RMAN 将备份星期天以后做的所有更改,因为级别 0 比 2 还要低。
  • 星期二使用级别 2。RMAN 将备份星期天以后做的所有更改。该备份包括星期一复制的那些块。
  • 星期三使用级别 2。RMAN 将备份星期天以后做的所有更改。该备份包括星期一和星期二复制的那些块。
  • 星期四使用级别 1。RMAN 将备份星期天以后做的所有更改。
  • 星期五使用级别 2。RMAN 将备份星期四以后做的所有更改。
  • 星期六使用级别 2。RMAN 将备份星期四以后做的所有更改。
  • 第二个星期天(这里指定了级别 0),没有低于 0 的级别,除了前一个星期天的级别 0。因此将备份前一个星期天以后做的所有更改。
  • 重复这个过程。

DB2 UDB 有类似的增量和恢复策略。它提供的两种增量备份类型是:

  • 增量备份。
  • delta 备份。

增量备份是自最近成功的完全备份以来所有更改的备份。这种形式的备份也称为累积备份。每个连续的增量映像都包含前一个增量映像的全部内容,以及前一个完全备份以后所做的更改。在备份失败的情况下,例如,在执行了增量备份后的星期六,您只可以恢复第一个星期天的完全备份,并应用星期六的增量备份。请参见下图。

图 66. DB2 UDB 增量备份
DB2 UDB 增量备份
DB2 UDB 增量备份

delta 备份是上一次成功的完全、增量或 delta 备份以后所做更改的备份。在星期六出现失败的情况下,您可以恢复第一个星期天的完全备份,并应用星期一到星期六的 delta 备份。请参见下图:

图 67. DB2 UDB delta 备份
DB2 UDB 差异备份
DB2 UDB 差异备份

可以配置参数 TRACKMOD 跟踪数据库更新。当将该参数设置成 NO(默认)时,就不用跟踪数据库页面更新。在将该参数设置为“Yes”时,数据库管理器就会跟踪数据库修改,这样,备份实用程序就能够检测数据库页面的哪些子集必须由增量备份负责检查,以及备份映像中可能包括哪些子集。在将该参数设置为“Yes”之后,您必须执行完全数据库备份,以便在可以采用哪些增量备份上有一个基线。

注意,允许进行组合数据库和表空间增量备份。对于表空间跟踪,每个表空间的标志指出了表空间是否是脏的,以及是否需要备份。

下面的步骤向您展示了如何执行增量备份和恢复。假定我们像上面描述的那样执行了备份 —— 星期天执行完全备份,星期一至星期六执行增量备份。

  • 打开 TRACKMOD。确保在重连接生效前断开所有应用程序的连接。发出如下命令:
    清单 13. 打开 TRACKMOD
    update db cfg using trackmod on
    图 68. 打开 TRACKMOD
    打开 TRACKMOD
    打开 TRACKMOD
  • 执行完全数据库备份作为增量备份的基础。这是星期天的备份。可以发出如下命令:
    清单 14. 联机备份数据库
    db2 backup database sample to e:\tmp
    图 69. 联机备份数据库
    联机备份数据库
    联机备份数据库
  • 在星期一,需要执行增量备份。可以发出如下命令:
    清单 15. 增量备份数据库
    db2 backup database sample incremental
    图 70. 增量备份数据库
    增量备份数据库
    增量备份数据库
  • 从星期二到星期六,可以重复增量备份过程。
  • 比方说,在下个星期天的早上,发生了媒介失败。要进行恢复,而又不丢失数据,那么您需要从第一个星期天备份恢复,然后恢复星期六取得的增量备份并进行前滚。注意,您可以手动恢复完全备份,应用星期六的增量备份映像并进行前滚。您可以使用 automatic 关键字自动从完全备份中恢复数据,并应用星期六备份映像。这时,您仍将处于前滚挂起模式(SQL1117N),因为有要前滚的事务。
    清单 16. 自动从增量备份恢复
    db2 restore database sample incremental automatic
       from e:\tmp taken at 20040701112735 without prompting
    图 71. 增量恢复
    增量恢复
    增量恢复
    清单 17. 前滚到日志结束
    db2 rollforward database sample to end of logs and complete
    图 72. 前滚到日志结束
    前滚到日志结束
    前滚到日志结束

对于相同场景中的 delta 备份和恢复,您将恢复每天的 delta 备份映像(星期一到星期六),并执行前滚操作来完成恢复。DB2 UDB 提供了实用程序 db2chrst 来查询数据库历史,并为增量恢复所需的备份映像生成了一系列时间戳。

备份和恢复实用程序

Oracle 和 DB2 UDB 提供了一些实用程序来保护备份映像。下表列出了其中的一些实用程序。

表 5. 比较保护备份映像和数据库文件的实用程序的表
Oracle 实用程序DB2 UDB 实用程序
  • Export —— Oracle 使用 Export 来执行逻辑备份。Export 特别适合于从删除的表中恢复数据
  • Recovery Manager (RMAN) —— 在复制每个修改块前对它们进行检查
  • DB_BLOCK_CHECKSUM —— 该参数存储每个块头的校验和。但将该参数设为 true 会影响性能
  • LOG_BLOCK_CHECKSUM —— 让 ARCH 进程能够对归档日志文件求校验和。但将它设为 true 会影响性能
  • DBVerify —— 检查数据文件的完整性。可以发出命令 dbv file=c:\oracle\oradata\file1.dbf logfile=c:\temp\out.log
  • 不适用
  • 不适用
  • 不适用
  • 不适用
  • db2ckbkp —— 检查整个数据库映像的完整性。db2dart —— 检查数据库的体系结构正确性,并报告碰到的任何问题

恢复情形的场景

完全恢复

完全恢复是包括将数据库恢复到最近时间的前滚日志并且没有数据丢失的恢复。

Oracle 完全恢复

在 Oracle 世界中,有各种方式来完成完全恢复。通常该恢复是当数据库运行在 ARCHIVELOG 模式下和联机备份时取得的。完全恢复可以在数据库级或数据文件和表空间级上完成。在某些情形中,可能需要数据库级的恢复。要执行数据库级恢复,需要执行下面的操作:

  • 装入数据库。
  • 使所有数据文件联机。
  • 复制丢失的数据文件或整个数据库。
  • 应用重做(联机和归档的)。

有时您可能想执行数据文件和表空间级恢复。在这种情形中,必须完成下面工作:

  • 使数据文件或表空间脱机。
  • 复制要恢复的数据文件。
  • 执行前滚操作。

对于 Oracle,因为媒介失败的严重性和部署的备份策略,恢复到一致状态并且没有数据丢失有时是不可能的。比如下面的少数场景(不是很详尽):

  • 从丢失的多路复用控制文件成员中进行恢复。
    • 场景 1:磁盘和文件系统是完整的。
      • 关闭异常终止的控制文件。
      • 将好的控件文件复制到坏的控制文件的原始位置:- cp /path/blah_good.ctl /path/blah_bad.ctl。
    • 场景 2:磁盘和文件系统都不是很完整。
      • 关闭异常终止的控制文件。
      • 将好的控制文件复制到新的位置:- cp /path/blah_good.ctl /new_good_path/blah.ctl。
      • 更改 init.ora 中的 CONTROL_FILES 参数来反映好的新路径。
      • 启动该控制文件。
  • 从丢失的联机重做日志组的成员中进行恢复。
    • 不需要关闭异常终止的事务。
    • 要检查丢失的重做日志处于什么状态 —— Select * from v$logifle 显示哪个组及哪个成员是无效的。
    • 从步骤 1,您将拥有被破坏的成员的完全路径。删除该成员 —— Alter database drop logfile member 'fullpath/log_filename.log'。
    • 将新的成员添加到这个组 —— Alter database add logfile member '/fullpath/log_filename.log' reuse to group n;,其中 log_filename.log 和 group n 遵循步骤 1。
  • 从没有数据文件备份的情形中恢复。
    • 关闭异常终止的事务。
    • 装入数据库。
    • 获取丢失数据文件的路径和大小 —— select df.file#, df.status, df.enabled, df.create_bytes, df.name from v$recover_file rf, v$datafile df where rf.file#=df.file# and rf.error = "FILE NOT FILE"(注意丢失文件的路径和大小)。
    • 创建数据文件 —— alter database create datafile '/path/filename.dbf' as '/path/filename.dbf' size xxx reuse(确保路径和大小与步骤 4 相同)。
    • 如果文件是脱机的,使它处于联机状态 —— alter database datafile '/path/filename.dbf' online;。
    • 恢复数据库 —— recover database。
    • 打开数据库 —— alter database open。
  • 从属于只索引表空间的数据文件的丢失中进行恢复。
    • 恢复数据文件的完整副本。
    • 装入数据库 —— startup mount。
    • 恢复数据文件 —— recover datafile 'fullpath/filename'。
    • 将向您提示归档日志。请确认,直到收到“媒介恢复完成”为止。
  • 从属于临时表空间的数据文件丢失中恢复。
    • 让表空间处于脱机状态。
      • 在归档日志中 —— alter database datafile xxx offline immediate。
      • 在非归档日志中 —— alter database datafile xxx offline drop。
    • 删除表空间
      • 删除表空间 xxx。
    • 删除表空间的物理文件并重新创建这些文件。
  • 从属于只读表空间的数据文件的丢失中恢复。
    • 恢复属于 READ-ONLY 表空间的丢失数据文件其实是一项很简单的任务。由于 READ-ONLY 表空间从未被修改,所以只需将数据文件恢复至其原始位置即可。但如果自最后备份以后将只读更改为读写,或反之亦然,那您就必须恢复文件,并在其上进行媒介恢复。
      • 恢复数据文件 xxx。
      • 应用日志,直到看到“媒介恢复完成”为止。
  • 从不活动的重做日志组的丢失中恢复。
    • 要检查丢失的重做日志处于什么状态 —— a. select * from v$logfile 展示了哪个组是无效的。b. select * from v$log 展示了无效组的状态。
    • 既然您已经确认丢失的重做文件是 INACTIVE 重做日志,那么现在可以关闭数据库 —— shutdown immediate。
    • 装入数据库 —— Startup mount。
    • 由于重做日志组是不活动和归档的,所以只需清除重做日志即可 —— alter database clear logfile group N(其中 N 是丢失的重做日志的组 #)。
    • 打开数据库 —— Alter database open。
    • 检查状态 —— select * from v$log 展示了具有 UNUSED 属性的新的重做。
    • 执行完全备份(如果您想的话)。
  • 从属于系统表空间的数据文件的丢失中恢复。
    • 如果数据库仍在运行中,就关闭异常终止的数据库。
    • 将损坏或丢失的数据文件从备份位置复制到原始位置。
    • 装入数据库。
    • select v1.group#, member, sequence#, first_change# from v$log v1, v$logfile v2 where v1.group#=v2.group#;。
    • 通过下面命令恢复数据库:Recover datafile '/path/filename.dbf'。
    • 某些日志将被提示。请确认,直到看到“媒介恢复完成”为止。如果要求您输入不存在的归档日志,就输入重做组成员的完整路径,其中序列号正与某一提示日志的序列号匹配(从步骤 4),直到看到“媒介恢复完成”为止。
    • 打开数据库。
  • 从属于传统回滚段表空间的数据文件的丢失中恢复。
    • 未做任何修改地关闭数据库(将所有提交的数据写到磁盘)。
      • 注释出 init.ora 中的 ROLLBACK_SEGMENTS 项。
      • 严格装入数据库。
      • 脱机删除数据库数据文件 '/path/filename.dbf' 。
      • 打开数据库。
      • 删除表空间 tablespace_name,包括内容。
      • 用它的所有回滚段重新创建回滚表空间。段名称应该对应 init.ora 中的 ROLLBACK_SEGMENTS。
      • 立即关闭数据库。
      • 注释出 init.ora 中的 ROLLBACK_SEGMENTS。
      • 启动数据库。
      • select segment_name, status from dba_rollback_segs just,以确保所有的回滚段处于联机状态。
    • 数据库没有彻底关闭(在回滚段中有活动的事务)。
      • 使用操作系统的 cp 命令来从备份中恢复损坏/丢失的文件。
      • 装入数据库。
      • 检查数据文件的状态:select name, status from v$datafile;。如果它是 OFFLINE 的,就通过下面命令来使数据文件处于联机状态:Alter database datafile '/path/filename.dbf' ONLINE。
      • select v1.group#, member, sequence#, first_change# from v$log v1, v$logfile v2 where v1.group#=v2.group#;。
      • 恢复数据文件 '/path/fileame.dbf'。
      • 一些日志将被提示。请确认它,直到看到“媒介恢复完成”为止。如果要求您输入不存在的归档日志,就输入重做组的完整路径,其中序列号与某个提示日志的序列号相匹配(从步骤 4),直到看到“媒介恢复完成”为止。
      • 打开数据库。
    • 数据库启动并正在运行(较简单)
      • 创建少数附加回滚段来处理数据库活动。例如,Create tablespace rbstemp datafile '/path/rbstemp01.dbf' size 50M'。Create rollback segment xxx tablespace rbstemp。
      • 使丢失的数据文件处于脱机状态:Alter database datafile '/path/filename.dbf' offline。
      • 使用操作系统拷贝功能从备份中恢复丢失的数据文件。
      • select v1.group#, member, sequence#, first_change# from v$log v1, v$logfile v2 where v1.group#=v2.group#;。
      • 恢复数据文件 '/path/filename.dbf'。
      • 一些日志将被提示。请确认它,直到看到“媒介恢复完成”为止。如果要求您输入不存在的归档日志,请输入重做组的成员的完整路径,其中序列号与某个提示日志的序列号相匹配(从步骤 4),直到看到“媒介恢复完成”为止。
      • 使数据文件处于联机状态:Alter database datafile '/path/filename.dbf' online。

如果您正在使用传统的 ALTER TABLESPACE…BACKUP BEGIN,那么必须根据一种情形和另一种情形的不同,来区别对待上面情形中的恢复。好的计划方法是防止出现上面提及的所有类型的丢失。但自 Oracle 8i 以来,Oracle 建议使用 Recovery Manager(RMAN)执行联机备份。RMAN 有一些优点,比如:

  • 增量备份。
  • 不会发生包含传统备份的重做膨胀(redo inflation)。
  • 对数据进行完整性检查,以避免数据损坏。
  • 允许并行备份。
  • 自动化备份和恢复过程。

DB2 完全恢复

下面是一些在不丢失数据的情况下的恢复类型:

  • 用好的备份映像联机恢复数据库。前滚至日志的结束,然后完成备份。注意,这包括了各种媒介失败,容器被损坏等。请参阅上面的步骤来执行数据库级恢复。
  • 用好的备份映像联机恢复表空间。前滚到日志的结束,然后完成备份。注意,这包括了各种媒介失败,容器被损坏等。请参阅上面的步骤来执行表空间级恢复。
  • 意外删除表。要恢复被删除的表,需要执行下面一些操作:
    • 您必须将 DROP_RECOVERY 选项设置为 Y,来为表空间启用被删除表的恢复支持。发出下面的命令来检查是否为表空间启用了对被删除表的恢复支持,如果没有启用,就打开它。
      • db2 select tbspace, drop_recovery from syscat.tablespaces。
      • db2 alter tablespace userspace1 dropped table recovery on。
    • 确保 LOGRETAIN 被设为 ON,如果不是,请发出下面命令:
      • db2 update db cfg using logretain on(您需要断开所有应用程序的连接以使该命令生效)。
    • 执行完全脱机备份。
      • db2 backup database sample to e:\tmp。

    如果在某个时间点,您发现一张表被一位业余的 DBA(或者更加准确地说是一位 DBA 新手)意外删除了。要恢复该表,请执行下面的操作:

    • 通过发出命令来列出被删除表的历史。您将注意到少数的几件事;备份 ID(比如 000000000000bb000002000d),表删除操作的开始和结束时间(比如 20040705150008)及被删除表的 DDL。在一些后续步骤中,您需要用到被删除表备份 ID 和 DDL。
      • db2 list history dropped table all for sample
    • 在没有前滚操作的情况下,使用备份映像来恢复表空间。
      • db2 restore database sample tablespace (userspace1) from e:\tmp taken at 2004070515 without rolling forward
    • 使用完全恢复将被删除表前滚至 e:\tmp。您将看到 ROLLFORWARD 命令成功完成的提示。
      • db2 rollforward database sample to end of logs and complete recover dropped table 000000000000bb000002000d to e:\tmp
    • 现在,在被删除表的 DDL 语句清单中创建被删除的表。
    • 导入被导出的数据,例如:
      • db2 import from d:\tmp\node0000\data of del method p (1,2,3,4,5,6,7,8,9,10,11,12,13,14) messages d:\tmp\imp.loog insert into employee(empno, firstnme, midinit, lastname, workdept, phoneno, hiredate, job, edlevel, sex, birthdate, salary, bonus, comm)

不完全恢复

不完全恢复是这样的一种恢复,该恢复包括前滚重做日志,以便数据库恢复到某个时间戳,该前滚操作允许您丢失一些数据。顾名思义,这是部分恢复。

Oracle 不完全恢复

在 Oracle 世界中,不完全恢复通常是由下面情况引起的:

  • 表的丢失。
  • 在对联机重做日志进行归档之前,这些日志丢失了。
  • 防止出现超越某一时间点前滚的归档重做日志的丢失。
  • 没有备份的控制文件的丢失。

完全恢复和不完全恢复的基本区别在于:由于上面列出的各种原因,不完全恢复不能超越某个时间戳继续前滚。不完全恢复将要求通过发出 Alter Database Open Resetlogs 命令来重新设置日志。与完全备份不一样,您必须恢复所有数据文件,而不只是要恢复选定的数据文件。当执行不完全恢复时,您必须确保数据文件处于联机状态。

  • 基于更改的恢复。基于更改的恢复是恢复到指定 SCN 的恢复。比如恢复数据库直到更改 87643。
  • 基于时间的恢复。基于时间的恢复是恢复到指定 SCN 的恢复。比如恢复数据库直到时间“2004-06-05:15:20:00”。
  • 基于 cancel 的恢复。基于 cancel 的恢复是恢复到用户键入 cancel 的恢复。比如恢复数据库直到 cancel。在这一时间点上,前滚将继续,直到用户决定通过键入 cancel 来停止前滚。
  • 基于日志序列的恢复是恢复直到指定日志序列号(只有在使用 Recovery Manager时才可用)的恢复。

注意,不完全恢复会一直前滚,直到所有事务都丢失。这是不完全恢复的性质。通常,在执行不完全恢复后,有必要立即执行脱机备份。alter database open resetlogs 之后,所有重做日志都将表现为无用,所以它不适合于恢复。resetlogs 只表明重新设置了重做日志的序列号。

尽管在“恢复情形的场景”中后面没有一个详尽介绍的场景,我们还是看到了一些不完全恢复情形的场景。本文的目的不是用来解决如何从由于媒介失败而引起的每个单一故障中恢复。

下面是一些可能在 Oracle 中引起不完全恢复的示例场景:

  • 从未归档联机日志文件的丢失中恢复。
    • 要检查丢失的重做日志处于什么状态 —— a. select * from v$logfile 展示了哪一组是无效的;b. select * from v$log shows 展示了无效组的归档状态。
    • 既然您确认丢失的重做文件是未归档重做日志(archived=NO),那么现在就可以关闭数据库 —— shutdown immediate。
    • 从备份中恢复所有数据文件。
    • 装入数据库 —— Startup mount。
    • 如果媒介被损坏了,不能在媒介上写入默认文件系统,就将文件移动到其他位置 —— a. 在操作系统中,查找存放新文件的目录,并移动文件(相同文件名);b. alter database rename file '/oldpath/filename.log' to '/newpath/filename.log'。
    • 执行基于 cancel 的不完全恢复 —— a. recover database until cancel;b. 按回车,直到看到 ora-00308 和 ora-27037 为止;c. 重新运行 recover database until cancel,但这次在提示中键入 CANCEL。
    • 打开数据库并重新设置日志 —— alter database open resetlogs(注意,使用 resetlogs 打开后将创建联机日志文件)。
    • 执行整个数据库的用户管理备份。
  • 从惟一活动重做日志组的丢失中恢复。
    • 要检查丢失的重做日志处于什么状态 —— a. select * from v$logfile 展示了哪个组是无效的。b. select * from v$log 展示了无效组状态。
    • 既然您确认丢失的重做文件是 ACTIVE 重做日志,那么现在就可以关闭数据库 —— shutdown immediate。
    • 恢复备份。
    • 装入数据库 —— Startup mount。
    • 如果媒介被损坏了,不能在媒介上写入默认的文件系统,那么就将文件移动到其他位置 —— a. 在操作系统中,查找存放新文件的目录,并移动文件(相同文件名)。b. alter database rename file '/oldpath/filename.log' to '/newpath/filename.log'。如果原始文件系统是好的,就跳过这个步骤。
    • 执行基于 cancel 的不完全恢复 —— a. recover database until cancel。b. 按回车,直到看到 ora-00308 和 ora-27037 为止。c. 重新运行 recover database until cancel,但这次在提示中键入 CANCEL。
    • 打开数据库并重新设置日志 —— alter database open resetlogs。
    • 执行整个数据库的用户管理备份。
  • 从当前重做日志组的丢失中恢复。
    • 要检查丢失的重做日志处于什么状态 —— a. select * from v$logfile 展示了哪个组是无效的。b. select * from v$log 展示了无效组的状态。
    • 既然您确认丢失的重做文件是 CURRENT 重做日志,那么现在就可以关闭数据库 —— shutdown immediate。
    • 恢复备份。
    • 装入数据库 —— Startup mount。
    • 如果媒介被损坏了,不能在媒介上写入默认文件系统,那么就将文件移动到其他位置 —— a. 在操作系统中,查找存放新文件的目录,并移动文件(相同文件名)。b. alter database rename file '/oldpath/filename.log' to '/newpath/filename.log'。如果原始文件系统是好的,就跳过这个步骤。
    • 执行基于 cancel 的不完全恢复 —— a. recover database until cancel。b. 按回车,直到看到 ora-00308 和 ora-27037 为止。c. 重新运行 recover database until cancel,但这次在提示中键入 CANCEL。
    • 打开数据库并重新设置日志 —— alter database open resetlogs。
    • 执行整个数据库的用户管理备份。

DB2 不完全恢复

在 DB2 中,不完全恢复可能由下面情况引起:

  • 活动日志的丢失。这可能是最坏的情形场景。因此强制使用数据库配置参数 MIRRORLOGPATH 来镜像活动日志。
    • 寻求 IBM 支持的帮助。
  • 归档日志的丢失。在这种场景中,您只能前滚到某个时间点,前滚到上次完好归档的日志文件,例如:
    • db2 rollforward db sample to 2004-06-28-10.30.50.000000。

结束语

对于必须最小化数据丢失(如果不能完全避免的话)的任何业务环境,备份和恢复是最基本的操作。Oracle 和 DB2 UDB 都有一些备份和恢复小型数据库和大型数据库的机制。对于小型数据库和中型数据库,Oracle 提供了脱机和常规联机备份(使用 Alter Tablespace …Backup Begin 命令)。DB2 UDB 也提供了脱机和联机备份。对于脱机备份,需要排它地进行备份,联机备份则允许用户在备份过程中连接数据库。表空间或数据库的恢复可以通过恢复备份映像和前滚来完成。两种数据库都提供了前滚到某个时间点以及前滚到日志的结束的恢复。

在处理像数据仓库环境中数据库那样的巨型数据库方面,Oracle 和 DB2 都提供了增量和差异备份,避免复制未更改的数据页。要使用增量备份或自动化联机备份,Oracle 建议使用 Recovery Manager。

Oracle 和 DB2 UDB 都提供了一些有效的机制和功能,来保护数据不会由于媒介损坏或人为错误而丢失。使用本文提供的信息,您应该发现从 Oracle 技能转向 DB2 UDB 环境是容易的。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=20184
ArticleTitle=IBM DB2 UDB 与 Oracle 的备份和恢复
publish-date=09012004