数据库快照与数据库副本不同。数据库快照仅占用包含数据库信息更改所需的空间。随着对数据库进行更改，快照将从数据库接收自己的原始页副本。要从不恰当的数据库更改恢复，可以将快照中的原始页重新应用到数据库。
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 中提供。
针对服务器故障的数据库高可用性解决方案
毫无疑问，在高可用性环境中的主要技术考虑就是针对服务器故障提供保护。服务器故障可以定义为一个计划外事件，会导致用户无法访问服务器系统。一系列不同的因素都可能导致服务器故障。各种不同的硬件和软件原因都可能导致服务器故障，包括：
硬件故障（CPU、RAM、存储设备、I/O 或电源）
操作系统或设备驱动程序故障
数据库服务器故障
针对硬件故障提供保护的第一步就是投资购置提供关键组件冗余的硬件平台。例如，目前主要硬件供应商提供的大部分服务器都提供高可用性功能，如冗余电源，内置不间断电源 (UPS) 以及可以热切换的 RAM 和 RAID 驱动器。
在软件方面，确保高可用性的最重要步骤就是使用最新的服务包使操作系统、设备驱动程序和应用程序软件保持为最新。这确保您的系统将具有最新的软件更新和安全更新。Microsoft 提供了大量处理系统更新问题的技术。System Management Server (SMS) 产品可提供企业级的软件更新和目录功能。对于中型企业，新的 Windows Server Update Services (WSUS) 可提供在组中分发 Microsoft Windows? 和 Microsoft Windows Server 更新的功能。而 Windows Update 可为小型企业提供系统更新。
保持最新的修补程序是非常重要的步骤，还需要具有适当的质量保证过程，以将软件更新部署到生产环境中之前在测试环境中严格对所有软件更新进行测试。
处理这些基本的系统必备是提高数据库和服务器可用性非常重要的步骤，不过这措施本身并不能确保带来高可用性。为了进一步提供针对服务器故障的保护和确保高数据库可用性，需要采用由各个竞争数据库平台支持的某项高可用性技术。这些技术设计用于帮助系统更好地应对系统故障，并能在出现服务器故障时更快地进行恢复。
充分利用集群技术和日志传送是创建高可用性数据库平台的重要技术手段。集群技术主要涉及到在这样一种环境中使用多台服务器，即一台或多台备份服务器可以无缝地接过出现故障的主服务器的工作负载。除了集群技术之外，目前的竞争企业数据库平台都支持大量的其他针对服务器故障提供保护的技术。其中包括日志传送和复制技术。本节将对每种备选技术进行分析，并讨论每个企业数据库产品是如何实现这些技术的。
SQL Server 2005 N 路集群
由于利用了 Windows Server 2003 提供的增强集群支持，SQL Server 2005 在Windows Server 2003 Datacenter Edition 上支持多达 8 个节点的集群；在 Windows Server 2003 Enterprise Edition 和 Windows 2000 Datacenter Server 上支持 4 节点集群；在 Windows 2000 Advanced Server 上支持两节点集群。其安装过程和管理工具都支持集群。
Microsoft Windows Clustering Services 是用于保护数据库平台不受服务器故障影响的一项重要技术。Windows Clustering Services 对所有企业数据库应用程序都可用，包括SQL Server、Oracle 和 DB2。Windows Server 操作系统版本不同，它们支持节点数的能力也不相同。下表说明了Windows 2000 Server 和 Windows Server 2003 不同版本的基本集群性能。
操作系统
节点数
Windows 2000 Server
0
Windows 2000 Advanced Server
2
Windows 2000 Datacenter Server
4
Windows Server 2003 Standard Edition
0
Windows Server 2003
Enterprise Edition
4
Windows Server 2003 Datacenter Edition
8（仅 SQL Server Enterprise Edition 64 位）
Windows 2000 Server 和 Windows Server 2003 Standard Edition 不支持故障转移集群。Windows 2000 Advanced Server 支持两节点集群；Windows Datacenter Server 2000 和 Windows 2003 Enterprise Edition 支持 4 节点集群；Windows Server 2003 Datacenter Edition 支持多达 8 个节点的集群。所支持的节点数量取决于主机操作系统的功能。
对于 Windows Clustering，集群中的每个物理服务器称为“节点”。节点共同工作组成“集群”。集群中的所有节点都处于持续的通信状态。如果其中一个节点不可用，那么其他节点将自动承担其服务，并且开始向用户提供与故障节点相同的服务。这个过程称为“故障转移”。与可以提供无间断服务专业容错的第三方硬件解决方案不同，Windows 集群的故障转移过程的完成需要约20秒的短时间隔（取决于所使用的硬件）。另外，必须恢复故障转移节点上的数据库，从而保持事务一致性。该恢复时间的长短很大程度上取决于故障转移时正在进行的数据活动的水平和所使用的硬件类型。连接到故障节点的客户将被断开连接。当他们试图重新连接时，将可以访问备用节点上的集群资源。Windows Clustering 具有下列优势：
自动故障转移。当检测到故障时，集群将自动从主节点切换到从节点。
对客户透明。故障转移完成后，客户可以使用相同的虚拟名称和（或） IP 地址重新连接到集群中。
事务完整性。所有提交的事务将被保存，并且在故障转移处理完成后可以使用。
快速故障转移。在大多数情况下，系统的故障转移过程大约在 30 秒内可以完成。后续数据库可用性取决于需要前滚或回滚的事务数量。
在图 2 中，可以看到 Windows Clustering Services 的基本概况。
图2：基本集群
每个集群节点需要下列硬件：
一个用于 Windows Server 操作系统的硬盘。该硬盘不共享，并且不连接到用于连接共享存储的控制器。该磁盘使用它自己的控制器，并且应该被镜像，以提高可用性。
SCSI 或 Fibre Channel 适配器，连接到集群的共享磁盘存储器。
二张网卡 (NIC)。一张网卡用于将集群节点连接到外部网络；另外一张网卡用于专用集群网络，它维持集群的“心跳”——表明节点可用的信号。
因为集群中的节点使用共享存储子系统，所以它们通常需要放置于相对较近的位置。节点之间的距离取决于用于存储子系统的节点的连接情况。使用共享 SCSI 连接的集群必须相对较近（数米范围内）；而使用 Fibre Channel 连接的节点可以相隔数英里。该解决方案减小了服务器故障引起停机的可能性，但仍然易受影响整个位置的事件的影响。地理集群（多站点集群）通过按地理位置上分散集群节点解决了这个问题。该方法通过同步镜像不同位置之间的 Quorum 磁盘来实现。集群实际上并不需要知道其节点之间的地理距离，所以这些解决方案必须在组织的基础架构的网络级和存储级上实现。
为了实现 Windows Clustering 解决方案，必须使用 Microsoft 认证的服务器系统和 Windows Clustering 软件。可以在 Windows HCL Home 网页上找到受支持的硬件平台列表。确保使用的是经过认证的集群系统很重要，不要使用现有部件自行构建集群。这是因为硬件供应商将对这些系统进行有力的测试，以便符合 Microsoft 所定义的要求，并且作为一个整体对系统进行认证。
使用部件自行构建的集群（而非经过认证的系统）是不受支持的配置。
使用 N 1 配置（N 活动节点 1 后备节点）的 SQL Server 2005 和 Windows Server 2003 组合可提供非常灵活且极具成本效益的的集群方案，能实现高可用性应用。例如，在 N 1 配置的 8 节点集群中，8 个节点中的 7 个可以设置为活动状态以提供不同的服务，而剩下的 1 个节点设置为被动节点，当7 个活动节点中任何一个服务器出现故障时，它将承担起该服务器的服务。图 3 所示为一个 8 节点集群，其中 7 个节点为活动的，1 个节点备用，等待 7 个活动节点之一发生故障时切入。
图3：N 路集群
数据库镜像
SQL Server 2005 中的新 Database Mirroring 功能是另一个重要的选项，它可以防止服务器或数据库故障引起的计划外停机。顾名思义，Database Mirroring 提供数据库级的故障转移。在主数据库发生故障的情况下，Database Mirroring 将启用从 SQL Server 系统上的备用数据库，使系统几乎可以立即恢复可用性。单个数据库上可以设置 Database Mirroring，同一服务器上的多个数据库也可以设置Database Mirroring。它提供零数据丢失。从数据库将实时地与主数据库服务器上正在进行的当前事务同步更新。运行 Database Mirroring 对事务吞吐量的影响微乎其微，几乎为零。
与运行在服务器级的 Windows Clustering Services 不同，Database Mirroring 在数据库级实现。Database Mirroring 具有接近实时的故障转移，只需要几秒钟；而集群通常需要约 30 秒的故障转移时间（有时更久，取决于故障服务器上的数据库活动水平和数据库大小）。Database Mirroring 提供对磁盘故障的额外保护，因为其中没有集群解决方案中的共享 Quorum 磁盘。另外，对于 Database Mirroring 实际上没有距离限制；而使用集群的高可用性解决方案有约 100 英里的距离限制，以传输集群节点之间的“心跳”信号。与需要特定硬件配置的集群不同，Database Mirroring 可以与支持 SQL Server 的所有标准硬件一同工作。图 4 所示为新的 Database Mirroring 功能的工作原理概览。
图4：Database Mirroring
Database Mirroring 使用三套系统来实现：主服务器、从服务器和见证服务器。
主服务器是当前提供数据库服务的 SQL Server系统。默认情况下，所有传入的客户端连接都连接到主服务器。从服务器的工作是维护主服务器镜像数据库的一个副本。从服务器不限于只提供后备服务，从服务器上的其他数据库可以活动地支持其他非关联应用程序。见证服务器实质上是作为独立的第三方，负责确定哪个系统将承担主服务器的角色。
Database Mirroring 是通过在主服务器和从服务器之间发送事务日志而进行工作的，从而使 Database Mirroring 成为一个实时的日志传送应用程序。当客户端系统向主服务器写入事务时，在该请求被写入数据库文件之前，它被写入到主服务器的日志文件中。随后该事务记录将被发送到从服务器，然后写入到从服务器的事务日志中。从服务器将记录写入其日志后，将向主服务器发送确认消息。这使两个系统都知道记录已被接收到，现在同样的数据在每个服务器日志文件中都存在。当进行提交操作时，在主服务器向客户端回应操作已结束的信息前，它将等待镜像服务器的确认消息。从服务器实质上处于连续恢复的状态，不断地使用传入的事务日志数据对数据文件进行更新。
为了提高客户端应用程序的高可用性，Database Mirroring 与 Microsoft Data Access Components (MDAC) 层中称为“Transparent Client Redirection”的更新协同工作。Transparent Client Redirection 使最终用户系统在主服务器的数据库不可用时，可以自动重定向到从服务器。因为新的 Transparent Client Redirection 功能是在 MDAC 层中实现的，所以利用该功能时，不需更改客户端应用程序。MDAC 软件层了解主服务器和从服务器的状态，当初始连接到主服务器时，它会同时取得从服务器的名称。如果客户端失去主服务器连接，MDAC 将进行一次重新连接到主服务器的尝试。如果该连接尝试失败，则 MDAC 将自动将接下来的连接尝试重定向到从服务器。
Database Mirroring 可以与 SQL Server 2005 数据库快照组合，用于创建使用镜像服务器数据的报告服务器。数据库快照提供特定时间点的只读数据库快照。图 5 所示为使用 Database Mirroring 和数据库快照的组合创建只读的报告数据库的示例。
图5：报告服务器
通常，镜像服务器上的数据总是处于恢复模式，这意味着任何应用程序都不能访问。不过，可以为镜像的数据库创建数据库快照，以创建镜像数据库的一个只读副本。报告应用程序在只读模式下可以自由访问该数据库。
SQL Server 2005 日志传送
日志传送是一项高可用性和灾难恢复解决方案，可以用于在主服务器故障情况下保护数据库。在 SQL Server 2005 和 SQL Server 早期版本中均提供了日志传送，提供对服务器故障的低成本保护措施。日志传送可以在任何能够运行 SQL Server 的硬件平台上实现，并且它可以配置为与 SQL Server 的任何版本一起运行。日志传送工作时，首先会在后备服务器上还原主数据库的完全备份。此后，将从主服务器的数据库发送事务日志，并将这些日志自动应用到后备服务器上的数据库。可以为日志传送配置一个在后备服务器上应用事务日志的延迟时间，从而防止用户错误。该用户定义的延时提供一个窗口，可以防止用户错误的传播，如意外删除、不正确的数据输入、应用程序错误和其他数据相关问题。
日志传送包括下列组件：
主服务器。该服务器包含生产数据库。SQL Server Agent 作业将定期进行生产数据库事务日志备份，从而捕捉对生产数据库的更改。
后备服务器。后备服务器包含主数据库的一个未恢复副本。后备服务器上的 SQL Server Agent 作业将定期从主服务器复制事务日志备份，并且将其还原到后备数据库。
监视服务器。该服务器监视主服务器和后备服务器的状态。
与 Windows Clustering Services 或 Database Mirroring 不同，日志传送没有进行主服务器和从服务器角色切换的自动过程。日志传送可以与 Windows Clustering Services 组合使用来提供保护，防止受到站点级灾难和本地服务器故障的影响。日志传送使在一个或多个从服务器上维护生产数据库成为可能，并且在某个服务器或站点发生故障时，可以提升其中一个从服务器，使其成为新的主服务器。
SQL Server 2005——复制
事务复制是可以用于解决服务器故障的另一个技术工具。尽管复制可以从主数据库向从数据库发送事务，但并非主要设计用作高可用性解决方案，不过，可以将事务复制作为低成本的数据库服务器备份机制。图 6 所示为 SQL Server 2005 事务复制的概览。
图6：复制