web-dev-qa-db-ja.com

SQL Server 2016 Enterpriseのパフォーマンスが低い

長くなって申し訳ありませんが、分析に役立つように、できるだけ多くの情報を提供したいと思います。

同様の問題のある投稿がいくつかあることは知っていますが、これらのさまざまな投稿やWebで入手可能なその他の情報をすでにフォローしていますが、問題は残っています。

SQL Serverのパフォーマンスに深刻な問題があり、ユーザーを狂わせています。この問題は数年間続き、2016年末までは別のエンティティによって管理され、2017年からは私が管理するようになりました。

2017年の半ばに、Microsoft SQL Server 2012パフォーマンスダッシュボードレポートに示されているインデックス付けのヒントに従って問題を解決することができました。効果はすぐに現れ、魔法のように聞こえました。最後の日にほとんど常に100％であったプロセッサは、非常に穏やかになり、ユーザーのフィードバックが鳴っていました。私たちのERP=技術者も、特定のリストを取得するのに通常20分かかり、最後に数秒でそれを行うことができたので、喜んでいました。

しかし、時間の経過とともに、それは徐々に悪化し始めました。インデックスが多すぎるとパフォーマンスが低下するのではないかと心配して、インデックスの作成を避けました。しかし、ある時点で、不要なものを削除して、Performance Dashboardが提案する新しいものを作成する必要がありました。しかし、影響はありません。

ERPでの保存とコンサルティングの際に感じるのは、本質的に遅いことです。

次の構成のSQL Server 2016 Enterprise（64ビット）専用のWindows Server 2012 R2があります。

  • CPU：Intel Xeon CPU E5-2650 v3 @ 2.30GHz
  • メモリ：84 GB
  • ストレージに関しては、サーバーにはオペレーティングシステム専用のボリューム、データ専用のログ、およびログ専用のボリュームがあります。
  • 17データベース
  • ユーザー：
    • 最大のDBでは、多かれ少なかれ113人のユーザーが同時に接続されています
    • 他には約9人のユーザーがいます
    • それらの2つで3 + 3
    • 残りのユーザーはそれぞれ1人だけです
    • 大規模なデータベース用に作成するWebもありますが、使用頻度ははるかに低く、ユーザー数は約20人です。
  • DBのサイズ：
    • 最大のデータベースは290 GBです。
    • 2番目に大きいものは100 GB
    • 3番目に大きいものは20 GB
    • 4番目の14 GB
    • 残りはそれぞれ3 GBを少し超えています

これは本番環境のインスタンスですが、ほとんどの場合私がそこに接続しているだけなので、この目的のために無視できると思われる開発のインスタンスもありますが、この問題は、接続していない場合でも常に発生します。

プロセッサーはほとんど常に次のようなものです。

enter image description here

夜間に実行するルーチン（問題はありません）と日中に実行するルーチンがあります。

ユーザーは、リモートデスクトップを介して、ODBC 32で構成されている他のマシンに接続し、SQL Serverにアクセスします。

サーバーが配置されているデータセンターには、100/100 Mbpsと私がいる場所があります。ほとんどのサイトはMPLSでリンクされており、他のサイトはIPSecでリンクされています（FOから4Gまで）。プロバイダーは多くの分析を行い、回線は問題ありません。

キャッシュヒット率は99％（ユーザーリクエストとユーザーセッションの両方）

待機は次のようになります。

enter image description here

私はすでにPerfmonでデータを収集しており、それがあなたの分析に役立つ場合は結果が得られます-個人的には、分析から何の結論も得られませんでした。

この問題を解決するためのサポートに期待しており、解決に必要と思われる情報を提供することができます。

どうもありがとうございました。

これがsp_blitzマークダウンです（会社名を仮名に置き換えました）。

優先度1：信頼性：

  • 2週間以上前の最後の良いDBCC CHECKDB

    • 主人

    • モデル-最後に成功したCHECKDB：2018-02-07 15：04：26.560

    • msdb-最後に成功したCHECKDB：2018-02-07 15：04：27.740

