数据库镜像是将数据库事务处理从一个数据库移动到不同环境中的另一个数据库中。镜像的拷贝是一个备用的拷贝，不能直接访问，它只用在错误恢复的情况下。Oracle数据库与MSSQL数据操作上有很大的不同，但是，在镜像操作方面有类比的地方。这篇文章关于MSSQL数据库镜像在Oracle数据库中是如何实现的，它们之间存在哪些差异呢。

首先，微软SQL数据库中的镜像数据库类似于Oracle数据库中的备用数据库。我说的只是类似，确切的说，我们需要考虑不同数据库在自己体系中的差异。MSSQL作为一个实例来操作，一个实例包含几个数据库，你首先要登录一个实例，然后选择哪个数据库作用于该实例。而在Oracle数据库中，简单模式(忽略RAC)就只有一个数据库与一个实例相联系。因此，可以这么说，在Oracle数据库中，备份数据库(standby database)就完全是主数据库的快照。而在MSSQL中，镜像数据库仅仅是选择的那个数据库的备份，但没有包括代理，登录，任务(这些或者更多的数据库项目需要单独在数据库镜像上创建或者复制)这些外部数据项。

在服务器数量上，Oracle的主数据库和备用数据库配置最小需要2台。在MSSQL中，最小数据是2个或3个，根据你所选择的高可用性、高安全性、高性能方式所决定。

高可用性方式：这个操作模式选项允许你在两台服务器上同步事务写入，并支持自动错误恢复。要使用这个选项，你必须还要使用一个证人服务器。

高保护方式：这个选项可以让你在两台服务器上同步事物写入，但是错误恢复是手工的。因为自动的错误恢复不是这个选项的一部分，所以也不会用到证人服务器。

高性能方式：这个选项不关心两台服务器上的写入是否是同步的，因此在性能上有所提高。当使用这个选项的时候，你只能假设镜像服务器上的所有事情都是成功完成。这个选项只允许手工的错误恢复，因此不会用到证人服务器。

MSSQL还有其它版本的选择，但是这些并不如Oracle的反射“干净”，这些版本包括：Developer、Workgroup 和 SQL Express。举个例子，目击服务器能够是任何的版本，但是如果你想给镜像服务器做一个快照，那么你就需要企业或者开发版的了。

在设置伙伴(partner，通常有主数据库和镜像数据库组成)过程中，他们的恢复状态开始起作用。通过使用相同的名字，镜像在远程/镜像服务器上建立(使用配置数据库镜像安全向导是最简单的方法)起来，并且镜像数据库被设置成NORECOVERY，通常它是恢复(recovering)状态的。在MSSQL中，恢复数据库是没有的，因此没有进行上述的设置，是不能被其他用户当作只读数据库来使用的。

为了避免这个中缺陷，你可以给镜像做一个快照，使得该“影像”对用户可见。正如我上述所提到的那样，这需要你的数据库版本是企业(或者开发)版。这就意味着用户需要有快照数据库的知识，知道如何进入存储它，如何告诉应用程序使用哪个数据库。惯例上来说，配置文件使用的.NET环境，你能建立一个主数据库和一个故障回滚的辅数据库。如果在Oracle中配置过备份数据库，你就会觉得这很类似。

结论

这篇文章内容包括按照Oracle的方式，如何更好的理解在另一种主流的RDBMS上执行镜像或者复制，。试着学习和解释你的RDBMS如何工作的，从另外一种模式来得到你的注意有助于你搞清楚你当前数据库系统运行原理。举个例子，我发现非常有实用价值的是Oracle归档模式和MSSQL三种恢复模式之间的关系。使用在MSSQL中的一些术语(伙伴，主数据库，目击，镜像)有助于你构成和识别Oracle中执行数据库镜像的操作。

