恢复场景

　　您永远也无法知道您的系统何时会碰到灾难或故障。因此最好早作准备，不但要防止数据受到外部因素的影响，也要防止内部用户无意中用不正确的信息破坏您的数据库。

　　您有备份您的数据库吗?您能够恢复执行到最后一秒的所有事务吗?

　　为了尽量减少丢失的数据，需要有一个恢复策略，确保这个恢复策略可行，并不断地加以演练。您应该考虑以下一些恢复场景：

系统运行中断

　　停电，硬件故障，或者能导致数据库处于不一致状态的软件故障。

事务失败

　　用户可能无意中用不正确的数据修改您的数据库。

媒介故障

　　如果您的磁盘驱动器变得无法使用，那么可能会丢失所有或部分数据。

灾难

　　放置系统的设施遭到火灾、洪水或其他类似灾难的毁坏。

恢复策略

　　为了制定恢复策略，应该问一问自己下面这些问题：

• 　　您的数据可以从另一个地方装载吗?
• 　　您能承受多少数据的丢失?
• 　　您需要花多少时间才能恢复数据库?
• 　　您有什么可用的资源来存储备份和日志文件?

事务

　　一个工作单元(UOW)，也称一个事务，由一条或多条 SQL 语句组成，最后是一条 COMMIT 或 ROLLBACK 语句。这个 UOW 中的所有语句被看作一个单元，以确保数据的一致性。例如，一个客户试图将 100 美元从一个储蓄帐户转到一个支票帐户。在这种情况下，UOW 是这样的：

　　DELETE 100 dollars from SAVINGS account

　　INSERT 100 dollars to CHECKING account

　　COMMIT

　　如果这些语句没有被当作一个单元，那么可以想像一下，如果在 DELETE 之后、INSERT 语句之前出现硬件故障，会出现什么情况：这个客户将丢失 100 美元。但是，如果将这些语句当作一个单元，就不会发生这样的事情。DB2 将知道这个单元没有完成(COMMIT)，因此它将回滚之前的语句作出的所有更改，并将受影响的行返回到事务开始之前的状态。

　　没有语句用于标识一个事务的开始。COMMIT 或 ROLLBACK 之后的语句将开始一个新的事务。

恢复的类型

　　我们来熟悉一下恢复类型方面的概念。DB2 允许以下类型的恢复：

紧急事故恢复

　　通过撤销(回滚)未提交的事务，使处于不一致状态的数据库恢复到一致状态。再次考虑前一屏中的例子。如果在 COMMIT 语句之前出现停电事故，则下一次 DB2 重新启动并访问数据库时，DB2 将首先回滚 INSERT 语句，然后回滚 DELETE 语句。(回滚的语句的顺序与这些语句当初执行的顺序相反。)

版本恢复

　　允许使用从 BACKUP 命令获得的一个备份镜像恢复前一个版本的数据库。被恢复的数据库将包含关于当执行 BACKUP 命令时该数据库所处状态的信息。如果在备份之后又执行了新的活动，则该信息将丢失。

前滚恢复

　　这种恢复结合使用完整的数据库备份和日志文件，从而扩展了版本恢复。在使用一个备份作为基准之前，必须首先存储这个备份，然后在该备份上应用日志。这个过程允许将数据库或表空间恢复到某个特定的时间点上。前滚恢复要求启用归档日志记录 。在 日志记录类型 中对归档日志记录作了讨论。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。