優先度10：パフォーマンス：

  • コア数が奇数のCPU

    • ノード0には5つのコアが割り当てられています。これは本当に悪いNUMA構成です。

    • ノード1には5つのコアが割り当てられています。これは本当に悪いNUMA構成です。

優先度20：ファイル構成：

  • CドライブtempdbのTempDB-tempdbデータベースには、Cドライブにファイルがあります。 TempDBは予期せず頻繁に増大し、サーバーがCドライブの空き容量を使い果たして激しくクラッシュする危険にさらされます。 Cは他のドライブよりもかなり遅いことが多いため、パフォーマンスが低下する可能性があります。

優先度50：信頼性：

  • デフォルトのトレースで最近記録されたエラー
    • master-2018-03-07 08：43：11.72ログオンエラー：17892、重大度：20、状態：1. 2018-03-07 08：43：11.72トリガーの実行が原因で、ログイン 'example_user'のログオンログオンが失敗しました。 [クライアント：IPADDR]

（注：ユーザーセッションを制限するトリガーが有効になっているため、このような多くのエラー-ERPライセンス使用制御）

  • ページ検証が最適ではありません

    • DATABASE_A-データベース[DATABASE_A]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_B-データベース[DATABASE_B]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_C-データベース[DATABASE_C]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_D-データベース[DATABASE_D]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_E-データベース[DATABASE_E]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_F-データベース[DATABASE_F]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_G-データベース[DATABASE_G]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_H-データベース[DATABASE_H]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_I-データベース[DATABASE_I]のページ検証はありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_Z-データベース[DATABASE_Z]のページ検証はありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_K-データベース[DATABASE_K]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_J-データベース[DATABASE_J]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_L-データベース[DATABASE_L]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_M-データベース[DATABASE_M]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_O-データベース[DATABASE_O]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_P-データベース[DATABASE_P]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_Q-データベース[DATABASE_Q]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_R-データベース[DATABASE_R]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_S-データベース[DATABASE_S]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_T-データベース[DATABASE_T]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_U-データベース[DATABASE_U]には、ページ検証のためのNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_V-データベース[DATABASE_V]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

    • DATABASE_X-データベース[DATABASE_X]には、ページ検証用のNONEがありません。 SQL Serverでは、ストレージの破損を認識して回復するのが困難な場合があります。代わりにCHECKSUMの使用を検討してください。

  • リモートDACが無効-専用管理接続（DAC）へのリモートアクセスが有効になっていません。 DACを使用すると、SQL Serverが応答しない場合のリモートトラブルシューティングがはるかに簡単になります。

優先度50：サーバー情報：

  • インスタントファイルの初期化が有効になっていません-IFIを有効にして、リストアとデータファイルの増大を高速化することを検討してください。

