By: Brady Upton｜更新しました。 2016-07-26｜ コメント (2) ｜ 関連記事 その他の > データベース コンソール コマンド DBCCs

Problem

SQL Server データベース破損は問題であり、データベースに深刻な損害を与える可能性があります。 経験豊富な DBA であれば、これを検出するためのセーフガードを持っていると思いますが、長年にわたり、検出方法がまったくない何百もの SQL Server を見てきており、これは問題だと思います。 データベースの破損を検出する方法はいくつかありますが、このヒントでは DBCC CHECKDB.

Solution

DBCC (database console commands) 文を聞いたことがあるかもしれませんし、ないのかもしれません。 これらのステートメントは、データベース内のperformdifferent操作に使用され、4つのカテゴリに分けることができます：メンテナンス、その他、情報提供、および検証。 私は日常的に DBCC 文を使用していますが、DBCC CHECKDB.

What is SQL Server DBCC CHECKDB

DBCC CHECKDB, fromMicrosoft MSDN Library, check the logical and physical integrity of all the objects in the specified database by performing a following operations:

  • Runs DBCC CHECKALLOC on the database – Check consistent of disk spaceallocation structures for the specified database.DBC は、指定したデータベースについて、ディスク領域の割り当て構造の整合性を確認するものです。
  • Runs DBCC CHECKTABLE on every table and view in the database – テーブルまたはインデックス付きビューを構成するすべてのページと構造の整合性をチェックします。
  • データベース上で DBCC CHECKCATALOG を実行 – データベース内のカタログの整合性をチェックします。
  • データベース内のすべてのインデックス付きビューの内容を検証します。
  • FILESTREAMを使ってファイルシステム内にバイナリ（最大）データを格納する場合、テーブルメタデータとファイルシステムのディレクトリおよびファイル間のリンクレベルの整合性を検証します。
  • データベース内のサービス ブローカー データを検証します

DBCC CHECKDB を実行したことがあるなら、大規模データベースでは多少時間がかかることを知っているはずです。 データ破損は、不正なデータ結果、失敗した SQL 文、場合によっては SQL インスタンス全体の停止など、データベース内のあらゆる種類の問題を引き起こす可能性があります。 DBCC CHECKDB は破損を警告するので、ひどくなる前に（できれば）修正することができます。

SQL Server DBCC CHECKDB の使用方法

DBCC CHECKDB は非常に簡単です。 ステートメントで使用できるオプションがいくつかあり、次のセクションでそのいくつかを説明しますが、基本的な構文は次のようになります。

Automate SQL Server DBCC CHECKDB

