数据库灾难性恢复

数据库灾难性恢复

1 数据库的选型

1.1 基本原则

选择什么样的数据库是否可以从几个方面考虑：

1)企业根据自身规模和要求选择适当规模的数据库；

2)产品数据所要求的安全性；

3)数据库本身的处理冗余度的能力 ；

4)能处理多种格式的数据文件（企业内部流动的）。

 

1.2 数据库以及数据库服务器的选型

数据库服务器上的存放着大量关键的信息和数据。而且，一旦数据库系统发生异常错误或导致数据的丢失，其损失将是灾难性的。

数据库系统的衡量标准通常有两个：一个是整个数据库系统的运行性能，包括了一些典型操作的响应时间，以及在系统负载比较大的情况下，系统依然要有合理的运行表现；第二个是数据库系统的稳定性，即数据库系统能够稳定持续运行的时间，要求能够达到5×24。

基于服务器硬件的高可用性基于服务器硬件的高可用性通常包括两个核心部分：一、运行性能，即在突然增加的负载下，如增加交易容量和用户数量，系统依然有合理的运行表现；二、容错性能，就是防止系统崩溃，如果任何部件出现失效，系统都不会损失关键数据且易于恢复正常，而对最终用户的服务不会出现明显的中断。

由此，硬件系统的可靠性、稳定性、科学有效的维护是提高系统可用性指标的关键因素；对于避免人为误操作及防范病毒，除采用必要的技术手段外，更要建立一整套严格的计算机系统管理规程，防范于未然；对于系统的容灾，选取恰当的冗余备份措施，如服务器的冗余、交换机等网络链路的冗余等。而在服务器和磁盘阵列上，采用RAID系统来存储重要的数据库数据和应用服务器系统的其它数据，如采用高性能的RAID-5实现数据冗余，并且保证系统的吞吐能力，提升整体性能；此外，多项冗余技术，如冗余双电源、冗余I/O数据通道、冗余总线，支持热插拔、ECC内存及缓存等都将作为服务器选型的基本技术依据。

所以采用的要求数据库集群方案既充分考虑系统的性能，又提供最可靠的运行环境。同时要做到资源的充分利用；另外，当其中的某一台服务器由于发生错误，包括软件和硬件错误，导致无法继续提供服务时，所有的应用将被自动转移到另一台可用的服务器所上，这就充分保证了整个数据库系统的高可用性。同时，整个数据库集群系统的规模可以根据用户的需求来设计或改变。

2高可用性解决方案

2.1 涉及到的三个方面

当设计 HA 解决方案时，应该考虑所有这三个方面：用户应用程序、客户机软件、数据库引擎。

数据库应用程序是基于客户机／服务器的。应用程序依靠数据库软件的完整性来产生一致的结果。虽然这看起来似乎相当明显，但当选择和设计解决方案时理解如何实现这一点非常重要。

当应用程序提交 SQL 事务时，在可以假设事务完成之前它必须接收返回码。应用程序并不与数据库引擎直接交互。事务经由客户机软件传递到引擎。由客户机软件将响应返回给应用程序。正的返回码表示成功的情况，而负的返回码表示失败。应用程序如何处理这些情况对于整体 HA 解决方案很重要。通过包含返回码逻辑，尤其是关于事务失败的，应用程序可以使 HA 解决方案对于最终用户显得更加天衣无缝。

数据库引擎通过实现事务日志来确保完整性，事务日志存储了所有插入、更新和删除活动。事务日志确保了数据库更改只在应用程序发出提交语句后接收到正的返回码时才算完成。事务日志是 HA 和 DR 解决方案的基础部分。

在可以提交 SQL 事务之前，必须建立到数据库的连接。CONNECT 语句用于建立数据库连接，但有一些基本特性会影响连接被路由到哪里。客户机软件有两个目录告诉它如何路由数据库连接尝试：

节点目录（node directory）列出了服务器的位置（服务器的 IP 地址或主机名）和数据库服务器用于侦听数据库连接尝试的端口。

数据库目录（database directory）列出了数据库名称、数据库别名和节点目录中用于建立连接的对应项。

当应用程序发出 CONNECT 语句时，会搜索数据库目录来查看是否存在这个数据库名或数据库别名。如果这一项的类型是“indirect”，那么数据库是本地的，并通过共享存储段建立该连接。如果这一项的类型是“remote”，那么节点名用于指向节点目录中的正确项。节点目录信息允许客户机软件正确路由连接尝试。通过了解客户机如何通过目录结构建立数据库连接，在您规划 HA 解决方案时就可以规划资源移动。