優先度100：パフォーマンス：

  • 変更されたフィルファクター

    • DATABASE_A-[DATABASE_A]データベースには、Fill Factor = 70％の417個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_B-[DATABASE_B]データベースには、フィルファクタ= 70％の318個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_C-[DATABASE_C]データベースには、Fill Factor = 70％の346個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_D-[DATABASE_D]データベースには、フィルファクタ= 70％の663個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_E-[DATABASE_E]データベースには、フィルファクタ= 70％の335個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_F-[DATABASE_F]データベースには、フィルファクタ= 70％のオブジェクトが1705個あります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_G-[DATABASE_G]データベースには、フィルファクタ= 70％の671個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_H-[DATABASE_H]データベースには、Fill Factor = 70％の2364個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_I-[DATABASE_I]データベースには、FILL FACTOR = 70％の1658個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_Z-[DATABASE_Z]データベースには、フィルファクタ= 70％の673個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_K-[DATABASE_K]データベースには、フィルファクタ= 70％のオブジェクトが312個あります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_J-[DATABASE_J]データベースには、フィルファクタ= 70％の864個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_L-[DATABASE_L]データベースには、フィルファクタ= 70％の1170個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_M-[DATABASE_M]データベースには、フィルファクタ= 70％の382個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_O-[DATABASE_O]データベースには、フィルファクタ= 70％の356個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • msdb-[msdb]データベースには、Fill Factor = 70％の8つのオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_P-[DATABASE_P]データベースには、フィルファクタ= 70％の291個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_Q-[DATABASE_Q]データベースには、フィルファクタ= 70％の343個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_R-[DATABASE_R]データベースには、フィルファクタ= 70％の2048個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_S-[DATABASE_S]データベースには、フィルファクタ= 70％の325個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_T-[DATABASE_T]データベースには、フィルファクタ= 70％の322個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_U-[DATABASE_U]データベースには、フィルファクタ= 70％の351個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_V-[DATABASE_V]データベースには、フィルファクタ= 70％のオブジェクトが312個あります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • DATABASE_X-[DATABASE_X]データベースには、フィルファクタ= 70％の352個のオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

    • tempdb-[tempdb]データベースには、Fill Factor = 70％の2つのオブジェクトがあります。これにより、メモリとストレージのパフォーマンスの問題が発生する可能性がありますが、ページの分割が妨げられることもあります。

  • 1つのクエリの多くのプラン-20763プランは、プランキャッシュ内の1つのクエリに対して存在します。つまり、おそらくパラメーター化の問題があります。

  • サーバートリガー有効-サーバートリガー[connection_limit_trigger]が有効です。そのトリガーが何をしているのかを理解していることを確認してください-トリガーが少ないほど良いです。

  • RECOMPILE付きのストアドプロシージャ

    • master-[master]。[dbo]。[sp_AllNightLog]は、ストアドプロシージャコードにWITH RECOMPILEが含まれているため、コードが常に再コンパイルされるため、CPU使用率が増加する可能性があります。

    • master-[master]。[dbo]。[sp_AllNightLog_Setup]は、ストアドプロシージャコードにWITH RECOMPILEが含まれているため、コードが常に再コンパイルされるため、CPU使用率が増加する可能性があります。

優先度110：パフォーマンス：

  • クラスタ化インデックスのないアクティブテーブル

    • DATABASE_A-[DATABASE_A]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_B-[DATABASE_B]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_C-[DATABASE_C]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_E-[DATABASE_E]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_F-[DATABASE_F]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_H-[DATABASE_H]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_I-[DATABASE_I]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_K-[DATABASE_K]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_O-[DATABASE_O]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_Q-[DATABASE_Q]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_S-[DATABASE_S]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_T-[DATABASE_T]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_U-[DATABASE_U]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_V-[DATABASE_V]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

    • DATABASE_X-[DATABASE_X]データベースには、アクティブに照会されているヒープ（クラスター化インデックスのないテーブル）があります。

優先度150：パフォーマンス：

（注：ここではアドバイスはありませんが、文字の制限のために含めることができませんでした。他に共有する方法がある場合は、その旨をお知らせください。）

sql-serverperformancesql-server-2016enterprise-edition
8
Nelson Lopes

非常に有用で、私が適用した、または適用するすべての回答を無視しないで、最大の問題を見つけるのは簡単ではありませんでした。

私たちの最後のメッセージの後の数日で問題は悪化しました。

私たちはクラウドを基盤としているため、私も、インフラストラクチャを管理してサポートを提供する会社も、物理ホストにアクセスできません。

ワークロードがまったく同じではありませんが、似ている場合、プロセッサの平均が20％である日と60％を超えるはるかに高い日があることに気づいたとき、何かが不思議に思いました。同じタイプの操作を実行している人の数は同じです。

