(一个人按了绿色按钮而不是蓝色按钮,他原来的目标还剩下三个机架,可能绿色比蓝色更好,在这个 SAN 上保存了数据库文件)
在这次事故之后,我正在对数据库进行一致性检查
但其中一个数据库返回一致性错误
失败:(-1073548784) 执行查询“DBCC CHECKDB(N'XxxXxxx') WITH NO_INFOMSGS”失败,出现以下错误:“数据库 ID 9 中的范围 (1:511776) 在 GAM 中标记为已分配,但没有 SGAM 或 IAM已分配它。数据库 ID 9 中的 Extent (1:511784) 在 GAM 中标记为已分配,但没有 SGAM 或 IAM 分配它。
. . .
数据库 ID 9 中的范围 (1:994048) 在 GAM 中标记为已分配,但没有 SGAM 或 IAM 分配它。索引分配映射 (IAM) 页 (0:0) 由对象 ID 0、索引 ID -1、分区 ID 0、分配单元 ID 72057594374717440 (类型未知) 中的 IAM 页 (1:3318703) 的前一个指针指向,但在扫描中未检测到。CHECKDB 发现 32446 个分配错误和 0 个与任何单个对象无关的一致性错误。CHECKDB 在数据库“XxxXxx”中发现 32446 个分配错误和 0 个一致性错误。
repair_allow_data_loss 是 DBCC CHECKDB (XxxXxx) 发现的错误的最低修复级别。”。可能的失败原因:查询问题、“ResultSet”属性设置不正确、参数设置不正确或连接未正确建立。
UAT 看起来很成功,没有数据丢失
例外是(我问这个问题的原因)分配硬盘上的新空间
我的问题是
我可以运行标准修复数据库吗(将是我的第一次尝试)
搜索详细信息,并针对具体表运行此修复
从备份集构建数据库,然后导入新数据(可以,在此数据库中存储数据快照)
编辑
对于未来的读者,在我的案例中存在一些问题,(DBCC CHECKTABLE 成功通过,没有任何例外)
SQL Server(2008_R2/2012_R2)使用 DBCC CHECKDB(DbName, REPAIR_ALLOW_DATA_LOSS) ... 仅修复部分错误。
我必须运行这个过程四次(分配的 GAM 数量减少),最后一次运行解决了这个问题,
有趣的是,SQL Server 2008_R2 和 2012_R2 都具有相同的进程,但具有相同的异常、异常数量、所需修复的数量、非常相似的性能(一个环境有两个不同的实例)