2.2 高可用性的两种类型

选择高可用性解决方案很大程度上取决于客户的业务需求。有两种类型的高可用性可供选择： 持续可用性（continuous availability）和 故障转移可用性（failover availability）。

2.2.1 持续可用性

持续可用性要求数据库引擎可随时用于处理 SQL 事务。这类可用性通常只在最关键的应用程序中实现。要实现这个目标，要求百分之百的冗余。那意味着您必须有两个完全互相独立（包括在硬件和软件方面）的系统。

基本上，SQL 事务在这两个系统上发生。一个系统发生故障不会造成其伙伴系统上事务的处理发生中断。要使这成为现实，应用程序必须知道这两个系统，并且将每个事务实现为跨两个系统的分布式工作单元（distributed unit of work，DUOW）。DUOW 是作为在系统之间协调的一个事务而执行的一系列 SQL 语句。应用程序将事务提交给这两个系统，并从这两个系统接收关于成功或失败的返回码。然后应用程序可以继续处理另一个 DUOW 或执行另一种操作。如果发生故障，其中一个数据库系统不能再为应用程序提供服务，则应用程序（被编码为可以捕获该错误）可以利用另一个系统继续处理它的工作负载，而不会发生中断。

要实现 DUOW 需要类型 2 数据库连接和事务监视器。类型 2 数据库连接建立了适合于 DUOW 的环境。事务监视器负责实现 DUOW 并确保完成或回滚 DUOW 中的事务。DB2 可以充当事务监视器或者您可以使用另一家软件供应商（如 Microsoft 或 BEA）的事务监视器。

图 1说明了通过使用 DUOW 提供的持续可用性解决方案。

图 1. 分布式工作单元

表 1. 持续可用性解决方案的优缺点

优点：	缺点：
100％ 正常运行时间	需要重复的硬件
	需要额外的应用程序编码

2.2.2 故障转移可用性

故障转移可用性与持续可用性的区别在于：数据库引擎会有一段时间（尽管时间很短暂）无法用于事务处理。这种解决方案的基本元素有：

l         主系统和辅助系统

l         故障检测

l         数据源移动

两个系统都有数据库数据的副本，当检测到故障时，就会发生故障转移。在故障转移过程中，数据源从主系统移到辅助系统。

有两种故障转移可用性： 同步（synchronous）和 异步（asynchronous）。同步可用性保证了主系统和辅助系统上的数据源是一致的，而且在故障转移之后维持完整的连续性。异步可用性不保证主系统和辅助系统数据库是完全同步的。将数据库更改从主系统移到辅助系统的方法会不同，但这个过程会生成一个时间窗口，在这段时间内数据还没有从一个系统迁移到另一个系统。数据量也许会非常小，时间窗口可能会非常短，但是我们在决定解决方案时必须要考虑这一点。

下面就是两四个同步或异步故障转移可用性的选项。

 

1）专用的 HA 软件选项

同步方法涉及数据库软件与专用 HA 软件的紧密集成以产生 HA 群集。HA 软件支持由于操作系统平台的不同而不同。常用的 HA 解决方案有：

l         High Availability Cluster Multiprocessing（HACMP — AIX）

l         Microsoft Cluster Server（MSCS）— Windows

l         Sun Cluster — Sun

l        Steeleye 的 Lifekeeper — Linux 和 Windows

这些列出的都是针对各平台的最常见选项。还有其它一些 HA 软件解决方案，也可以使用它们。

所有这些解决方案的工作方式基本相同。如果有故障，数据库服务器可以从一台机器移到备份系统上。要完成该任务，HA 软件会将所有必需的资源移到辅助系统。这些资源包括物理数据库的磁盘资源、网络资源和数据库服务器资源。

在 HA 群集解决方案中，单个物理数据库副本存储在共享存储系统上。在 DB2 环境中，一次只能有一个系统“拥有”存储器阵列。当检测到故障时，存储器的所有权就会从主系统转移到辅助系统。同时也会转移网络资源。最后，在辅助系统上启动数据库服务器资源，使数据库变为可用。

故障的检测由服务器之间的“心跳”连接执行。这个“心跳”是 HA 软件的一个功能，它可以察觉硬件和软件故障。

由于只有一个数据库的副本，所以它始终是同步的。数据库引擎的故障转移和重新启动的时间取决于以下因素：

l         检测故障所需的时间

l         移动数据库资源相关资源（存储阵列和联网资源等）所必需的时间长度

