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

8

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

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

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

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

しかし、時間の経過とともに、それは徐々に悪化し始めました。インデックスが多すぎるとパフォーマンスが低下するのではないかと心配して、インデックスの作成を避けました。しかし、ある時点で、不要なものを削除して、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を少し超えています

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

プロセッサはほとんどの場合、次のようになります。

ここに画像の説明を入力してください

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

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

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

キャッシュヒット率は99％（ユーザー要求とユーザーセッションの両方）

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

ここに画像の説明を入力してください

私はすでに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]には、ページ検証用のNONEがありません。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]データベースには、フィルファクタ= 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]データベースには、フィルファクタ= 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-server  performance  sql-server-2016  enterprise-edition 
— ネルソンロペス
ソース
@Peter Query Storeはすべてのデータベースで有効になっています。
— ネルソンロペス2018年
1
@RDFozz更新統計は、すべてのデータベースでオンになっています。
— ネルソンロペス2018年
@ThomasKronawitterはDell EMCの優れた能力であり、SANです。RAIDの概念はありません。データパターンに従ってブロックを最適化する仮想化ストレージです
— Nelson Lopes
この質問は広くなりすぎたと思います。特定の問題がないため、一般的にパフォーマンスチューニングを行っています。Sp_blitzの結果とThomasの回答は良いアドバイスであり、出発点となります。彼らは除去のプロセスを介してあなたを助けるべきです。しかし、改善できる点はたくさんあるようです。あなたが物事が遅い場所についてより具体的になることができるならば、我々はあなたにより良い答えを与えることができます。
— Swears-a-lot卿2018
@ピーター、人々は一般的にデータの保存とコンサルティング/リストについて不満を言っています。特定のタスクを特定することはできましたが、それはすべての部門、非常に異なるタスクを持つさまざまな企業、およびコア構造に影響を与える問題です。私たちのERP内での数年間の開発とTSQLを追加することが可能な場所（私たちのERPはFox Proに基づいています）のため、いくつかのクエリには確かに改善の余地があることを認識していますが、私を混乱させたのは提案されたインデックスを作成するだけで、昨年すべてがうまくいきます。
— ネルソンロペス

回答:

7

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

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

一時的な緊急措置：

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

緊急対策として、すべてのデータベースで統計情報を一度更新することをお勧めします。次のスクリプトを実行すると、必要な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のブログ投稿で提供しており、統計の更新が重要である理由も説明しています。

これは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にふさわしいロックスターライブをお楽しみください。;）
— トーマス・クロナウィッター
ソース
@ThomasKronawitter、私は週末にスクリプトを実行しました。日中と数日後の様子をユーザーに理解してもらいます。Ola Hallengren Maintenance Solutionもすでにセットアップしています。ただし、以下の疑問がありました：*メンテナンスジョブとして呼び出すジョブは、Olaが提供するデフォルトで開始できるもので、IndexOptimizationという名前で自動的に作成されるジョブですか？*そして、あなたが言及する最初のものはゼロから作成されなければなりませんか？（IndexOptimizationは統計を更新しませんか？）
— ネルソンロペス
私が持っているもう1つの質問は、各データベースで[統計の自動更新]オプションが有効になっていても、統計を更新する必要があるのはなぜですか？SQLはこの仕事を最も完全な方法で実行しませんか？あなたの時間と経験の共有をありがとう。
— ネルソンロペス
@NelsonLopes。好奇心から：完全な統計の更新にはどのくらい時間がかかりましたか？私は、Maintenance Solutionがインストールプロセス中に作成するIndexOptimizeエージェントジョブを参照しています。最初のジョブは最初から作成する必要があります。
— Thomas Kronawitter '19年
@NelsonLopes。投稿の「定期メンテナンス」セクションに回答を追加しました。
— トーマスクロナウィッター
当時は数えませんでしたが、20分くらいかかったと思います。私はあなたが提案したように統計更新ジョブをすでに構成しており、このジョブとOlaジョブでスケジュールを設定しました。手動ですべて一度に実行します。フィードバックがあり次第、ご
— Nelson Lopes
3

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

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

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

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

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

技術者も何も見つかりませんでした。彼はついに何か他のことがこの問題を引き起こさなければならなかった理由を私に与え始めました、そして彼がクラウドに連絡したときでした。クラウドでは何も実現しませんでした。物理ホスト間に構成された負荷分散があるため、SQL ServerをサポートするVMは、物理ホスト間で1日に数回移動されました。幸い、私は技術者に正確にその日に問題が発生し始めた時刻を伝えました。これは、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の答えが完全に正しいと信じています。私はそれを適用します。ただし、この説明は他の人にとっても重要だと思います。 。トーマスに感謝します。

— ネルソンロペス
ソース
1
ホスト間で絶えず移動するVMは、パフォーマンスにとって本当に悪いものです。あなたは、絶対に正しい。それは考えていませんでした。
— Thomas Kronawitter
インターネット上には多くの「ベストプラクティス」があります。私が書いたすべてのものが、どのような状況でも100％正しいとは限りません。あなたが見つけるすべてがまだ最新のものではありません。私が言えることの1つは、「Priority Boost」が悪いことです。brentozar.com/blitz/priority-boost そして、Fill Factorの場合：テストしてパフォーマンスに役立つかどうかを確認します。そうでない場合はリセットしてください。グローバルに有効にするだけでなく、何とかしてすべてがより良くなると信じてください。
— Thomas Kronawitter
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.