崩溃恢复的基石

核心提示： 因为多个事务可以在任何时候使用一个数据库，所以一个日志文件可能包含属于几个不同事务的日志记录，崩溃恢复的基石(3)，为了追踪哪一条日志记录属于哪个事务，要给每条日志记录分配一个特殊的事务 ID，该命令的基本语法是：RESTART [DATABASE | DB][DatabaseName]U

因为多个事务可以在任何时候使用一个数据库，所以一个日志文件可能包含属于几个不同事务的日志记录。为了追踪哪一条日志记录属于哪个事务，要给每条日志记录分配一个特殊的事务 ID，将之绑定到创建它的事务。通过使用事务 ID，可以随时将与特定事务相关联的日志记录写入一个或多个日志文件，而不影响数据一致性 — 最终，对于终止该事务的操作的 COMMIT 或 ROLLBACK 记录也将进行日志记录。

崩溃恢复

在还未提交事务的修改之前，如果发生问题 — 例如，发生停电或应用程序异常终止 — 会发生什么事情呢？事务所做的任何未提交或已回滚的工作都将丢失。此外，如果正在将其数据具体化（externalize）到数据库的已提交事务遭到破坏，该数据库将处于不一致、不可用的状态。（每当尝试建立连接时，不一致的数据库将生成返回代码和错误消息。）您无法恢复内存中所存储的事务记录，但是可以通过执行名为崩溃恢复的操作，将不一致的数据库恢复为一致、可用的状态。

启动崩溃恢复的最常用方法就是从 DB2 命令行处理器（DB2 Command Line Processor，CLP）执行 RESTART 命令。该命令的基本语法是：

RESTART [DATABASE | DB]
[DatabaseName]
USER [UserName] < USING
[Password] > >
< DROP PENDING TABLESPACES
( [TS_Name] , ... ) >
< WRITE RESUME >

其中：

DatabaseName 指示分配给尝试进行恢复的数据库的名称。

UserName 指示分配给用户的名称，崩溃恢复将在该用户的权限下执行。