为了更好的评价数据库镜像是如何运作，如何实施的，你可以运行两个单独的MSSQL实例，操作系统是XP或者是2003都没有关系。按照MSDN联机丛书的步骤完成一遍。下载或者选用AdventureWorks数据库(类似于Oracle的HR/SH数据库等。这些都没有预安装的)，将其镜像到主机服务器上。呈现在你面前的不仅仅是另外一个数据的所具有功能特性，你将还会看到MSSQL所具有的操作，得到自己的正确评价(我平时使用的是Oracle数据库，测试用的是MSSQL，反过来说，你平时使用的是MSSQL，现在用Oracle来测试的话，也会有新的发现)。

为了保证故障自动恢复，就需要有第三台服务器，可以称之为目击者(另外两个就是主数据库和镜像数据库)，你可以将这个目击者当作群集中的一个成员。它实现了2比1投票的能力，当我的一个组件不可达，并因此需要进行错误恢复的时候。证人服务器只有在你想实现自动错误恢复的时候才需要用到。

在Oracle数据的一个事务中，日志缓冲器在废数据写入数据文件(忽略write-ahead情况)前被刷新或者写入到redo日志中。这种刷新或者写入到redo日志的行为是有必要的，如像实例失败(使用前滚和回滚恢复过程)这样的事件发生时。MSSQL也承认将日志缓冲器写入到磁盘的重要性。不过这里称之为硬化(hardening)。首先将事务日志缓冲器的信息写入到磁盘或者硬化，接着将日志记录块发送到镜像数据库中。镜像数据库接收到该日志记录块后，将之存入到某个缓冲器中，随后依次硬化该日志记录块。

当数据发生变化时，MSSQL数据库如何保持主数据库和镜像数据库的一致性呢?

Oracle用户非常熟悉SCN，而MSSQL用户通过使用mirroring_failover_lsn机制(粗略来讲就是一个日志序列号)。MSSQL与Oracle不同，MSSQL将事务分离(两个事务在两个机器上)，而不是一个分布式事务(在自身提交前需要远程等待提交)。

另外一个相似点，但稍微有些畸变的反射就是redo日志和事务日志。在Oracle中，完成的redo日志将被发送到远程的服务器中，将完成的redo日志应用到备份数据中去。在MSSQL中,事务日志没有被传输，但是就像我以上提到的，日志缓冲器数据发送到网络上。这就导致另外一个镜像反射：备份和恢复模式。

在Oracle中，当你处于归档模式或者非归档模式的时候，这些操作是内定的。如果归档redo日志被传输或者提交到一个远程的服务器，那么主数据库明显就是在归档模式下，那些文件就是这么产生的。运行在这种模式下，允许有少量的数据丢失，因为在发生故障(无论什么样的故障)前，恢复能够在任意一个点上执行。在MSSQL中是类似的，但是有三种状态需要选择。

《SQL Server联机丛书》，像许多其它的在线资源一样，讲述了在使用MSSQL时，3种恢复模式的不同点。快速的比较有：MSSQL完整模式对应于Oracle中的归档模式;简单模式对应于非归档模式;bulk模式与使用直接路径插入，添加提示，或者与nologging模式操作类似。

根据以上三种模式(这三种模式很容易转换，不需要关机或者重启)的描述以及日志缓冲器和归档redo日志的讨论中，很容易断定在MSSQL中进行数据库的镜像需要将数据的回复模式设置成完全模式(full model)。简单模式(Simple model)或许也能行，但是这种模式下维持事务日志中的小部分数据，在备份中，如果在日志被删节了，整个镜像过程也就破环了，因为当你在将事务发送到镜像数据库中的时候，如果日志被删节了，这个过程就不能完成。

说到数据库被破坏该怎么办呢?

这正是镜像(或者说备份)的主要目的：当主数据库断开或者说遇到故障时候我们希望系统能回到镜像前或者备份前的状况去。这如何才能实现呢?我们能自动实现或者手动实现。想实现这些，需要一些已经完成的设置。在MSSQL中，自动故障恢复，回到原来状态需要在HA模式，事务安全是full，数据传输是同步，有目击服务器的情况下。这种模式下运行还需要使用企业版的数据库系统。高安全性和高性能在标准版的情况下也能实现。