BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース SQL Server First Responder Kit入門

SQL Server First Responder Kit入門

原文(投稿日:2017/02/09)へのリンク

SQL Serverデータベースが突然ダウンした。DBAは休暇中で,何をどうすればよいのかさっぱり分からない。こんな状況を脱出するためのものが,DBAあるいは臨時DBAの作業を支援し,SQL Serverインスタンスの修正とチューニングを行なうスクリプトを集めたオープンソースプロジェクトであるSQL Server First Responder Kitだ。

これらのスクリプトは通常,サーバ上の“master”データベースにストアドプロシージャとしてインストールされる。このように“sp_”で始まる一連のスクリプトを用意しておくことで,確認対象のデータベースがどれであっても利用することができるのだ。

追記: SQL Serverでは常に,masterの“sp_”で始まるストアドプロシージャが最初に参照される。従って,通常のプレフィックスを持ったデータベース固有のストアドプロシージャを使用すると,別の場所を検索することで,サーバの動作をわずかながら遅くすることになる。

sp_BlitzWho – 現在の問題を起こしているのは誰か?

何らかの問題が発生した場合,まず最初に使用するツールである。データベースに接続しているのは誰か,何を実行しているのか,データベースにどのような悪影響を与えているのか,といったことを教えてくれる。

(画像をクリックして拡大)

停止すべき暴走プロセスが見つかれば,そのセッションidを指定して“kill”コマンドを発行すればよい。

ここで問題が明確にならない場合は,次のsp_BlitzFirstに進むことになる。

sp_BlitzFirst – 何を待っているのか?

sp_BlitzFirstはデータベースが何を待機しているのかを見つけるためのツールだ。この例では,SQL Server以外のプログラムによるCPU時間の過剰な使用が最大の問題であることが分かる。

(画像をクリックして拡大)

開発者のマシン上でスクリプトを実行する場合を除けば,このような状態になることはまずあり得ない。より一般的なのは,ひとつないしそれ以上の“wait stat”が問題となる場合である。

SQL Serverでは,クエリを遅くする可能性のあるものはすべてwait statとして確認できる。ディスクやネットワークI/O,テーブルないし行のロック,CPUやメモリなどのリソース待ちなどがこれにあたる。アウトプットでのリンクは一般的な待機タイプで有効ではあるが,数百種類に及ぶさまざまな待機タイプがトラックされるため,実際に影響しているwait stat情報を特定することが困難な場合もある。

sp_Blitz – そもそもデータベースの設定は正しいのか?

データベースサーバの所有権を始めて受け取った場合,考慮に入れるべきツールがsp_Blitzだ。このツールは,SQL Serverのセットアップ方法に関する共通的な問題を指摘してくれる。それぞれのイシューには問題を解決する上でのヒントや,問題に対処する順番を示した優先順位スコアなどが含まれている。

(画像をクリックして拡大)

この例では,データベースの大部分に対してバックアップが長期間実施されていないことや,損傷チェックに時間が掛かり過ぎていることが分かる。

検出可能な問題としては,他にも次のようなものがある。

  • 不正なコンフィギュレーション設定。特に並列処理のコストしきい値など,“デフォルト値が不適切”なもの。
  • トランザクションログをOSドライブに置くなど,危険なファイル配置。
  • 非営利ライセンスの使用。
  • データベース破損やメモリ不足などに対する警告の不備。
  • データベース所有者の不適切な設定など,一般的なセキュリティ設定のエラー。

sp_BlitzCache – どのクエリをチューニングすべきか?

当面の問題が解決すれば,積極的なパフォーマンス改善の検討に着手することが可能になる。そのためのツールのひとつがsp_BlitzCacheで,SQL Serverのクエリ計画キャッシュを参照して,データベース全体の処理時間に最も大きく影響するクエリを特定することができる。さらに,スカラ演算子による計算列や暗黙的な型変換といった,クエリに関する一般的な問題も警告してくれる。

sp_BlitzFirstとsp_BlitzCacheの大きな違いは,sp_BlitzFirstは何が起きているのかをリアルタイムで観察している点だ。対照的に,sp_BlitzCacheは過去のデータを参照してトレンドを識別するので,問題となるクエリを実行時にキャッチする必要はない。

sp_BlitzIndex – インデックスは有効に機能しているか?

パフォーマンス上の問題が個々のクエリではなく全体的なものだと思われる場合には,次に確認すべきなのはインデックスだ。インデックスの不足がパフォーマンスに重大な悪影響を与えることは広く知られた事実であり,場合によってはクエリの実行に10倍,100倍,あるいは1000倍以上の処理時間を要することもある。

インデックスの数が多過ぎることも同じように重要な問題だ。インデックスの不足と合わせて,sp_BlitzIndexは,利用数に比較してインデックスの更新に時間が掛かり過ぎていることも警告してくれる。不必要なインデックスの更新は書き込みを遅くするだけでなく,他のデータをキャッシュから追い出すことで,結果的に無関係なクエリをスローダウンさせる。

SQL Server First Responder KitはBrent Ozar Unlimitedが開発したもので,現在はMITライセンスの下でオープンソースプロジェクトとなっている。

 
 

この記事を評価

関連性
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

BT