今週初め、ユーザーは数分間行き詰まり始め、プロセッサーのみが絞め殺されました。複数のユーザーにログアウトするように依頼しました（リソースをより多く消費しているが、それでも異常なことはありません）、データベースにリンクされているさまざまなサービスをオフにしたところ、結局何も変わっていません。私たちをサポートしていて、クラウドの人たちと通信して自分のマシンから離れているシステム管理者に、私が見ているものを確認し、何かを見つけるのを手伝ってくれるように頼みました。

技術者も何も見つかりませんでした。彼はようやく、何か他のことがこの問題を引き起こしているに違いないと私に何らかの理由を与え始めました、そして彼がクラウドに連絡したときでした。クラウドでは何も実現しませんでした。物理ホスト間に負荷分散が設定されているため、SQL ServerをサポートするVMが物理ホスト間でその日に数回移動されました。幸い、私は技術者に正確にその日に問題が発生し始めた時刻を伝えました。これは、VMが最後に物理ホストの1つに移動された時刻と一致しました。残りの時間はありません。

技術者がこの問題を綿密に追跡していなかった場合、これは、クラウドの担当者と話すこともできたときの1つになるはずですが、パフォーマンスサンプルを見ても何も得られませんでした。 CPUが40/50％のサンプル、実際には平均で80％を超え、多くの場合100％でスタックしている。

現在、マシンは物理ホスト上に立っており（ホスト間を移動していません）、まだ完全なパフォーマンスを達成していませんが、すべてのユーザーと平均CPUが約20％であるため、誰もが作業し、より多くの肯定的なフィードバックを提供しています。サービス。

その間、tempdbを別のディスク（オペレーティングシステムディスク上）に置き、CPUのコア数とより一致するようにファイルを増やしました。

コアの数も、sp_Blitzの推奨に基づいて調整されました。

また、古い日付に基づいて終日実行される自動ルーチンもありました...そして、到着したときに午前中に終了していなかったため、実行中かどうかを確認する方法がないため、私はまだ開始しました手動で実行します。しかし、おそらくもう一方はまだ実行中で、その間2回実行されていました。所要時間を短縮するために日付を変更しましたが、現在は夜遅くになっています。しかし、ここで説明したような多くの問題の前に解決されたため、これは解決策ではありませんでした。

また、ERPアシスタントに製造業者との会議をスケジュールするためのアシスタントを提供することもできました。そのため、システムを表示し、提案を探すとともに、いくつかの疑問を明確にします。 Priority Boost onやFill Factor 70％など、Microsoft自体を含むほとんどの推奨事項に反するトレーニングビデオ。

アプリケーションにはメンテナンス画面もあるので、これらのメンテナンスに必要な定期性と、アプリケーションの外部で何をするかを探します。私の考えは、オラハレングレンの計画を使用することです。

私はThomas Kronawitterの答えが完全に正しいと信じています。私はそれを適用します。ただし、この説明は他の人々にとって重要であると思います。物理ホストにある可能性があるため、すべての優れた実践に従っても問題を解決できない。トーマスに感謝します。

3
Nelson Lopes

あなたは私たちに長い（そして非常に詳細な）質問をしました。今、あなたは長い答えを扱わなければなりません。 ;）

サーバーで変更することをお勧めします。しかし、最も差し迫った問題から始めましょう。

1回限りの緊急対策：

システムにインデックスをデプロイした後のパフォーマンスが満足のいくものであり、パフォーマンスが徐々に低下していたという事実は、統計の維持を開始し、（それほどではないが）インデックスのフレーム化に注意する必要があるという非常に強いヒントです。

緊急対策として、すべてのデータベースで統計情報を一度更新することをお勧めします。次のスクリプトを実行すると、必要なTSQLを取得できます。

_DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB
_

Tim Fordがmssqltips.comの blogpost で提供しており、統計の更新が重要である理由も説明しています。

これはCPUであり、IO集中的なタスクであり、業務時間中に行うべきではないことに注意してください。

これで問題が解決した場合は、そこで停止しないでください！

