为什么 SAN 复制会导致随机数据库损坏？

Question

我们正在尝试实施的灾难恢复技术遇到了奇怪的问题。两个数据中心的环境相同，具有相同版本的 VMWare 和 Dell Equallogic SAN。

当我们从一个数据中心复制到另一个数据中心时，随机数据库会以某种方式损坏并最终进入可疑模式。每次我们尝试这种方法时，不同的数据库都会被损坏。这是 SQL 中的行为导致的吗？这是 SAN 中用于复制的软件导致这些错误的原因吗？

我已经能够将数据库的状态更改为紧急模式并执行 DBCC CHECKDB，但每次都是不同的问题和数据库。我发现的一些错误是索引问题和数据不匹配问题。我仍在检查其他数据库以查看是否可以找到模式。如果发现其他东西，如果有帮助的话我一定会发布。

我听说有人成功地实施了这个程序，这是我们关闭项目章程之前要解决的项目中的最后一个任务。

我真的希望我们可以使用 SQL Server 的内置功能，例如镜像或 AO-AG。

SQL版本为2008 R2和2012。我们正在安装一些全新的 SQL 2014 服务器。而且，它们都是标准版，而不是企业版。

任何输入或我可以尝试的事情都会有很大的帮助，提前致谢！

编辑#1 2015 年 8 月 6 日中午 12:50 CST - 以下是我在Windows事件查看器中发现的一些错误消息，这或多或少是DBCC CheckDB所产生的。

• EventID 605 - 尝试在数据库 26 中获取逻辑页 (1:22620) 失败。它属于分配单元 72057594239385600 不属于 72057594249412608
• EventID 824 - SQL Server 检测到基于逻辑一致性的 I/O 错误：分页不正确（预期 1:1230；实际0:0）。它发生在读取文件“D:\Mydatabase.mdf”中偏移量 0x0000000099c000 处的数据库 ID 58 中的页面 (1:1230) 期间。SQL Server 错误日志或系统事件日志中的其他消息可能提供更多详细信息。这是威胁数据库完整性的严重错误情况，必须立即纠正。完成完整的数据库一致性检查 (DBCC CHECKDB)。
• EventID 7886 - 将数据发送到客户端时，对大对象的读取操作失败。造成这种情况的常见原因是应用程序在 READ UNCOMMITTED 隔离级别下运行。该连接将被终止。
• EventID 608 - 在数据库 23 中找不到分区 ID 72057594383564800 的目录条目。元数据不一致。运行 DBCC CHECKDB 以检查元数据是否损坏。

编辑#2 2015 年 8 月 6 日下午 2:24 CST - 收到信息表明，在可疑模式下恢复数据库的 .bak 文件可以解决此问题。

Answer 1

关于您的评论，我怀疑这里存在与操作相关的问题，而不是 SQL Server 引擎问题。这些 SAN 设备通常在块层上工作，并且某些设备比其他设备以及其他区域更好地管理事务日志/数据文件同步。

您可以向运营团队表明，不，SQL Server 不会像这样随机损坏数据。您可以将备份恢复到另一台服务器，设置镜像，并且所有这一切都不会损坏。当我们进行 san 级别复制时，它就会发生。如果 SQL Server 造成这样的损坏，它就不会存在。SQL Server 有近百万行代码处理损坏、修复损坏和减少损坏的可能性。您不会在任何其他环境中遇到此问题，并且只会出现 SAN 复制，对吗？

固件通常是此类问题的主要原因。请致电您的戴尔支持代表，他们将提供更多信息和故障排除。不要满足于懒惰的代表，您企业的数据和时间都处于危险之中。他们有很多工具可以检查后台导致此问题的原因，还有其他工具（例如 DPAC）可能会有所帮助。这不是 SQL Server 引擎的问题，我们需要 Ops 的全力支持。

编辑：如果您的固件已过期或不匹配，请从管理 SAN 的运维团队获取策略，其中规定他们将保持其管理的计算机堆栈中的固件为最新状态。如果此 SLA 不存在，您应该向经理记录下来，因为除此之外您还面临许多其他问题。

我假设您正在使用 SAN 块级复制。

设置通常也可能不匹配。也许不同的块大小等。但 san os 通常应该能够检测到这些问题。