在处理我当前的开发产品时，我在主数据中心和辅助数据中心之间设置了SQL Server镜像。在主数据中心，SQL .mdf和.ldf文件存储在SAN上。
现在可以肯定的是，我们应该不太可能丢失SAN，但是如果例如与SAN的连接丢失并且数据库完整性丢失了。镜像仍然会发生吗？即SQL现在会镜像破坏的数据库，现在两者同样被破坏了吗？
从谷歌搜索不清楚什么时候镜像会发生，也不会发生，所以我希望社区可以分享一些经验。
我还有备份时间表设置，这将是最终的故障保护，但实际上我希望镜像数据库是我们将所有内容重新联机的最快方式。
在这种情况下，目前在镜像过程中没有见证服务器，虽然有了自动故障转移的好处，我想添加一个。
由于
答案 0 :(得分：0)
对于PRIMARY和SECONDARY之间的反映腐败：不幸的是，这取决于。如果损坏是立即和物理的，那么通常 - 通常通过在事务结束时完成的检查来获取损坏并回滚。
但是，在任何事情发现数据库已损坏之前，数据库可能会在损坏状态下存在一段时间。如果未触及基础数据页，则引擎永远不会检查它们。因此，潜在的存储问题可能意味着数据库可能会损坏，并且在您访问受影响的页面之前您不会知道。传统上，这将是一个写操作，因为您的客户端连接只会从当前活动数据库（而不是伙伴）读取。
这就是为什么对数据库执行定期维护检查很重要（例如DBCC CHECKDB）。这在镜像环境中变得更难，因为通常只能检查PRIMARY，因此您必须引发手动故障转移来测试您的SECONDARY（除非您正在运行Enterprise，您可能能够对其进行快照镜像并检查 - 我没试过。）
从SQL Server 2008开始，引擎将尝试一种名为“自动页面修复”的功能，它会尝试自动恢复在镜像过程中遇到的损坏页面。如果这是你担心的事情，你应该留意sys.dm_db_mirroring_auto_page_repair。
如果是逻辑损坏，输入了错误的数据，这将推送到SECONDARY而无需任何停止它。
但是，我应该指出，您的方法可能会让您遇到其他问题。镜像不是备份。在WAN链接上镜像并不好。
在同步模式下，它接收客户端请求，然后写入PRIMARY，然后写入SECONDARY，从SECONDARY获取OK，然后将OK发送回客户端。如果它无法写入SECONDARY，或者没有从SECONDARY获得响应，它将回滚PRIMARY上的操作（即使它成功）并将故障发送回客户端。
WAN链接失败（甚至是暂时的）可能导致PRIMARY选择不接受连接（因为它无法看到SECONDARY）。故障转移中间连接可能会使您处于无效的逻辑数据状态，因此请确保您的事务处于合理状态。
使用WITNESS服务器，这可以更加强大 - 将见证服务器与PRIMARY放在同一个局域网中允许WITNESS和PRIMARY形成仲裁并同意PRIMARY仍在工作，即使它看不到SECONDARY （因此不会将您锁定在功能完善的数据库中）。
相反，通过我较慢的站点到站点链接，我更喜欢在PRIMARY和SECONDARY之间使用日志传送。通过一些努力，我可以控制站点之间的传输，以便对WAN链路进行速率限制，并且可以将日志出货的SECONDARY保持在单用户待机模式。这允许我对SECONDARY运行标准DBCC CHECKDB命令，以及查询SECONDARY以进行数据协调。我也可以对恢复进行延迟，因此我有一些余地可以在主要逻辑数据错误到达SECONDARY之前进行故障转移（尽管这实际上取决于RDO）。
如果我有高可用性要求，我可能只在主站点进行镜像 - 即两个服务器+见证。在过去，目击环境提供的相对快速的几秒钟自动故障转移时间为我节省了一些深夜电话。
希望这有帮助。
学家