l        DB2 引擎执行崩溃恢复所需的时间

当数据库没有正确关闭时，DB2 总是会执行崩溃恢复。崩溃恢复是日志文件的处理，从而确保将所有已提交的事务都写到磁盘并且回滚未提交的事务。执行该操作所需的时间取决于发生故障时数据库日志中“打开”工作的量。整个故障转移可能只需要几秒钟，如果要从日志文件中处理的工作量很大，可能会需要更长时间。

这种可用性解决方案的一个优点是它不需要对应用程序或客户机配置目录做任何更改。HA 软件为数据库连接提供了一个虚拟的 IP 地址资源。当检测到故障时，该 IP 地址就会进行故障转移，应用程序可以使用它以前使用的同一条连接语句。发生故障转移时，所有应用程序都会断开连接，客户机会将通信错误情况返回给应用程序。一旦数据库服务器在辅助系统上运行之后，应用程序只要重新发出连接语句，就可以象以前一样继续处理工作了。

这也称作 热备用（hot standby）配置。但是，在等待故障转移时，辅助系统并不一直空闲。也可以以 相互接管（mutual takeover）配置来配置系统，在该配置中，这两个服务器都主动地主管不同的数据库。每台机器都准备在发生故障时接管其伙伴的工作负载。

图 2. 专用的 HA 软件选项

表 2. 专用 HA 软件选项的优缺点

优点：	缺点：
数据库始终是同步的	需要额外的软件来创建和配置解决方案
不需要更改应用程序或客户机	没有复制数据，因此提供较少的冗余
不需要用户交互来检测和初始化故障转移	需要必须符合一些 HA 标准的外部存储器
性能不受额外工作负载的干扰	由于硬件需求，限制了服务器之间的距离

2）数据复制选项

DB2 UDB 包含了集成复制能力。DB2 的复制实现包括两部分： Capture（捕获）和 Apply（应用）。复制管理员指定表中要复制的复制源，然后通过使用前一步中的复制源作为其来源，在目标数据库（辅助系统）上创建复制预订。Capture 进程监控事务日志以获取对复制源表的所有更改，然后将对这些表的任何更改放到登台表中。Apply 程序定期读取登台表并将更改转移到预订目标。

数据复制是一个异步过程。在已更改的数据还没有放到登台表中或者 Apply 程序还没有将更改复制到目标系统期间，这两个数据库不是同步的。这不一定是一段很长的时间或很大的数据量，但必须考虑这一可能性。

复制有几个好的特性。它允许：如果不需要整个副本，可以只复制数据的子集。只要有足够的网络带宽满足用户的需要，距离就不是问题。复制还允许在使用 IBM 的 Information Integrator 产品的情况下，可以在一个独立的平台或不同的数据库管理系统上托管辅助系统。这两个系统都是“活动的”，因此可以完成独立的工作。例如，一个系统可以用于处理事务，而辅助系统可以用于创建报告或运行备份。

复制只捕获对源表的更改。它不会捕获对系统目录的更改。例如，必须在两个系统上都执行对表许可权的更改，因为复制无法复制这项更改。

此外，故障转移过程不是自动的。发生故障后，系统管理员必须在客户机上进行更改，这样他们才可以针对辅助系统工作；或者在辅助系统上做更改，使它可以模拟主系统。这将允许应用程序按以前那样继续工作，而不必更改应用程序编码。一个替代方法是使用诸如 IBM 的 Edge Server 之类的产品来管理服务器连接。如果应用程序是用户应用程序，那么用户只要连接到辅助数据库，而不必对客户机配置或数据库服务器做任何实际的更改。

运行复制有一些开销。额外的工作量取决于对源表的插入、更新和删除活动的量。不需要对基本表进行额外的锁定，因为复制只分析日志文件，而不会分析基本表。但登台表（更改表）的填充和这些事务的日志记录需要数据库资源。

图 3说明了用于高可用性的复制选项。

图 3. 复制

表 3. 复制解决方案的优缺点

优点：	缺点：
集成能力，不需要额外的软件	过程是异步的，可能会因故障而丢失数据
在两个地方复制数据，冗余更大	不会自动进行故障转移，需要手工处理（或使用 Websphere Edge Server）
灵活的体系结构	不能复制所有数据库更改
距离限制较少	主系统上有额外的工作负载
辅助系统可以执行第二份工作负载

 

3）日志传送选项

