【IT168 技术文章】

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

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

• 语句失败
  

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

  在 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 中，这些失败的处理方式大致是一样的，都是通过脱机或联机备份并使用前滚操作恢复日志来完成的。

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