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

SQLインスタンスでピークアクティビティが発生する可能性がある3つの理由は次のとおりです。

    高性能のSQLServerインスタンスを維持することは、DBAの職務の大部分を占めています。異常なアクティビティを検出して修正しないと、内部の運用に影響を与えるだけでなく、ビジネスの収益を損なう可能性があります。

    SQL Serverインスタンスのアクティビティの変化や異常のピークに気付いた場合は、次の3つの場所で回答の検索を開始できます。

    ページの平均余命

    インスタンスのページ寿命(PLE)は、かなり一貫した値の範囲を維持する必要があります。その値が低下して低いままである場合は、バッファプールの需要が増加していることを示しています。

    メモリを使い果たして使い切る前に、ワークロードアクティビティを確認してください。ワークロードが増加した場合、それはバッファプールへの追加のプレッシャーを説明します。ただし、ワークロードが変更されていない場合は、余分なメモリを使用しているものを特定するために、より詳細に調べる必要があります。

    PLEが低下する理由として考えられるのは、アクティブに実行されているメンテナンスジョブ、インデックスの再構築または統計の更新、DBCC操作、クエリプランの変更などです。

    ワークロードの増加に関連しないPLEの低下に気付いた場合は、インスタンスのPLEを改善するために試すことができることがいくつかあります。

    • 未使用のインデックスを削除する
    • 重複するインデックスをマージする
    • 大きなクエリに注意してください
    • デフラグ
    • データを削除する

    WRITELOG待機時間

    WRITELOG待機時間が合計待機時間に占める割合が大きすぎる場合は、SQLServerインスタンスにボトルネックがある可能性があります。ボトルネックは、トランザクションログが保存されているディスクの問題か、データが非効率的にコミットされていることが原因である可能性があります。

    対処しているボトルネックの種類を判別するには、WRITELOGイベントを待機しているSQLステートメントの数を分析することから始めます。待機しているステートメントがたくさんある場合は、ディスクのボトルネックがあります。待機しているステートメントが少ない場合は、データが頻繁にコミットされている可能性があります。

    ボトルネックがディスク関連かコミット関連かを判断した後、高いWRITELOG待機時間を解決する方法はいくつかあります。

    • トランザクションログが保存されているディスクにI/O帯域幅を追加します
    • 非トランザクションログI/Oをディスクから移動する
    • トランザクションログをビジーでないディスクに移動します
    • トランザクションログのサイズを縮小します
    • データが頻繁にコミットされないように、COMMITステートメントがコードに配置されていることを確認してください

    TempDB

    TempDBは、一時オブジェクトを保持するSQLServerの一時ワークスペースです。 TempDBに保持されているオブジェクトは一時的なものであるため、SQLServerインスタンスは再起動するたびにTempDBを再作成します。これにより、TempDBの最適化は、パフォーマンスを維持し、運用上のボトルネックを回避するために重要になります。

    TempDBの競合は、パフォーマンス低下の主な原因の1つです。複数のリソースがTempDBにアクセスする必要があるが、TempDBデータファイルが1つしかない場合、競合が発生します。これにより、プロセスがTempDBに十分な速度でアクセスできず、接続がタイムアウトし、プロセスの割り当てが解除されるため、ボトルネックが発生します。

    幸い、TempDBのボトルネックは、TempDBファイルの数とサイズを調整することでかなり簡単に解決できます。インストール時に、SQLServerのデフォルトは1つのTempDBデータファイルです。競合が発生していることに気付いた場合は、8つの新しいデータファイルを追加して、それで問題が解決するかどうかを判断することをお勧めします。問題が解決しない場合は、パフォーマンスが回復するまで、4の倍数でデータファイルを追加してみてください。

    パフォーマンスの問題が発生したときにどこから始めればよいかを知ることは素晴らしいことですが、上記の各問題とその結果生じるボトルネックは、1つの厳格なルールを実装することで、完全に軽減または回避できます。パフォーマンスメトリックの監視はオプションではありません。追跡する主要な指標の例を次に示します。

    ページの平均余命:継続的な監視でPLEを追跡し、特定のSQLServerインスタンスの標準値を下回って下回った場合は事前に対処します。

    WRITELOG待機時間:ログの増加、ログの縮小、使用されたログの割合、ログのフラッシュ待機/秒などのメトリックを監視します。

    TempDBの非効率性:ユーザーオブジェクト、バージョンストア、または内部オブジェクトに何が割り当てられているかを監視します。時間の経過に伴う傾向を追跡し、TempDBを消費しているセッションとその量を特定します。

    パフォーマンスを低下させる問題に先んじるのに役立つ、機能が豊富で手頃なSQLServerパフォーマンス監視ツールがいくつか市場に出回っています。内向きのオペレーションと外向きのビジネスサービスの両方を最高のパフォーマンスで実行し続けるソリューションを積極的に研究して、会社のDBAMVPになりましょう。


    1. Oracle 9iが空の文字列をNULLとして扱うのはなぜですか?

    2. 関係代数

    3. Java:OracleデータベースにCLOBを挿入する方法

    4. PostgreSQLでのCONCAT()関数のしくみ