问真正的腐败？

EN

我们有一个太阳风猎户座网络性能监视器的生产数据库，在该数据库中，我们在MapStudioFiles表中发现了DBCC CHECKDB错误之后的损坏。

CHECKDB输出：

Msg 8961，级别16，状态1，表错误:对象ID 747149707，索引ID 1，分区ID 72062477575258112，分配单元ID 72057594049724416 (键入LOB数据)。页(1:3414)、插槽0、文本ID 1031262163304448的脱机数据节点与页(1:412)、插槽22中的引用不匹配。Msg 8961，级别16，状态1，表错误:对象ID 747149707，索引ID 1，分区ID 72062477575258112，分配单元ID 72057594049724416 (键入LOB数据)。页( 1 :160077)、插槽0、文本ID 1026498368241664的脱机数据节点与页( 1 :408)、槽11中的引用不匹配。Msg 8929、级别16、状态1、第1行对象ID 747149707、索引ID 1、分区ID 72062477575258112、分配单元ID 72062476506234880 (输入-行数据)：在行外数据中发现的错误，其ID为182073438109696，由RID = (1:408:11) Msg 8929、级别16、状态1、一行对象ID 747149707、索引ID 1、分区ID 72062477575251121、分配单元ID 72062476506234880 (输入行数据)：在由RID = (1:412:22)标识的数据记录拥有ID 186837233172480的脱机数据中发现的错误，CHECKDB在表'MapStudioFiles‘中发现了0个分配错误和4个一致性错误(对象ID 747149707)。CHECKDB在数据库OrionNPM中发现了0个分配错误和4个一致性错误。repair_allow_data_loss是DBCC (OrionNPM)发现的错误的最小修复级别。

我们没有有效的备份，因为这个错误似乎发生了很长时间，但是由于服务器不在我们的监控工具上，没有人注意到DBCC作业上的错误，并且没有任何电子邮件在失败时发送。

在测试服务器上，我们还原了一个备份，只为了检查修复允许数据丢失方法，而DBCC CheckTable能够修复两行(被删除的行)。

CHECKTABLE修正了表'MapStudioFiles‘中的0个分配错误和2个一致性错误(对象ID 747149707)。

然后在第二次执行之后，所有的问题都解决了。表在修复之前有251行中的249行。

另一个测试中的

：

我注意到，如果您查询执行select的表，则不会收到任何错误，并显示表上的所有数据。(这是因为腐败出现在LOB列上吗？)

因此，我的第一个想法是将表复制到另一个表中，以查看是否出现任何错误。我在使用SELECT INTO时没有遇到任何问题，在运行DBCC CHECKTABLE之后，一切正常，新表有251行。

这是否意味着腐败已经消失？或者因为它位于LOB列上，所以只有在尝试将对象从数据库中取出或应用程序查询表时才会看到这个问题？