针对数据库恢复的数据库高可用性解决方案
创建高可用性环境的能力可能会受到纠正应用程序错误和数据破坏的需求的影响。保持数据对用户和员工可用的一个重要方面就是确保“正确”的数据可用。如果数据库中的数据被破坏（例如，用户错误，如使用不正确的信息更新数据库或无意删除了信息），则必须有相应的过程能够快速识别并将数据还原到其原始状态。
- SQL Server 2005——备份与事务时间点恢复
高可用性的关键组成部分之一就是良好的备份与恢复计划。SQL Server 2005 不同的恢复模型在记录开销和数据的完全恢复能力这两方面实现了平衡。SQL Server 2005 提供三种恢复模型：简单、完全、批量记录。
简单恢复模型。此模型具有最低的记录开销，但不能恢复任何最后一次备份前的数据。使用简单恢复模型，将丢失从上次备份以来的所有数据修改。
完全恢复模型。该模型与简单恢复模型正好相反，将记录所有的数据更改。使用完全恢复模型，所有数据都可以恢复到发生故障时的状态。默认情况下，SQL Server 使用完全恢复模型。
批量记录恢复模型。此模型位于两个极端之间，将记录处理批量操作（如批量复制和 SELECT INTO）之外的全部事务。在进行恢复时，这些操作会丢失。而批量记录模型可以恢复到最后的数据库或记录备份时的状态。
选择了恢复模型后，组织需要确定采用何种备份计划。可以备份到磁盘、磁带或其他媒体。执行磁盘备份是用于备份和还原数据最快的机制。为了防止受驱动器故障的影响，应始终将备份放置到独立的驱动器上，最好是与数据库数据独立的控制器上。SQL Server 支持三种基本数据库备份类型：完全备份、差异备份和日志备份。
完全数据库备份。此类备份是数据库的完全副本。这将提供一个已知点，从此处开始还原过程。
差异备份。此备份仅复制最后一次完全数据库备份之后修改过的数据库页。频繁进行差异备份，可以尽可能减少将数据库恢复到最近事务状态时所需的事务日志数量。
日志备份。此备份仅复制事务日志。事务日志备份可以在还原了最后的差异备份之后应用。
事务时间点恢复允许将整个数据库恢复到任何给定的时间点时的状态。SQL Server 2005 事务日志是一系列记录，包含自最后一次备份事务日志以来在数据库中所做的全部更改。使用事务日志备份，可以将 SQL Server 数据库恢复到任何特定的时间点。例如，如果 04:00 时出现了应用程序错误，导致一个数据库中数据被破坏，则可以使用 SQL Server 2005 事务日志备份将数据库恢复到 03:59（发生数据破坏前）的状态。
当还原了 SQL Server 事务日志时，该日志中包含的所有事务都会被前滚。除了用于更新数据库的数据外，每个事务日志记录都包含一个时间戳，用以指明事务发生的时间。达到事务日志尾部或在还原期间遇到了指定的时间时，数据库将处于最后事务时的精确状态，使您能够迅速从数据破坏错误恢复。
除了这些标准的备份选项之外，SQL Server 2005 还提供非常准确的页级别还原功能，可以还原一个页或一组页。
- SQL Server 2005——有延迟的日志传送
可以将日志传送配置为允许“时间窗”，以方便地从出现数据破坏的情况恢复。日志传送是一种数据库可用性技术，该技术将日志从数据库服务器发送到一个或多个备份服务器上。如果主服务器或数据库出现故障，就可以随后将这些事务应用到备份服务器上。主服务器的事务日志备份在发送到从服务器之前可能会有指定量的延迟。例如，不采用立即将事务日志发送到从服务器的方式，而可以将日志传送配置为每五分钟向从服务器写入一次。如果在这五分钟期间出现数据错误，可以使用从服务器上的事务日志将数据恢复到五分钟前的状态。
- SQL Server 2005——文件组还原
时间点恢复和日志传送恢复功能均在 SQL Server 2005 中可用。事务日志备份可以应用于将数据恢复到特定的时间点。
SQL Server 2005 的新功能允许方便地还原被破坏的对象。SQL Server 2005 中的细粒度还原功能允许对数据库中选择的文件组进行还原。在 SQL Server 2000 中，可用性单位是数据库。在数据库可用之前，不能接触到数据库的任何组件。在 SQL Server 2005 中，可用性单位则为文件组。这样就提高了可用性，因为只有当前正在还原的数据不可用；仍然可以访问包含在其他文件组中的其他数据库数据。SQL Server 2005 允许一次还原一个文件组，或在主文件组就绪时，甚至可以还原一个页或一组页。
- SQL Server 2005——快速恢复
与 Oracle 的 FastStart Fault Recovery 一样，SQL Server 2005 的快速恢复功能允许用户在事务日志前滚后立即重新连接到正在恢复的数据库，从而提供了数据库可用性。SQL Server 的早期版本要求用户必须等到回滚了未完成的事务之后，即使用户不需要访问所涉及的数据库区域也是如此。
- SQL Server 2005——数据库快照
SQL Server 2005 包含数据库快照，允许快速方便地还原损坏的数据。数据库快照提供了生成数据库只读视图的工具，而不会有创建整个数据库及其相关存储区的副本的系统开销。图 1 所示为数据库快照的概览。
图 1：数据库快照
数据库快照与数据库副本不同。数据库快照仅占用包含数据库信息更改所需的空间。随着对数据库进行更改，快照将从数据库接收自己的原始页副本。要从不恰当的数据库更改恢复，可以将快照中的原始页重新应用到数据库。
-
Oracle 10g—Recovery Manager (RMAN)
Oracle 10g 包括了一款称为 Recovery Manager (RMAN) 的工具，用于管理创建备份和进行还原的流程。RMAN 工具由 RMAN 可执行函数、要备份的目标数据库和可选恢复目录组成。如果未指定恢复目录，备份详细信息将存储在目标数据中的一个“控制文件”中。Recovery Manager 可以用于恢复被破坏的数据或不能接受的数据更改。控制文件中包含关于数据文件和从数据文件创建到恢复时的存档日志文件的信息。
标准 RMAN 备份包含组成特定数据文件的数据块的备份单元。数据块以特殊的压缩格式存储。需要还原数据文件时，需要从备份单元中的块重新创建整个数据文件。现在使用 Oracle 10g，可以在数据库级、表空间级或数据文件级创建映像副本。数据文件的映像副本的还原速度较快，因为数据文件的实际结构已经存在了。一项称为 Incrementally Updated Backups 的 RMAN 功能允许将增量数据库更改应用到数据文件映像副本备份，以将其前滚到特定的时间点。通过不时地使用增量备份来更新数据文件映像副本，可以将数据文件映像副本前移到更为接近其最近状态的位置。这就减少了数据恢复时间。
Change Tracking 是 Oracle 10g 中的一个可选功能，可以提高增量备份的性能。在 Oracle 以前的版本中，需要对数据文件中的所有块进行扫描，以发现从最后一次增量备份以来的更改。启用了 Change Tracking 后，只需对第一个增量备份进行全面扫描，因为所有更改过的块的 ID 都被写入了 Change Tracking 文件。后续的增量备份将扫描 Change Tracking 文件，以确定是否需要备份任何更改过的块。
- Oracle 10g—Flashback
Oracle 10g 的 Flashback 提供了与 SQL Server 2005 数据库快照非常相似的功能。Flashback 数据库允许使用 Flash Recovery Area 代替标准备份媒体，将数据库恢复到特定的时间点。Flashback 功能最好用于恢复被破坏的简单表和行数据，与最适合用于恢复较大的数据块的 RMAN 功能相对。要使用此功能，DBA 必须配置一个 Flash Recovery Area，使其包括 Flashback 数据库日志、Redo 存档日志和 RMAN 备份。块更改的副本写入到 Flashback 日志中，可以在出现用户或应用程序错误事件时还原到数据。Flashback 包含特定的 SQL 语句，用于对 Flash Recovery Area 进行查询和从中恢复数据，因此，为了访问对象，需要给用户授予适当的特权。
注意：Flashback 技术的一个重要局限在于其并不具有对引用完整性的内置支持。如果使用 Flashback 还原具有依赖项的表，而这些依赖对象已经发生更改，则可能会在数据库中造成不一致现象。
Flashback Table、Database 和 Transaction Query 功能仅在 Oracle Enterprise Edition 中提供。
