私は長年、SQLServerの一般的な間違いについて教えたり書いたりしてきました。何年も前にもブログを書いていましたが、時間が経つにつれ、ガイダンスが少し変わりました。この記事では、以前の記事を拡張し、これらがSQL Server、Azure SQLデータベース、およびAzureSQLマネージドインスタンスにどのように適用されるかを指摘します。
何年もの間、私はユーザーが同じ過ちを犯しているのを見つけました。私はそれらを間違いと呼んでいますが、ほとんどの場合、環境を管理している人々がそれ以上のことを知らないために、適切に行われていないことが原因です。 SQLServerをインストールおよびサポートする人が知っておくべき重要な項目のいくつかを次に示します。
- バックアップ
- DBCC CHECKDB
- メモリ設定
- 統計
- インデックスのメンテナンス
- 並列処理のMAXDOPとコストのしきい値
- SQLServerエージェントのアラート
バックアップ
新しいシステムを検討するときは、常に最初にバックアップを確認します。リカバリの目標を達成するために適切なバックアップを用意することが重要です。データの損失は、組織に悪影響を与える可能性があります。バックアップを見るとき、各データベースのリカバリモデルとバックアップの現在の履歴を確認します。私は通常、次の組み合わせを見つけます：
- バックアップがまったくない–データベースのバックアップの記録がない
- バックアップがありません–完全復旧モデルを使用したデータベースのログバックアップはありません
- 最近のバックアップはありません–最後のバックアップは数週間/数か月/数年前のものでした
誤って構成されたバックアップは、復旧状況が発生したときに組織に悪影響を及ぼします。データを失ったことを顧客と協力して伝えなければならないことは、決して楽しいことでも簡単なことでもありません。 SLAを満たすための適切なバックアップを用意することは、これらのバックアップのコピーがオフサイトのセカンダリロケーションに保存されていることを確認することに加えて、組織の最優先事項である必要があります。
この状況は、オンプレミスのSQLServerとIaaSに当てはまります。 AzureSQLデータベースとAzureマネージドインスタンスにはバックアップが管理されています。
DBCC CHECKDB
残念ながら、データベースの破損は発生します。破損を定期的にチェックしないと、破損が物理データに影響を与えたときに回復するためのバックアップがないため、顧客は悪い場所にいることに気付く可能性があります。破損をチェックするには、DBCCCHECKDBを各データベースに対して定期的に実行する必要があります。私が見つけたものはバックアップと非常に似ています：
- DBCCCHECKDBはまったく実行されません
- DBCC CHECKDBは、選択したデータベースでのみ実行されます
- DBCCCHECKDBは数か月または数年前に最後に実行されました
最悪のケースは、失敗したDBCCCHECKDBを報告するジョブスケジュールです
破損がヒープまたはクラスター化されたインデックスであり、破損が発生する前にバックアップがない場合、破損を見つけたり、破損の問題について顧客に連絡したりするのは決して楽しいことではありません。このような場合、破損は実際のデータであり、ほとんどの場合、破損前から復元を開始することが唯一の選択肢です。破損がクラスター化されていないインデックスである場合は、インデックスを再構築することが修正されます。
いくつかの状況では、適切なバックアップなしで厄介な破損を抱えている顧客と協力して、データベースのスクリプトを作成し、使用可能なすべてのデータを新しく作成したデータベースに手動でコピーする必要がありました。これらのコストのかかる状況は、DBCC CHECKDBを実行し、適切なバックアップを保持することで簡単に回避できます。
DBCC CHECKDBをオンプレミス、IaaS、Azure SQLデータベース、およびAzureSQLマネージドインスタンスで実行することをお勧めします。 Azureは、物理的な破損をチェックするのに最適です。ただし、消費者は論理的な破損をチェックする必要があると感じています。
メモリ設定
Microsoft SQL Serverのデフォルトのインストールでは、最小メモリ値が0に設定され、最大サーバーメモリ値が2147483647 MB（2ペタバイト）に設定されています。 SQL Server 2012より前は、サーバーの最大メモリ値はバッファプールにのみ適用されていたため、顧客は、オペレーティングシステムやその他のプロセスのメモリを節約するためにバッファプールが使用できるメモリの量を制限する必要がありました。 SQL Server 2012では、メモリマネージャーの書き換えが導入され、サーバーの最大メモリ値がすべてのSQLServerメモリ割り当てに適用されるようになりました。
SQLServerインスタンスの最大値を設定することを強くお勧めします。 Jonathan Kehayiasは、最大メモリ値のベースラインを確立するのに役立つ式を使用して、SQLServerが実際に必要とするメモリの量をブログに投稿しています。共有SQLServerの場合、クライアントにサーバー上のメモリの30％に最小値を設定することをお勧めします。
複数のインスタンスがある場合、またはサーバーがSQL Server、SSIS、SSAS、またはSSRSに使用されている場合は、他のシステムに必要なメモリの量を評価し、サーバーの最大メモリ値を減らして、OSと他のシステムに十分なメモリを確保する必要があります。サービス。
この問題は、オンプレミス、IaaS、および部分的にAzureSQLマネージドインスタンスで有効です。管理対象インスタンスは、展開された層に基づいて最大サーバーメモリ値を設定しますが、環境のサイズ変更をテストしたとき、最大メモリ値は動的に変更されませんでした。そのような状況では、値を手動で更新する必要があります。この問題は、AzureSQLデータベースには適用されません。
統計
クエリオプティマイザは、統計を使用して実行プランを作成します。これは、クエリオプティマイザが適切な実行プランを作成できる可能性を高めるために、SQLServerが最新の統計を必要としていることを意味します。デフォルトでは、統計は20％+500行のデータが変更された後に更新されます。大きなテーブルでは、これには長い時間がかかる可能性があります。互換性レベル130以降、大きなテーブルの統計更新のしきい値が低くなりました。 SQL Server 2008R – 2014の場合、トレースフラグ2371を使用してこのしきい値を下げることができます。
お客様が統計を手動で更新していないことを定期的に確認しています。しきい値を低くしても、手動で更新すると環境がより安定することがわかりました。
統計を更新するには、サードパーティのスクリプトを使用することをお勧めします。 Ola Hallengrenは、広く使用されているSQLServerのメンテナンスソリューションを公開しています。そのプロセスの一部は、統計を更新するために追加のパラメーターを取ることができる彼のインデックス最適化手順です。
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
サードパーティの製品またはスクリプトを使用してインデックスの断片化レベルに基づいてインデックスのメンテナンスを実行しているお客様は、再編成が再構築のように統計を更新しないことを考慮していないことがわかりました。これらのサードパーティアプリケーションの多くには、Olaのインデックス最適化手順と同じように統計を更新するためのオプションがあります。オンにするだけです。
統計の更新は、オンプレミス、IaaS、Azure SQLデータベース、およびAzureSQLマネージドインスタンスに適用されます。
インデックスのメンテナンス
インデックスから断片化を削除してインデックスのメンテナンスを実行することは、依然として重要です。 Microsoftからのいくつかの廃止されたドキュメントは、インデックスの断片化は、環境のサイズと断片化のレベルに応じて13〜460％の悪影響を与える可能性があると述べています。インテリジェントSAN、ソリッドステートディスクなどのハードウェアは速度を上げるのに役立ちましたが、インデックスの無駄なスペースは、バッファプールの無駄なスペースに変換されるだけでなく、より多くのI/Oを無駄にする可能性があります。
断片化は、挿入、更新、削除などの通常の操作によって発生します。これを修正するには、インデックスの再構築または再編成の適切なインデックスメンテナンスが必要です。 IndexOptimizeスクリプトについては再びOlaHallengrenに目を向けます。 Olaのスクリプトは、断片化のレベルと最小ページに基づいて再構築または再編成するように指定する機能を提供します。多くのサードパーティツールは同じロジックを提供します。 SQL Server2016より前のSQLServerデータベースメンテナンスプランでは、すべてのインデックスの再構築または再編成のみが許可されていました。 SQL Server 2016以降、断片化レベルに基づいて同様のロジックを指定できるようになりました。ただし、断片化レベルに基づくスマートロジックを使用している場合は、これらの統計を忘れないでください。
テーブルにログインするOlaのスクリプトとサードパーティのツールが好きです。次に、テーブルをクエリして、断片化が高レベルで絶えず発生しているインデックスのホットスポットがあるかどうかを確認し、断片化が非常に一般的で何でもできる理由をトラブルシューティングできます。
すべてのルールまたはベストプラクティスには例外があります。データアクセスのいくつかのパターンは、絶え間ない断片化につながります。これらのテーブルを絶えず再構築/再編成するコストは、それだけの価値がない可能性があり、メンテナンスから除外できます。これらの状況は、ケースバイケースで評価する必要があります。
これは、オンプレミス、IaaS、Azure SQLデータベース、およびAzureSQLマネージドインスタンスに適用されます。
MAXDOP
並列処理の最大度と並列処理のコストしきい値は、通常、クライアントサーバーのデフォルト値のままであることがわかりました。 MAXDOPの場合、デフォルト値はゼロです。これは、「無制限」の数のCPUを使用してクエリの並列領域を実行できることを意味します。トレースフラグを有効にしてさらに使用しない限り、技術的には最大64プロセッサ。
10年前、プロセッサのコア数が少なかったとき、この値は許容範囲内でした。現在、コア密度が高く、マルチソケットサーバーがあるため、並列処理用のCPUの数に制限はありません。 Microsoftは、MAXDOPに使用する値に関するガイダンスを提供しています。
SQL Server 2008 – SQL Server 2014を使用している場合、論理プロセッサが8つ未満の単一のNUMAノードの場合、MAXDOPを論理プロセッサの数以下に維持します。論理プロセッサーが8つを超える場合は、MAXDOPを8に保ちます。NUMAノードあたりの論理プロセッサーが8つ未満のNUMAノードが複数ある場合は、MAXDOPをNUMAノードあたりの論理プロセッサーの数以下に保ちます。 8より大きい場合、MAXDOPを8に保ちます。
SQL Server 2016では、soft-NUMAノードが導入されました。サービスの起動中に、データベースエンジンがNUMAノードまたはソケットごとに8を超える物理コアを検出すると、soft-NUMAノードが自動的に作成されます。エンジンは、同じ物理コアからの論理プロセッサを異なるsoft-NUMAノードに配置します。そのため、SQLServer2016以降のMAXDOPのガイダンスは少し異なります。
SQL Server 2016以降を使用している場合、論理プロセッサが16未満の単一のNUMAノードの場合、MAXDOPを論理プロセッサの数以下に維持します。 16を超える論理プロセッサーがある場合は、MAXDOPを16に保ちます。NUMAノードあたりの論理プロセッサーが16未満のNUMAノードが複数ある場合は、MAXDOPをNUMAノードあたりの論理プロセッサーの数以下に保ちます。 16より大きい場合、MAXDOPをNUMAノードあたりの論理プロセッサ数の半分に保ち、MAX値を16にします。
デフォルトのMAXDOPを備えた8個以下の論理プロセッサを搭載したマシンでほとんど仮想化されている場合は、おそらく問題ありません。デフォルトの大きな物理ハードウェアがある場合は、MAXDOPの最適化を検討する必要があります。
上記の数字はすべてガイドラインであり、難しい真実ではありません。ワークロードはさまざまであり、ワークロードに最適な値を決定する際には考慮が必要です。
MAXDOPの構成は、オンプレミス、IaaS、およびAzureSQLマネージドインスタンスに適用されます。ただし、SQL Server 2016以降、データベースごとに適用できるデータベーススコープの構成があり、これはAzureSQLデータベースに適用されます。
並列処理のコストしきい値
並列処理のコストしきい値のデフォルト値は5です。この数値の履歴は、SQLServerとワークステーションテストが実行されたワークステーションの初期の頃にさかのぼります。最新のハードウェアでは、5のコスト見積もりは時代遅れです。テストの結果、数値を5から高い値に増やすと、実行時間の短いクエリで並列プランが実行されなくなることがわかっています。プランキャッシュを調べた後、この値をより高い数値に増やすことをお勧めします。多くの場合、私は25の値から始めて、さらに監視し、必要に応じてそこから調整することになります。並列処理のコストしきい値の調整の詳細については、JonathanKehayiasが次のように書いています。プランキャッシュからの「並列処理のコストしきい値」の調整。
これは、オンプレミス、IaaS、およびAzureSQLマネージドインスタンスに適用されます。
SQLServerエージェントアラート
同じエラー状態を監視するサードパーティのアプリケーションがない限り、誰もがSQLエージェントアラートを活用する必要があります。アラートの構成は簡単で無料です。アラートを構成しておくと、サーバーで問題が発生したときに重要な情報が得られます。
SQL Serverエージェントアラートというタイトルの記事を作成し、重大度19〜25のエラーとエラー825のアラートを作成する方法を段階的に説明しました。これらのアラートの有効化は簡単です。データベースメールを有効にし、メールオペレーターを作成してから、アラート。これは、GUIまたはT-SQLを使用して実行できます。 T-SQLを使用してこのプロセスをスクリプト化し、標準のサーバービルドの一部にすることを皆さんに勧めます。
これは、オンプレミス、IaaS、およびAzureSQLマネージドインスタンスに適用されます。
概要
ご覧のとおり、SQLServerのインストール後にデフォルトから変更する必要のある設定が多数あります。これは包括的なリストではありません。ただし、これは、私が見つけた、パフォーマンスに影響を与えるより重大でパフォーマンスに影響を与える問題の多くをカバーしており、「SQLServerの事故」カテゴリにまとめられています。