所有数据库更改（插入、更新或删除）都记录在 DB2 事务日志中。事务日志主要用于崩溃恢复和在故障之后恢复系统。正如我们已经讨论的，它们在复制中发挥作用。此外，它们还可用于另一个高可用性解决方案日志传送（log shipping）。该 HA 方案类似于数据复制选项。它要求辅助系统准备好在主系统发生故障时进行接管。管理员通过恢复主系统数据库的备份来创建这个辅助系统。通过恢复主系统的数据库备份，备份系统将处于前滚暂挂状态。事务日志从主系统转移到辅助系统，并用于使数据库前滚以完成事务。如果发生故障，管理员应停止前滚过程，并且使数据库联机。

可以用几种方式完成转移日志文件的过程。主要方法是使用 DB2 的 用户出口（user exit）工具。用户出口是当事务日志已满并准备归档时调用的可执行应用程序。数据库引擎将日志文件传递给用户出口，用户出口逻辑将执行所有必需的工作。用户出口可以制作日志的副本、将它发送到磁带设备、调用另一个程序或执行它被编码来处理的任何例程。一个可能的选项是将日志文件复制到辅助系统可以读取日志并应用日志中包含的事务的位置。

与复制选项相同，日志传送是一个异步过程。只要主系统上有活动日志文件并且还有未应用且未完成的日志文件，辅助系统就处于不同步状态。

DB2 确实有执行双日志记录的能力。这允许数据库在不同卷上创建复制日志文件，从而增加冗余。此外，该方法不会在数据库服务器上产生额外的开销。与使用复制不同，该方法不会创建两个活动的系统，因为备份系统在被管理员停止前滚暂挂状态之前一直处于不可用状态。

图 4说明了日志传送过程。

图 4. 日志传送

表 4. 日志传送的优缺点

优点：	缺点：
集成能力，不需要额外的软件	过程是异步的，可能会因故障而丢失数据
在两个地方复制数据，冗余更大	不会自动进行故障转移，需要手工处理
距离限制较少	辅助系统是被动的，只提供备份能力
活动系统上没有额外工作负载

4）高级存储选项

现代的存储子系统提供了许多高级特性。DB2 已经能够利用这些高级特性来创建高可用性和灾难恢复系统。虽然这些技术可能会不同，但高级存储选项的基本要素就是能够快速创建磁盘卷的相同副本。然后可以将这些卷安装到辅助系统上。辅助系统可以充当备份系统或执行其它一些类型的工作负载。允许实现这一功能的 DB2 特性叫作 暂挂 I/O（suspended I/O）。

暂挂 I/O 这项技术允许数据库引擎使数据库处于一致状态，同时又保持联机。暂挂 I/O 状态暂挂写 I/O 操作，以防止对数据表空间和日志的写操作。在数据库离开暂挂 I/O 状态之前，该数据库仍可用于所有应用程序，处理只读语句和延迟写语句（插入、更新和删除）。通过 SET WRITE SUSPEND 命令将数据库置为暂挂状态。暂挂数据库之后，就可以制作数据库的物理文件的副本。将需要数据库目录、日志文件和数据库容器的副本。存储硬件和软件通过分割镜像卷或其它高级复制技术，可以非常快地创建大量数据的副本。然后，所复制的卷可以用于创建备份系统。制作了副本之后，可以使用 SET WRITE RESUME 命令来继续处理主系统上的所有事务。

所复制的卷可以与 DB2INIDB 实用程序一起用来创建辅助系统。该实用程序有三个实现：SNAPSHOT、STANDBY 和 MIRROR：

l         SNAPSHOT 实现只允许数据库执行崩溃恢复。创建了一个复制的数据库，但在恢复期间不回滚任何事务。该方法适用于创建测试环境或报告机器。它不提供用于数据库恢复的方法，因此不应用作 HA 选项。

l         STANDBY 和 MIRROR 方法允许创建恢复实现。在这两种情况下，DB2INIDB 工具使数据库处于前滚暂挂状态。然后可以将主系统中的日志文件应用到备份系统。如果主系统发生故障，那么辅助系统将离开前滚暂挂状态并联机，准备处理事务。用 STANDBY 还是用 MIRROR 方法取决于如何应用日志以及如何使数据库恢复联机。

l         STANDBY 方法使数据库在独立于主系统的位置恢复联机，并允许在主系统处于暂挂状态时，在辅助系统上进行数据库备份。

l         MIRROR 方法用所复制的卷替换原来的卷，而处理将在相同的位置中发生。

