本当の腐敗？
Solarwinds Orion Network Performance Monitorの本番データベースがあり、DBCC CHECKDBエラーの後にMapStudioFilesテーブルで破損が検出されました。
CHECKDB出力：
メッセージ8961、レベル16、状態1、行1テーブルエラー：オブジェクトID 747149707、インデックスID 1、パーティションID 72062477575258112、割り当てユニットID 72057594049724416（タイプLOBデータ）。ページ（1：3414）、スロット0、テキストID 1031262163304448の行外データノードが、ページ（1：412）、スロット22からの参照と一致しません。
メッセージ8961、レベル16、状態1、行1テーブルエラー：オブジェクトID 747149707、インデックスID 1、パーティションID 72062477575258112、割り当てユニットID 72057594049724416（タイプLOBデータ）。ページ（1：160077）、スロット0、テキストID 1026498368241664の行外データノードが、ページ（1：408）、スロット11からの参照と一致しません。
メッセージ8929、レベル16、状態1、行1オブジェクトID 747149707、インデックスID 1、パーティションID 72062477575258112、割り当てユニットID 72062476506234880（タイプ行内データ）：識別されたデータレコードが所有するID182073438109696の行外データでエラーが見つかりましたRID =（1：408：11）
メッセージ8929、レベル16、状態1、行1オブジェクトID 747149707、インデックスID 1、パーティションID 72062477575258112、割り当てユニットID 72062476506234880（タイプ行内データ）：識別されたデータレコードが所有するID186837233172480の行外データでエラーが見つかりましたRID =（1：412：22）
CHECKDBは、テーブル 'MapStudioFiles'（オブジェクトID 747149707）で0個の割り当てエラーと4個の整合性エラーを検出しました。 CHECKDBは、データベース 'OrionNPM'で0個の割り当てエラーと4個の整合性エラーを検出しました。 repair_allow_data_lossは、DBCC CHECKDB（OrionNPM）によって検出されたエラーの最小修復レベルです。
このエラーは長い間発生していたようですが、サーバーがモニターツール上になかったため、DBCCジョブのエラーに誰も気付かず、電子メールもありませんでした。失敗時に送信されます。
TESTサーバーでは、修復許可データ損失メソッドを確認するためだけにバックアップを復元し、DBCC CheckTableは2つの行（削除された行）を修正できました。
CHECKTABLEは、テーブル 'MapStudioFiles'（オブジェクトID 747149707）の0個の割り当てエラーと2個の整合性エラーを修正しました。
そして、2回目の実行後、すべての問題が修正されました。テーブルには、修復前の251行から249行があります。
別のテストで：
selectを実行してテーブルにクエリを実行してもエラーは発生せず、テーブル上のすべてのデータが表示されることに気付きました。 （これは破損がLOB列にあるためですか？）
したがって、私の最初の考えは、テーブルを別のテーブルにコピーして、エラーが発生するかどうかを確認することでした。 SELECT INTOを使用して問題なく実行できました。その後、DBCC CHECKTABLEを実行すると、すべて問題なく、新しいテーブルには251行が含まれています。
これは、腐敗がなくなったことを意味しますか？または、LOB列にあるため、データベースからオブジェクトを取得しようとした場合、またはアプリケーションがテーブルにクエリを実行した場合にのみ問題が発生しますか？
腐敗はなくなりましたか？
DBCC CHECKDBがエラーを返さない場合、破損は解消されています。
CHECKDBは、データベース「BFEnterprise」で0個の割り当てエラーと0個の整合性エラーを検出しました。
データの損失は問題ですか？
これが本当の質問です。伝える唯一の方法は、システムでテストすることです。おそらく、修復によってデータが削除される前に破損したデータが問題を引き起こしていなかった場合、データが失われたとしても問題は発生しません。
最適には、専用のテストシステムでテストすることをお勧めします。