我必须使用Oracle数据库及其数据库开发系统，还是选择配有Visual Studio的Microsoft SQL Server.这个决策将决定我们今后Web项目的方向，这两种组合有什么优势和劣势呢?

1.1. 比较的因素

LORI：决定选择哪种方案将取决于你目前的工作平台。例如，如果你想实现一种基于Web的数据库应用，而且你的工作平台只是Windows，那么SQL Server和Visual Studio组件就是一个不错的选择。但是对于混合平台，则最好选择Oracle解决方案。

1.1.1 开发软件：

还要考虑一些其他的因素，例如你可以获得哪些额外的功能以及需要哪些技术。WebDB是一种内容管理和开发工具，即使没有任何编程经验的内容创建员、数据库管理员和开发员也都可以使用这种开发工具。WebDB是一种基于浏览器的工具，有利于方便地创建内容，以及提供导航和维护工具。这对于已经使用Oracle的机构则是一个很好的解决方案。Oracle比SQL Server更易于调整，但你需要身边有一个称职的Oracle管理员。

SQL Server/Visual Studio方法相对来说较难使用，需要一个有经验的面向对象的编程人员或一些全面的训练。但是，你只要花上1619美元就可以获得许多Visual Studio的开发工具：Visual Basic，Visual C++，以及Visual Interdev。另外，你需要再加上SQL Server的费用，1999美元就可以拥有10个客户端，或用3999美元获得25个客户端—与Oracle的费用相比则便宜些。

Oracle也有一个组件解决方案，根据所选择平台的不同，费用也不同，最低为6767美元。Oracle.com套件不仅包括WebDB和Oracle8i，还包括其它的开发工具，如Oracle应用服务器、Jdeveloper和iWorkplace模板，该套件与Microsoft方案相比能运行在更多的平台上。如果你刚创业或是一个小型和中型企业，则Oracle套件是一个很好的选择方案。以组件的形式购买这些工具要比单独采购的花费要少些。

对这两种方案的选择主要取决于你的技术水平、硬件资源和资金预算。我希望以上所说的能对你的决策有一定帮助。

1.1.2 学习和应用灵活性

我完全同意对这两种方案的选择在很大程度上取决于你目前所配有的基础设施和所具有的专门技术。如果很难做出抉择，你就需要考虑由谁来做这项工作，以及你的重点是什么。

这两种产品采用不同的方法，并反映出这两个开发商的不同特点。Oracle是为那些优秀的程序员和项目负责人所进行的专业化开发而设计的产品。学习时间较长，该方案的费用也较高;但是你如果坚持下去，最终就会获得更好的灵活性，以及更高的可靠性。

如果你的项目时间很紧，而且你没有时间或金钱来雇佣一个花消很大、经验很丰富的开发队伍，你也许会发现选择Oracle方案会很容易使你陷入困境。没有比开发一个质量很差的Oracle应用程序更槽糕了。

Microsoft所提供的解决方案则致力于快速开发和低成本实现。开发工具、服务器、以及你所需要的开发人员的花费都比较少。若要使项目快速启动，选择SQL Server和Visual Studio则是很好的方式。

当然，有得必有失。在使用Visual Studio和SQL Server的过程中，我所遇到的主要问题就是，只能使用Microsoft操作系统和Intel硬件。如果有一天你需要支持成百上千个用户，你除了购买上百个服务器而外别无他法，这会给管理带来很大的麻烦。

如果你采用Microsoft方法，就表明你可能只需要Visual Interdev即可。如果你已经知道你将开发Visual Basic或Visual C++里的ActiveX组件，这就是一个预示，表明你需要更多的来考虑Oracle的解决方案。

1.1.3 选择的原则

我想强调的是，尽管这两种平台有他们各自的优点和缺点，如果你使用正确，你用任何一个都可以设计出具有世界水平的应用程序。如果你的组织倾向于某种产品，一定要跟随这种趋向。如果你是从零起点开始，就需要问问自己，你的组织是更倾向于完美主义还是实用主义，并要清楚这两种主义都有缺点。

在软件方面，确保高可用性的最重要步骤就是使用最新的服务包使操作系统、设备驱动程序和应用程序软件保持为最新。这确保您的系统将具有最新的软件更新和安全更新。Microsoft 提供了大量处理系统更新问题的技术。System Management Server (SMS) 产品可提供企业级的软件更新和目录功能。对于中型企业，新的 Windows Server Update Services (WSUS) 可提供在组中分发 Microsoft Windows? 和 Microsoft Windows Server 更新的功能。而 Windows Update 可为小型企业提供系统更新。