如我在日志传送部分所提到的，DB2 能够生成双日志。通过将日志放在不同的卷上，该能力可以与高级存储选项一起使用来确保日志的完整性。DB2 用户出口程序可以用于存储和检索日志文件，并管理已归档日志文件的位置。可以对用户出口进行编码，以将日志放到辅助系统或另一个可用位置上。

图 5显示了高级存储选项。

图 5. 高级存储

表 5. 高级存储的优缺点

优点：	缺点：
集成能力，不需要额外的软件	过程是异步的，可能会因故障而丢失数据（这可以用双日志记录来弥补）
在两个地方复制数据，冗余更大	不会自动进行故障转移，需要手工处理
能够迅速地复制大量数据	辅助系统处于前滚暂挂状态，不可用
捕获所有数据库更改	需要高级硬件

3灾难及其恢复的基本类型

3.1 灾难类型

为了使数据库损失降低到最小程度，需要一个恢复策略，确保它起作用，并经常实行策略，一些灾难类型包括：

l         系统故障。电源故障、硬件故障或软件故障都能够使数据库处于不一致状态。

l         事务故障。用户无意中会用错误数据修改数据库，从而毁坏数据库。

l         介质故障。如果磁盘驱动器变得不能使用，那么可能会丢失所有或部分数据。

l         灾难。系统所在的设施可能会遭受火灾、洪水或其它类似灾难的损坏。

3.2 恢复类型

DB2 考虑到了下列恢复类型：

l         崩溃恢复。这种类型的恢复通过撤销（回滚）未提交的事务来防止数据库处于不一致状态。

l         版本恢复。这种类型的恢复通过使用从 BACKUP 命令获取的备份映像来恢复先前的数据库版本。恢复的数据库将包含在执行 BACKUP 命令时所处状态的信息。如果在执行备份之后针对数据库执行进一步操作，那么该信息将丢失。

l         前滚恢复。这种类型的恢复通过使用完全数据库备份，结合日志文件来扩展版本恢复。必须先恢复备份以用作基线；然后在该备份之上应用日志。该过程会将数据库或表空间恢复到某个特定时间点。前滚恢复要求启用归档日志记录。

3.3  恢复的级别

建立灾难恢复计划对于现代企业至关重要。企业数据库中的信息对于进行业务活动是极其重要的。保护该数据以及在灾难之后确保其“生命”是很重要的活动。当构建 DR 计划时，有三个关键级别问题。

3.3.1 需要防止的故障级别

要防止的故障级别通常是近似性问题。原始数据与其备份之间在物理上有多紧密？备份数据可以在不同的驱动器上、在独立的机器上、在独立的楼层上或在不同的建筑物里。不可能预测所有可能的灾难。火灾、水灾或甚至用户的恶作剧都可能是企业必须面对的问题。解决方案的设计应该包括公司希望防止最坏情况的方案。

3.3.2 可接受的数据丢失量

所有企业都不希望在故障之后丢失任何数据。虽然不丢失数据是可能的，但由于可能需要的复杂性和费用（尤其是如果所防止的故障级别非常高），这通常是不实际的。可接受的数据丢失量取决于数据对公司有多重要以及有什么资源可用于确保其生命。

3.3.3 允许用于恢复的时间量

恢复所需的时间量类似于高可用性的目标。它与高可用性解决方案之间的差异在于所防止的故障类型以及通常认为合理的时间长度。HA 故障转移通常以秒和分钟来衡量，而灾难恢复则可能以小时和天来进行衡量。不过并非总是这样，但这个差异区分了对这些解决方案的相对期望。

3.4 备份和恢复

数据库备份创建了数据库的时间点映象，它是灾难恢复解决方案的基本组件。DB2 提供了几种备份，包括脱机备份、联机备份和增量备份。从备份恢复所需的时间取决于数据库的大小和可用于执行恢复的硬件资源。

由于数据库备份只捕获时间点的数据，因此无法通过一个简单恢复来恢复备份之后发生的任何数据更改。要恢复备份之后完成的事务，就需要应用日志文件。可以从备份和日志文件（通过在日志文件中进行“前滚”来应用）来恢复数据库。这允许恢复到某个时间点或恢复到日志文件结束。

因此，如果 DR 解决方案必须恢复自上次备份以来的事务，那么保留日志文件是非常关键的。有两个提高日志保留的 DB2 特性：双日志记录和用户出口工具，已在关于数据库复制 HA 选项的部分中进行了讨论。

4灾难恢复方案

灾难恢复方案可以分成三类：简单备份、备份和日志保留、高级存储备份 。

