web-dev-qa-db-ja.com

Checkdbの問題-重要なデータベースの2つのテーブルでの整合性エラー

昨夜ネットワークアクティビティがあり、サーバースイッチをアップグレードしていました。ネットワーク全体がダウンし、DBAはレプリケーションとバックアップのためにDBサーバーですべてのジョブを無効にすることで準備しましたが、アクティビティ中にWSFC（Windowsサーバーフェールオーバークラスター）の1つがフェールオーバーを開始し、完全に成功しなかったようです。これにより、2つのノードが稼働し、データベースとすべてのドライブが両方のサーバーにありますが、ドライブとSQLサービスはどちらか一方のみにあるはずでした。

上記の結果、多くのデータベースの破損が発生し、破損の解消に非常に苦労しました。 tempdbとmsdbで2つのユーザーデータベース以降を使用して開始した場合も破損しました。 tempdbのサービスを再起動する必要がありましたが、最後に成功したバックアップから復元されたmsdbの場合、すべてがビジネスを再開しているように見えました。

その後、すべてのデータベース（システムデータベースとユーザーデータベース）でdbcc checkdbを実行しました。システムデータベースに問題はありませんでしたが、ユーザーデータベース（クリティカル）の1つで以下のエラーが発生しています：

Command: DBCC CHECKDB ([User_DB_Critical]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, MAXDOP = 2
Msg 8914, Level 16, State 1, Server DB_Cluster_Name, Line 1
Incorrect PFS free space information for page (1:1439286) in object ID 526624919, index ID 0, partition ID 72057594055753728, alloc unit ID 72057594056933376 (type In-row data). Expected value  95_PCT_FULL, actual value  80_PCT_FULL.
Msg 8951, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: table 'Job_Execution_Log_Table' (ID 526624919). Data row does not have a matching index row in the index 'PK289' (ID 2). Possible missing or invalid keys for the index row matching:
Msg 8955, Level 16, State 1, Server DB_Cluster_Name, Line 1
Data row (1:2224:6) identified by (HEAP RID = (1:2224:6)) with index values 'JOB_NAME = 'populate_Tran_details' and START_TIME = '2019-07-03 03:42:00.323' and HEAP RID = (1:2224:6)'.
Msg 8951, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: table 'Job_Execution_Log_Table' (ID 526624919). Data row does not have a matching index row in the index 'PK289' (ID 2). Possible missing or invalid keys for the index row matching:
Msg 8955, Level 16, State 1, Server DB_Cluster_Name, Line 1
Data row (1:1395530:49) identified by (HEAP RID = (1:1395530:49)) with index values 'JOB_NAME = 'populate_Tran_details' and START_TIME = '2019-07-03 03:41:13.480' and HEAP RID = (1:1395530:49)'.
Msg 8951, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: table 'Job_Execution_Log_Table' (ID 526624919). Data row does not have a matching index row in the index 'PK289' (ID 2). Possible missing or invalid keys for the index row matching:
Msg 8955, Level 16, State 1, Server DB_Cluster_Name, Line 1
Data row (1:1439286:43) identified by (HEAP RID = (1:1439286:43)) with index values 'JOB_NAME = 'populate_Tran_details' and START_TIME = '2019-07-03 03:45:00.890' and HEAP RID = (1:1439286:43)'.
Msg 8951, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: table 'Job_Execution_Log_Table' (ID 526624919). Data row does not have a matching index row in the index 'PK289' (ID 2). Possible missing or invalid keys for the index row matching:
Msg 8955, Level 16, State 1, Server DB_Cluster_Name, Line 1
Data row (1:1439286:44) identified by (HEAP RID = (1:1439286:44)) with index values 'JOB_NAME = 'populate_Tran_details' and START_TIME = '2019-07-03 03:48:00.473' and HEAP RID = (1:1439286:44)'.
Msg 8935, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: Object ID 1374679995, index ID 1, partition ID 72057594120962048, alloc unit ID 72057596467675136 (type In-row data). The previous link (1:1685287) on page (1:491016) does not match the previous page (1:1445099) that the parent (1:232830), slot 129 expects for this page.
Msg 8937, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: Object ID 1374679995, index ID 1, partition ID 72057594120962048, alloc unit ID 72057596467675136 (type In-row data). B-tree page (1:491016) has two parent nodes (0:1), slot 0 and (1:1591622), slot 138.
Msg 8977, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: Object ID 1374679995, index ID 17, partition ID 72057594121093120, alloc unit ID 72057596467806208 (type In-row data). Parent node for page (1:692096) was not encountered.
Msg 8979, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: Object ID 1374679995, index ID 17, partition ID 72057594121093120, alloc unit ID 72057596467806208 (type In-row data). Page (1:692097) is missing references from parent (unknown) and previous (page (1:1548068)) nodes. Possible bad root entry in system catalog.
Msg 8978, Level 16, State 1, Server DB_Cluster_Name, Line 1
Table error: Object ID 1374679995, index ID 1, partition ID 72057594120962048, alloc unit ID 72057596467675136 (type In-row data). Page (1:1623651) is missing a reference from previous page (1:491016). Possible chain linkage problem.
CHECKDB found 0 allocation errors and 5 consistency errors in table 'Job_Execution_Log_Table' (object ID 526624919).
CHECKDB found 0 allocation errors and 5 consistency errors in table 'Tran_details_Table' (object ID 1374679995).
CHECKDB found 0 allocation errors and 10 consistency errors in database 'User_DB_Critical'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (User_DB_Critical).

テーブルのサイズ：

Sizes

私はマネージャーに以下のアプローチで行くことを提案しました：

  1. そのときに挿入された行を見つけて、可能であれば、上記の2つのテーブルから削除してください。
  2. 手順1が不可能な場合は、テーブルのすべてのインデックスを再構築します。再構築にはテーブルへの排他的アクセスが必要です。
  3. 再構築が機能しない場合–インデックスを削除して再作成する必要があります。これには、テーブルへの排他的アクセスが必要です。
  4. 手順3が機能しない場合は、修復再構築オプションを選択する必要があります。このオプションでは、データベース全体をシングルユーザーモードにする必要があります。つまり、この操作の実行中は誰もデータベースにアクセスできません。
  5. 手順4が機能しない場合は、repair_allow_data_lossオプションを使用する必要があります。これは時間がかかり、一貫性の問題があるデータを失う可能性があります。この場合も、データベースはシングルユーザーモードである必要があり、誰もデータベースにアクセスしないでください。

アクティビティの直前にデータベースのフルバックアップを行っていますが、アクティビティは7月3日の朝に予定されていました。すべてのデータベースの問題により、すべてのデータベースの破損がなくなり、通常どおりビジネスが開始されたときは午前6時30分になりました。 msdbおよび1つのユーザーデータベースの場合-以前のバックアップは復元にのみ使用しました。 7月3日の営業時間後にcheckdbを実行しました。つまり、データベースには1日のすべてのデータが含まれています。そのため、7月3日のバックアップをアクティビティの前に復元すると、7月3日の日中のすべてのデータが失われます。これは、ビジネスには受け入れられません。

バックアップに関するもう少し詳細を追加する-現在私はバックアップを取るためにola hallengrenスクリプトを使用しており、バックアップは昨夜正常に実行されました。以下は、バックアップを取るために使用しているパラメーターです。

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d DBA_Maintenance -Q "EXECUTE [dbo].[DatabaseBackup] @Databases = 'USER_DATABASES, -One_Heavy_Database', @Directory = N'DB_Backup_Path', @BackupType = 'FULL', @Verify = 'Y', @CleanupTime = 24, @CheckSum = 'Y', @Compress = 'Y',  @LogToTable = 'Y'" -b

確認とチェックサムフラグを使用してバックアップをチェックしています。差分バックアップは2時間ごとにスケジュールされ、ログバックアップは15分ごとに実行されます（ログ配布は構成されていますが、現時点では停止されています）。これまでのところ、バックアップの失敗や問題の報告はありません。

重いテーブルでは、3つの整合性エラーがクラスター化インデックスにあり、2つが非クラスター化インデックスにあります。最初のテーブル、つまりJob_Execution_Log_Tableには、非クラスター化インデックスに関するすべての不整合があります。

どうすればいいのか、この一貫性の問題を修正するために最も効果的で時間のかかる作業は何ですか。

現在、Paul Randalの link を使用して、それが最善の策であるかどうかを確認しようとしています。

EDIT：バックアップをプライマリサーバーからセカンダリサーバーに復元し、checkdbを実行したところ、プライマリで報告されたものと同じ一貫性エラーが見つかりました。クラスター化されていないインデックスを削除して再作成すると、4つの一貫性エラーがなくなり、残りは1つだけになります。

Incorrect PFS free space information for page (1:1439286) in object ID 526624919, index ID 0, partition ID 72057594055753728, alloc unit ID 72057594056933376 (type In-row data). Expected value  95_PCT_FULL, actual value  80_PCT_FULL.

クラスタ化インデックスで問題が発生しているため、まだ大きなテーブルには触れていません。そして、このPFS問題を修正する方法がわかりません。

あなたのアドバイスに感謝します。

バージョン：Microsoft SQL Server 2014（SP3）（KB4022619）-12.0.6024.0（X64）Sep 7 2018 2018 01:37:51 Copyright（c）Microsoft Corporation Enterprise Edition：Core-based Licensing（64-bit）on Windows NT 6.3（ビルド9600：）（ハイパーバイザー）

sql-serversql-server-2012clusteringdbcc-checkdb
2
Learning_DBAdmin

これは直接的な答えではなく、いくつかの提案です

どうすればいいのか、この一貫性の問題を修正するために最も効果的で時間のかかる作業は何ですか。

なぜバックアップからの復元について話さなかったのですか？クリーンなバックアップはありませんか？アクティビティの前にユーザーとシステムデータベースの完全なバックアップをとっていなかった場合、それは失敗でした。

バックアップがある場合は、サーバー上のバックアップから（別の名前で）復元を開始し、並行して、ステップ1/2/3で成功するかどうかを確認します。 1日の終わりにステップで失敗した場合、データベースの準備が整い、「管理ノイズ」を回避するためだけにアプリケーションをこれにポイントさせることができます。

Checkdbは最小の修復としてrepair_allow_data_lossを提案しました。本稼働データベースでこれを実行することはめったにありません。好きなものを削除する可能性があるため、ビジネス上の制約を取り除いて、ビジネスルールの範囲では基本的に役に立たないデータベースを提供します。したがって、バックアップがなく、上記のすべての手順が失敗する場合は、修復のみを使用してください。訴訟を起こしている場合は、神が一緒にいてください。

EIDT：（チャットから）

この特定のケースでは、checkdbのみがこの整合性エラーを報告しました。それ以外の場合、進行中の問題はありません。私はそれが今明らかであることを望みます。

データベースは現在機能しているが、checkdbが問題を報告していることを説明してくれてありがとう。あなたは経営陣に腐敗があり、遅かれ早かれ彼らは例外に直面し始めることを知らせなければなりません。彼らがまだこれに遭遇していないと私が思う理由は、破損したページがまだメモリに読み込まれていないためです。

あなたがすべきこと

  1. 汚職があることを関係者に知らせ、メッセージを示します。

  2. 持っているバックアップから復元を開始すると、アプリケーションを読み取り専用にする必要がある場合もあります。どれだけの違いがあるか見てください

  3. 失敗した場合は、現在破損しているデータベースのバックアップをとってみてくださいcontinue_after_errorを使用してください。破損があると、バックアップが失敗する可能性が高くなります。正常にcontinue_after_errorで復元し、repair_allow_data_lossを実行して、失われるデータの量を確認します。

  4. したがって、2つのテーブルが問題を引き起こしていることがわかりました。これらの2つのテーブルから別のテーブルにデータを移動してみて、移動できるデータ量を確認します（old_table_tempのような新しいテーブルを作成します）。私が言っているのは、これらの2つのテーブルからほとんどのデータを移動でき、これが破損の影響を受けていると確信できる場合は、これらのテーブルを削除し、他のテーブルに移動したデータから再作成することです。

  5. テーブルを削除して再作成し、新しいデータを入れたら、checkdbを再度実行して、クリーンになるかどうかを確認します。

  6. 復元されたバックアップから、削除されたデータを取得できるかどうかを確認します。

  7. インデックスを削除して再作成しても、インデックスがクラスター化されたインデックスに対してクラスター化されていない場合、問題は修正される可能性が高く、問題は修正されません。

編集：

差分バックアップは2時間ごとにスケジュールされ、ログバックアップは15分ごとに実行されます（ログ配布は構成されていますが、現時点では停止されています）。これまでのところ、バックアップの失敗や問題の報告はありません。

ログシッピングがあり、データベースが読み取り専用/スタンバイモードであることを望んでいます。それが非常に良い場合は、すべてのLSジョブを直ちに停止してください。復元モードでEnterprise Editionを使用している場合は、スナップショットを作成して、checkdbを実行します。アプリケーションのダウンタイムを取り、セカンダリデータベースでcheckdbを実行します。問題がなければ、オンラインにして、アプリケーションをこのDBにポイントすると、これで問題がなくなり、データ損失がゼロになります。

重いテーブルでは、3つの整合性エラーがクラスター化インデックスにあり、2つが非クラスター化インデックスにあります。最初のテーブル、つまりJob_Execution_Log_Tableには、非クラスター化インデックスに関するすべての不整合があります。

NCIを試してみて、問題が解決するかどうかを確認できますが、セカンダリデータベースに依存しているため、破損が伝播しないことを願っています。

私はそれが多くの仕事であることを知っていますが、これはあなたにあなたが可能な限りデータ損失を与えると私が信じるものです。

幸運を

2
Shanky