sql >> データベース >  >> RDS >> Database

パフォーマンスの問題:最初の遭遇

    DBAとして、パフォーマンスの問題に対処することは、多くの場合、事後対応的なイベントです。問題が発生した場合は、対応する必要があります。よく知っているSQLServerインスタンスを見ている場合もあれば、環境との最初の出会いである場合もあります。これはコンサルティングの世界でも発生します。長期のお客様をサポ​​ートする際に、私はすでに環境に関する詳細を提出しています。ただし、これまで一緒に仕事をしたことがない人からメールを受け取ったとき、彼らがすぐに助けを求めている緊急事態の場合、私たちは環境についての背景がなく、何に向かっているのかわかりません。私たちは、すべての新規顧客エンゲージメントを開始する広範なデータ収集および分析プロセスを経ることなく支援を提供します。

    このため、新しい環境に直面したときにすぐに確認する5つの項目のセットがあります。私が収集する情報は、今後のトラブルシューティングに取り組むための段階を設定しますが、 THEを特定することはめったにありません。 特定の問題、それは私がないものを除外するのに役立ちます 問題。これは同じくらい重要な場合もあります。

    データ収集方法

    新しい環境に取り組むとき、誰もが異なるアプローチを持っていることを認識しています。 SQL Serverインスタンスの「土地の敷設」を提供するためにダウンロードして実行できる無料の広く利用可能なスクリプトがいくつかあります(Glenn BerryのDMVスクリプトが思い浮かびます)。ここでの焦点は方法ではありません データを収集すると、それはです 収集するデータ、および最初に分析するもの 。

    サーバーのプロパティ

    インスタンスを見るときに最初に知りたいのは、SQLServerのバージョンとエディションです。この情報を取得する最速の方法は、以下を実行することです。

    SELECT @@VERSION;

    この出力により、ビルドをチェックして、適用されているサービスパック、累積的な更新プログラム、および修正プログラムを特定でき、使用されているエディションがわかります。インスタンスがクラスター化されているかどうかも知りたいので、以下も実行します:

    SELECT SERVERPROPERTY('IsClustered');

    お客様からこの情報を入手することもありますが、バージョンとエディションがその後のトラブルシューティング手順と推奨事項に影響を与える可能性があるため、確認しても問題はありません。たとえば、クライアントが最近、SQL Server 2008で見た断続的なパフォーマンスの問題について問い合わせてきました。バージョンを簡単に確認すると、SQL Server 2008 SP3を実行していることがわかり、SP3の後にリリースされた累積的な更新プログラムの範囲に対応するものがいくつかありました。パフォーマンスの問題。最新のCUを適用することを推奨する前に、より多くの情報を収集しましたが、これは問題の原因である可能性があることについての即時の危険信号でした。

    sys.configurations

    このカタログビューは、サーバープロパティで開始された基盤の上に構築するのに役立ち、インスタンスがどのように構成されているかを理解するのに役立ちます。このビューで、デフォルトから変更されたが変更されるべきではなかった設定と、されていない設定を探します。 変更されましたが、すべきです。

    SELECT [name], [value], [value_in_use], [description]
      FROM [sys].[configurations]
      ORDER BY [name];

    バッファプールで使用可能なメモリの量を制限する最大サーバーメモリ(MB)設定を検討してください。デフォルト値は2147483647ですが、OS、他のアプリケーション、およびバッファープールからメモリを取得しない必要がある他のSQL Serverタスク用に十分なメモリがあることを確認するために、サーバー上の合計メモリよりも小さい値に変更する必要があります。 。最大サーバーメモリ(MB)の適切な値を設定するためのガイダンスについては、Jonathanの投稿「SQLServerが実際に必要とするメモリの量」をお勧めします。

    逆に、優先度ブースト設定のデフォルトはゼロであり、常にそのままにしておく必要があります。実際、Microsoftはこれを変更しないことを推奨しており、このオプションはSQLServerの将来のリリースで削除される予定です。

    sys.databases

    インスタンスがどのように構成されているかを理解したら、次にデータベースレベルで何が存在するかを確認します。

    SELECT *
      FROM [sys].[databases]
      ORDER BY [database_id];

    このカタログビューの出力を確認するとき、データ内でアンチパターン(予期しないまたは非定型として飛び出すもの)を探します。出力は、迅速な分析に役立ちます。設定の多くは、値(オフまたはオン)に0または1をリストし、何が違うのかを頭の中でメモします。自動作成統計と自動更新統計が有効になっている(1に設定されている)ことを期待しています。自動クローズと自動縮小が無効になっている(0に設定されている)ことを期待しています。ユーザーデータベースの照合が何であるか、具体的にはすべてのデータベースが同じ照合を持っているかどうか、およびその照合がtempdbと同じであるかどうかを確認します。また、クロスデータベースチェーンやis_trustworthyオプションなどのセキュリティオプションにも注意してください。どちらもデフォルトで無効(0)になっています。これらの設定のいずれかが私が期待するものから逸脱していることに気付いた場合は、それに注意して次に進みます。環境をよく理解するためにできるだけ早く情報を収集しているだけなので、変更を加えるために収集や分析を停止することはありません。

    データベースの設定を確認するだけでなく、ユーザーデータベースの数にも注意します。インスタンスに「適切な数」のユーザーデータベースはありません。インスタンスは1つのデータベースではパフォーマンスが低下し、100では素晴らしいパフォーマンスを発揮します。さまざまな要因が関係しており、データベースの数は単なるデータポイントです。注目に値する。

    エラーログ

    確かに、私はSQLServerのERRORLOGを無視していました。 SQL Serverの問題を調査したとき、それは後から考えたようなものでした。それから私は自分のやり方の誤りに気づきました、そして私はそれ以来それを当然のことと思っていませんでした。私はManagementStudioをナビゲートしてログにアクセスする傾向があります([管理] | [SQL Serverログ]内)。ただし、sp_readerrorlogストアドプロシージャを使用するか、ファイルを参照してお気に入りのテキストエディターを開くことができます。

    ERRORLOG内で、最近のエラー(たとえば、メモリに関連するもの)を探します。また、使用されているトレースフラグがある場合はそれも調べます。また、メモリ内のページのロックが有効になっているかどうか、キャッシュがフラッシュされているかどうか(意図的かどうかに関係なく)、その他の異常なアクティビティが定期的に発生していないかどうかを確認します。問題の緊急性に応じて、Windowsログ(イベント、アプリケーション、セキュリティ)も調べ、エラーだけでなく、予期しないメッセージパターンも探します。

    待機統計

    不明なインスタンスのパフォーマンスの問題を調べるときに確認するSQLServerの最後の領域は、待機統計です。すべてのSQLServerインスタンスには待機があります。コードがどれだけ適切に調整されていても、背後にあるハードウェアの量に関係なく。 DBAとして、インスタンスの通常の待機が何であるかを知りたい場合、新しい環境を調べているとき、表示される待機が通常であるか、パフォーマンスの問題が原因であるかはすぐにはわかりません。ベースラインの待機統計があるかどうかをお客様に尋ねます。そうでない場合は、パフォーマンスの問題が発生している間、それらをクリアして蓄積を開始できるかどうかを尋ねます。待機統計を確認するには、Paul Randalの頻繁に参照される投稿のスクリプト、またはGlennのDMVクエリのバージョンを使用できます。

    蓄積された待機統計を確認すると、SQL Serverインスタンスの「全体像」と、トラブルシューティングを開始するために必要な情報を提供する最後の部分が得られます。トラブルシューティング時に最初に待機統計を確認することは珍しくありませんが、SQL Serverの基本構成も理解していない限り、待機だけでは次に調査する必要があることを判断するのに十分な情報ではありません。

    次のステップ

    前に触れたように、通常、パフォーマンスの問題がどこにあるかを示す1つのデータはありません。取得された複数のデータポイントが、正しい方向を示します。その情報をどのように取得するかはあなた次第ですが、出力を確認したら、SQL Server環境がどのように構成されているかを十分に理解し、待機統計と組み合わせて、次に何を調査するかを決定するのに役立ちます。トラブルシューティングは系統だったアプローチで最も効果的に機能するため、基本から始めて作業を進め、根本的な原因を特定したと思われる場合は、もう少し掘り下げて、発見を裏付ける1つまたは2つの追加の証拠を見つけます。そのデータを入手したら、問題の改善または解決に役立つ推奨事項を作成できます。


    1. 値を設定するためのPostgresql挿入トリガー

    2. MariaDBでのUNHEX()のしくみ

    3. 従業員のスケジュールをデータベースに保存する方法

    4. MySQL FULL JOIN?