虽然不是每个解决方案都清晰地被划入这三类中的某一类，但它们确实为您理解灾难恢复选项提供了合理的框架。

4.1 简单备份

只创建数据库备份确实创建了一个 DR 解决方案。它也许是非常有限的，这取决于您的环境。通过从“活动”的系统上移走所创建的备份，可以提高保护的级别。增加数据库备份的频率也降低了数据丢失的风险。

备份软件对于创建和维护 DB2 备份可能非常有帮助。例如，IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了允许在其软件控制的设备上直接备份和维护 DB2 数据库的解决方案。这些设备可以是磁带库或另一种存储设备。

简单备份适合于只读数据库或由能轻松重新创建的批处理作业填充的数据库，或者在备份之间不必维护数据库更改的情况下。

表 6. 简单备份的优缺点

	优点：	缺点：
保护级别：	数据库备份可以转移到外部位置，以提高保护级别
数据丢失的风险：		备份之间的数据更改可能会丢失（运行增量备份来降低风险的影响）
恢复所需的时间：		数据库恢复需要很长时间

4.2 备份和日志保留

保留数据库日志文件与数据库备份一起创建了更完善的 DR 解决方案。日志文件允许恢复备份之间发生的数据更改。

该解决方案的真正复杂性在于保护日志文件以确保它们在恢复期间的可用性。如果选择实现双日志记录，DB2 可以将日志文件放在不同的位置，如果确保这些位置在不同的存储器阵列上，那么保护级别就会得到提高。

但是，日志文件仍面临存储子系统故障。如在高可用性的日志传送选项中所提到的，用户出口程序可以提供重定位日志文件的替代方法。用户出口可以将已关闭的日志文件移到当前系统可用存储阵列之外的位置，从而提高保护级别。这里的告诫是它只移动已关闭的日志文件。即使已实现了双日志记录，包含活动事务的日志文件仍面临因阵列丢失或存储设备故障而产生的丢失。

该解决方案适合于大多数面向商业事务的环境。它均衡了最小化数据丢失风险的需要和维护 DR 解决方案所需的成本。

表 7. 备份加日志保留的优缺点

	优点：	缺点：
保护级别：	数据库备份可以转移到外部位置，以提高保护级别
数据丢失的风险：	如果使用适当的步骤来维护日志文件，会大大降低数据丢失的风险
恢复所需的时间：		数据库恢复需要时间，应用日志文件将增加恢复时间

4.3 高级存储备份

我们在高可用性下的 高级存储选项部分中讨论过这个主题，相同的原则在这里也适用。正如在那部分中所见的，STANDBY 方法允许当数据库副本处于暂挂状态时在辅助系统上执行数据库备份。

创建数据库副本已经创建了 DR 解决方案的一部分。备份副本提高了保护级别。如果用双日志记录和用户出口程序正确实现了这个高级存储备份，那么它就为核心企业数据库生成了最好的 DR 解决方案。

该解决方案最适合处于企业活动核心的数据库系统。示例可能包含了供应链管理和在线代理系统。

表 8. 用于灾难恢复的高级存储备份优缺点

	优点：	缺点：
保护级别：	保护级别本来就很高，而且可以通过耦合存储子系统来提高保护级别。
数据丢失的风险：	如果采用双日志记录和用户出口程序，会大大降低数据丢失的风险
恢复所需的时间：	恢复所需的时间非常短。

 

 

附录:名词解释

• 高可用性（high availability，HA）：是这样一种需求：每当需要时，数据就可用于从属应用程序。其目的是消除或最小化停机时间。
• 灾难恢复（disaster recovery，DR）：防止由于毁灭性的故障而导致数据丢失。这类故障意味着由于不可恢复的情况而丢失数据。
• 群集（cluster）：有两种类型的 DB2 数据库群集： 高可用性和 高可伸缩性（high scalability）。虽然在一个解决方案中可以结合这两种群集，但应该将它们看作是互斥的实体。高可伸缩性群集（也称作数据库分区）结合了多台服务器的聚集能力以产生高性能解决方案。该技术通常用于构建数据仓库或大型事务系统，而在这样的数据仓库或系统中，单个服务器是无法实现性能目标的。高可用性群集产生一个能最大化数据库正常运行时间的系统。在本文中，术语“群集”仅指高可用性群集。

备注

本文章中大部分内容来至IBM官方网站以及其他网上文章，但是其来源已经不祥，为此对原作者表示歉意。本人只是将其组合，加上一些自己的观点。