保持最新的修补程序是非常重要的步骤，还需要具有适当的质量保证过程，以将软件更新部署到生产环境中之前在测试环境中严格对所有软件更新进行测试。

处理这些基本的系统必备是提高数据库和服务器可用性非常重要的步骤，不过这措施本身并不能确保带来高可用性。为了进一步提供针对服务器故障的保护和确保高数据库可用性，需要采用由各个竞争数据库平台支持的某项高可用性技术。这些技术设计用于帮助系统更好地应对系统故障，并能在出现服务器故障时更快地进行恢复。

充分利用集群技术和日志传送是创建高可用性数据库平台的重要技术手段。集群技术主要涉及到在这样一种环境中使用多台服务器，即一台或多台备份服务器可以无缝地接过出现故障的主服务器的工作负载。除了集群技术之外，目前的竞争企业数据库平台都支持大量的其他针对服务器故障提供保护的技术。其中包括日志传送和复制技术。本节将对每种备选技术进行分析，并讨论每个企业数据库产品是如何实现这些技术的。

1.2. 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 和 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 的基本概况。

每个集群节点需要下列硬件：

一个用于 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 个活动节点之一发生故障时切入。

1.3. 数据库镜像

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 功能的工作原理概览。

1.4. Database Mirroring 使用三套系统来实现：主服务器、从服务器和见证服务器。

主服务器是当前提供数据库服务的 SQL Server系统。默认情况下，所有传入的客户端连接都连接到主服务器。从服务器的工作是维护主服务器镜像数据库的一个副本。从服务器不限于只提供后备服务，从服务器上的其他数据库可以活动地支持其他非关联应用程序。见证服务器实质上是作为独立的第三方，负责确定哪个系统将承担主服务器的角色。

Database Mirroring 是通过在主服务器和从服务器之间发送事务日志而进行工作的，从而使 Database Mirroring 成为一个实时的日志传送应用程序。当客户端系统向主服务器写入事务时，在该请求被写入数据库文件之前，它被写入到主服务器的日志文件中。随后该事务记录将被发送到从服务器，然后写入到从服务器的事务日志中。从服务器将记录写入其日志后，将向主服务器发送确认消息。这使两个系统都知道记录已被接收到，现在同样的数据在每个服务器日志文件中都存在。当进行提交操作时，在主服务器向客户端回应操作已结束的信息前，它将等待镜像服务器的确认消息。从服务器实质上处于连续恢复的状态，不断地使用传入的事务日志数据对数据文件进行更新。

为了提高客户端应用程序的高可用性，Database Mirroring 与 Microsoft Data Aclearcase/" target="_blank" >ccess Components (MDAC) 层中称为“Transparent Client Redirection”的更新协同工作。Transparent Client Redirection 使最终用户系统在主服务器的数据库不可用时，可以自动重定向到从服务器。因为新的 Transparent Client Redirection 功能是在 MDAC 层中实现的，所以利用该功能时，不需更改客户端应用程序。MDAC 软件层了解主服务器和从服务器的状态，当初始连接到主服务器时，它会同时取得从服务器的名称。如果客户端失去主服务器连接，MDAC 将进行一次重新连接到主服务器的尝试。如果该连接尝试失败，则 MDAC 将自动将接下来的连接尝试重定向到从服务器。

Database Mirroring 可以与 SQL Server 2005 数据库快照组合，用于创建使用镜像服务器数据的报告服务器。数据库快照提供特定时间点的只读数据库快照。图 5 所示为使用 Database Mirroring 和数据库快照的组合创建只读的报告数据库的示例。

通常，镜像服务器上的数据总是处于恢复模式，这意味着任何应用程序都不能访问。不过，可以为镜像的数据库创建数据库快照，以创建镜像数据库的一个只读副本。报告应用程序在只读模式下可以自由访问该数据库。

1.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 组合使用来提供保护，防止受到站点级灾难和本地服务器故障的影响。日志传送使在一个或多个从服务器上维护生产数据库成为可能，并且在某个服务器或站点发生故障时，可以提升其中一个从服务器，使其成为新的主服务器。

1.6. SQL Server 2005——复制

事务复制是可以用于解决服务器故障的另一个技术工具。尽管复制可以从主数据库向从数据库发送事务，但并非主要设计用作高可用性解决方案，不过，可以将事务复制作为低成本的数据库服务器备份机制。图 6 所示为 SQL Server 2005 事务复制的概览。