定期メンテナンス：

Ola Hallengren Maintenance Solution を見て、少なくともこの2つのジョブを設定します。

  • 統計更新ジョブ（可能であれば毎晩）。このCMDコードをエージェントジョブで使用できます。このジョブは最初から作成する必要があります。

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

  • インデックスのメンテナンスジョブ。毎月1回、スケジュールされた実行から始めることをお勧めします。 OlaがIndexOptimizeジョブに提供するデフォルトから始めることができます。

統計を個別に更新する最初のジョブを提案しているいくつかの理由があります。

  • インデックスの再構築は統計を更新しませんが、インデックスの再構築はそのインデックスがカバーする列の統計のみを更新します。 Olaはフラグメンテーションを3つのカテゴリに分けます。デフォルトでは、カテゴリの高いインデックスのみが再構築されます。
  • インデックスでカバーされていない列の統計は、IndexOptimizeジョブによってのみ更新されます。
  • 昇順キーの問題 を緩和するには。

SQL Serverは、デフォルトが有効のままになっている場合、統計を自動更新します。それに関する問題はしきい値です（SQL Server 2016の問題は少ない）。特定の数の行が変更されると、統計が更新されます（SQL Serverの以前のバージョンでは20％）。大きなテーブルがある場合、統計が更新される前にこれは多くの変更になる可能性があります。しきい値についての詳細情報 ここ を参照してください。

あなたがCHECKDBをやっているので、私の知る限り、以前と同じようにそれを続けることができるか、またはそのための保守ソリューションも使用します。

インデックスの断片化とメンテナンスの詳細については、以下を参照してください。

SQL Serverインデックスの断片化の概要

SQL Serverの断片化の心配をやめる

ストレージサブシステムを考えると、データがSANとにかく順番に保存されていないため、「外部の断片化」には固執しないことをお勧めします。

設定を最適化します

Sp_Blitzスクリプトは、開始するための優れたリストを提供します。

優先度20：ファイル構成-CドライブのTempDB：ストレージ管理者に相談してください。 CドライブがSQL Serverで使用可能な最速のディスクかどうかを尋ねます。そうでない場合は、tempdbをそこに配置してください...期間。次に、temdbファイルの数を確認します。答えが1つの場合 それを修正 。それらが同じサイズでない場合は、その2つを修正します。

優先度50：サーバー情報-インスタントファイル初期化が有効になっていません：sp_Blitzスクリプトが提供するリンクに従い、IFIを有効にします。

優先度50：信頼性-ページ検証が最適ではありません：これをデフォルト（チェックサム）に戻す必要があります。 sp_Blitzスクリプトが提供するリンクをたどり、指示に従ってください。

優先度100：パフォーマンス-変更されたフィルファクター：フィルファクターが70に設定されたオブジェクトがたくさんある理由を自問してください。回答がなく、アプリケーションベンダーが厳密にそれを要求していない場合。 100％に戻します。

これは基本的に、SQL Serverがこれらのページに30％の空スペースを残すことを意味します。したがって、同じ量のデータ（100％の全ページと比較）を取得するには、サーバーは30％多いページを読み取る必要があり、メモリ内の領域が30％多くなります。これがよく行われる理由は、インデックスの断片化を防ぐためです。

しかし、繰り返しになりますが、ストレージはそれらのページを異なるチャンクで保存しています。だから私はそれを100％に戻し、そこからそれを取ります。

みんなが幸せならどうするか：

  • Sp_Blitzの残りの出力を確認し、提案どおりに変更するかどうかを決定します。
  • Sp_BlitzIndexを実行し、作成されたインデックスが使用されているかどうか、またはインデックスを追加/変更する可能性がある場所を確認します。
  • （Peterの提案に従って）クエリストアデータを確認します。紹介 ここ を見つけることができます。
  • DBAにふさわしいロックスターライブをお楽しみください。 ;）
7
Thomas Kronawitter