数据库镜像与日志传送的特点

前一段时间面试的时候问到有关数据库镜像和日志传送差别的问题。现大致总结如下：

A。数据库镜像

镜像数据库一直牌恢复状态，所以它不接受任何类型的连接，也不允许直接将事务写入数据库但可以通过为镜像数据库创建数据库快照的方式，使用户对数据库中黄果树一时刻的数据拥有吟诗的权限。

因为数据库是相同的，并且都使用同步方式进行维护，在黄果树一时刻数据库既可以是主体又可以是镜像。所以在数据库镜像佳话中，主体服务器和镜像服务器角色都是瞬变操作状态。

见证服务器角色在数据库镜像中是可选角色。唯一目的是作为高可用操作方式的仲裁者。保证数据库在同一时间只能服务于一个SQL实例。

主体数据库不能有多个镜像数据库。见证服务器可以服务于多个数据库镜像组合。

主体服务器和镜像服务器角色发生在数据库级。见证服务器角色处于实例级。

所有的数据库镜像通信都是通过一个负载数据库镜像的TCP端点进行舆。每个SQL实例只可以创建一个数据库镜像端点。

可以在一个服务器上配置多个SQL实例。每一个实例有一个数据库镜像端点。然而在同一台服务器不同实例上的数据库镜像端点必须使用不同的端口号。

数据库镜像端点既可以是配置为加密通信方式，也可以配置为不加密通信方式。但默认为是加密的。

数据库镜像不用等到所有的事务都处理完毕就可以将事务传输到另一台机器。数据库镜像同步传输数据的影响会随着事务平均大小的啬而减小，事务越大，高可用性操作方式所需要的确认时间占总体运行时间的百分比就越小。

只有当SQL成功地将事务提交观察员体和镜像数据库的事务日志中时。事务才提交成功。因此高可以操作会导致应用程序的性能下降。同步传输对于性能的降低将随着主体数据库和镜像数据库之间距离的增加而增加。

高可用操作在参与数据库镜像佳话的实例间使用简单的ping完成故障检测。由于一个失控事务或其他操作数据库可能变为不可达的。然而是，数据库镜像并不会检测这种故障。只有ping测试失败会被视为故障。

高可用性会自动完成事务流的转换而复制和日志传送需要手动干预或者重新 配置事务流。

只有在见证服务器联机时，才会发生自动故障转移。

具有透明客房端重定向的功能。

数据库镜像会话中的每一个数据库都必须使用完整恢复模式。

B日志传送

日志传送工作在服务器的数据库一层，允许额外配置一台用于验证日志传送会话状态是否正常的监视服务器。但只是在会话过程中遇到错误时及时发出通知而已。

辅助数据库处于standby模式时，能被应用所访问并且处理sql语句。但当应用程序正在与数据库连接时，不能还原事务日志。处于no recovery模式时，不能被应用访问对于两种模式，事务日志都能在备用服务器上还原。

日志传送依赖于SQL SERVER AGENT。数据库丢失影响时间是事务日志备份间隔的两倍。