もちろん、毎朝ログインして各データベースでこのステートメントを実行したいとは思わないので、いくつかの異なる方法を使用してこのプロセスを自動化することができます。 私は、ほとんどの場合、保守計画を使用するのは好きではありませんが、この種のタスクのために使用するのは構わないと思っています。 メンテナンスプランのツールボックスでは、データベースの整合性をチェックするタスクを使用する必要があります。 設定可能なオプションはインデックスを含めることだけなので、あまり使い勝手はよくありませんが、場合によっては、これだけで済むこともあります。 6264>

  • カスタム スクリプト – カスタム スクリプトは通常私が使用しているもので、必要なオプションを追加する限り最高の柔軟性を提供します。 私の Go-Toscripts は、Ola Hallengren からすでに作成されており、無料で使用できます。 彼は、これらのスクリプトを作成し、世界に提供する素晴らしい仕事をしています。 ありがとう、オラ！
    • MSSQLTips でスクリプトをチェックする。com:
    • Perform Maintenance with SQL Server Databases in Full Recovery mode
    • SQL Server Database Maintenance Plans and Backup File Management
    • Performing SQL Server Maintenance with No Maintenance Window

    SQL Server DBCC CHECKDB Options

    DBC CHECKDB で使用するいくつかのオプションがありますが、ここではその中から人気のものをいくつか説明したいと思います。

    • NOINDEX – ユーザー・テーブルの非クラスタ化インデックスの集中的なチェックを実行しないように指定します。 これにより、オーバーアレックスの実行時間が短縮されます。 NOINDEXはシステム・テーブルには影響しません。なぜなら、整合性チェックは常にシステム・テーブル・インデックスに対して実行されるからです。
    • NO_INFOMSGS – すべての情報メッセージを抑制します。 このチェックは、データベースの物理的な整合性の小さなオーバーヘッド・チェックを提供するように設計されていますが、破れたページ、チェックサムの失敗、およびユーザーのデータを危険にさらす可能性のある一般的なハードウェア障害も検出することが可能です。 これには、データベースに対する短期排他 (X) ロックが含まれます。 TABLOCK は、高負荷のデータベースで DBCC CHECKDB をより速く実行しますが、DBCC CHECKDB の実行中にデータベースで利用できる同時実行数を減らします。
    • DATA_PURITY – DBCC CHECKDB に、有効ではないまたは範囲外の列値をデータベースで確認させる機能です。 たとえば、DBCC CHECKDBは、datetimeデータ型の許容範囲より大きい、または小さい日付と時刻の値を持つ列、または有効でないスケール値または精度値を持つ10進数または近似数値データ型の列を検出します。

    以下の別のセクションでREPAIRオプションのいくつかを説明します。 冗談です。

    毎日のメンテナンス ウィンドウがある場合、データの破損を毎日チェックするのは良いことだと思います。 より早く発見できれば、害は少なくなるかもしれません。 特に大規模なデータベースでは、多くの人が週末にこれを実行していることに気づきました。 これには善悪はなく、定期的にスケジュールされていることを確認するだけです。

    Do I have to run DBCC CHECKDB in my Production environment? データの破損をチェックするために、テスト環境で DBCC CHECKDB を実行しても意味がありません。 BRILLIANT!

    AlwaysOn や LogShipping などのいくつかの HA オプションが適切かどうか疑問に思うかもしれませんね？

    DBCC CHECKDB が構成され、実行されている今、私は何を探しているのでしょうか。 あなたは DBCC CHECKDB を自動化して実行しましたが、次は何でしょうか。 SQL ServerAgentジョブがセットアップされている場合、そのジョブでデータベース・メール、オペレータ、および通知をセットアップすることを確認します。 ジョブが成功した場合、その後withyour美しい一日に運ぶ。

    次のようなエラーが表示されることがあります。

    The In-row data USED page count for object “tablename”, index ID 2, partitionID 608313809829888, alloc unit ID 608313809829888 (type In-row data) is incorrect.Run DBCC UPDATEUSAGE.DBCC UPDATEUSAGE. (エラー2508）オブジェクト “tablename”、インデックスID 2、par…の行内データRSVDページカウントが正しくありません。 ステップに失敗しました。

    またはこれ:

    Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unitID 72345201051571606 (type In-row data).RSVDページカウントが正しくありません。 ページ(1:94299)を処理できませんでした。詳しくは他のエラーをご覧ください。 Msg 8939, Level 16, State 98, Line 1 Table error:Object ID 2088535921, index ID 0, partition ID 72345201021503994, alloc unitID 72345201051571606 (type In-row data), page (1:94299).Alloc unitID 72345201051571605 (type In-row data). テスト（IS_OFF（BUF_IOERR,pBUF->bstat））は失敗しました。 CHECKDB はテーブル ‘tablename’ (オブジェクト ID 2088535921) で 0 個のアロケーション・エラーと 2 個のコンシステンシー・エラーを発見しました。 repair_allow_data_loss は DBCC CHECKDB (Database) で見つかったエラーの最小修復レベルです。

    まず、パニックにならないでください。 第二に、バックアップを確認します。 DBCC CHECKDBエラーは、通常、何を行う必要があるかを教えてくれます。

    最初のエラーでは、DBCC UPDATEUSAGE がカタログ ビューのページと行数の不正確さを修正します。 かなり無害です。

    2番目のエラーは、データ破損を報告します。 このエラーでは、最小の修復レベルとして repair_allow_data_loss を使用することに言及しています。 つまり、この引数でステートメントを実行することはできますが、データを失う可能性があります。 このため、可能であれば常にバックアップに復元することをお勧めします。 バックアップに破損したデータが含まれていないことを確認し、データ損失がないことを確認する必要があります。

    How to repair a SQL Server database

    バックアップがない場合、修復オプション付きの DBCC CHECKDB を使用する必要があるかもしれません。

    • REPAIR_ALLOW_DATA_LOSS – 報告されたすべてのエラーを修復しようとします。これらの修復により、データが失われる可能性があります。 これには、非クラスタ化インデックスの欠落行の修復などの迅速な修復や、インデックスの再構築などのより時間のかかる修復が含まれます。

    上で述べたように、破損から回復するために最大限のバックアップを行うことが非常に重要です。 破損は、どれだけ多くのデータを持っているか、どのバージョンの SQL を実行しているか、またはデータセンターがどれだけ豪華であるかには関係ありません。

    これでかなり良くなったと思いますが、SQL インスタンスを保護するために他に何を使用できますか?

    DBCC CHECKDB はすべての SQL インスタンスで実行すべきですが、データ破損の検出や防止に役立つ他の方法がいくつかあります。 SQL 2005 またはそれ以下を実行している場合、これは利用できませんが、アップグレード後にこの設定を変更することを確認してください。 ページ検証の設定を確認するには、次のステートメントを使用します。 

select name, page_verify_option_desc from sys.databases
Next Steps
  • 詳細については、MSDN Library で DBCC CHECKDB
  • MSSQLTips.com には、役に立つかもしれない onDatabase Consistency Checks についての素晴らしいヒント集が掲載されています。 2016-07-26

    著者について
    Brady Upton はテネシー州ナッシュビルのデータベース管理者と SharePoint スーパースターである。
    私のヒントをすべて見る
    関連リソース

    • More SQL Server DBA Tips…

By: adminPosted on

コメントを残す

メールアドレスが公開されることはありません。