都内で働くSEの技術的なひとりごと / Technical soliloquy of System Engineer working in Tokyo

都内でサラリーマンやってます。SQL Server を中心とした (2023年からは Azure も。) マイクロソフト系(たまに、OSS系などマイクロソフト以外の技術も...)の技術的なことについて書いています。日々の仕事の中で、気になったことを技術要素関係なく気まぐれに選んでいるので記事内容は開発言語、インフラ等ばらばらです。なお、当ブログで発信、発言は私個人のものであり、所属する組織、企業、団体等とは何のかかわりもございません。ブログの内容もきちんと検証して使用してください。英語の勉強のため、英語の

実行プランの読み方をまとめてみる - その9 ( Scan しているオペレーターがないからといって、安心してはいけません ) -

 年末・年始にかけてお仕事でした。ゴールデンウィークがお仕事でなくなるのも少し萎えますが、年末・年始がなくなるのはかなり萎えますね。やはりきちんと休みを取りたいものです。来年以降もこのような状態が続きそうです... この状態から脱却するには、会社・業界を変えるしかないんでしょうね(笑)

 さて、今回は実行プランを見ながらどのようにチューニングを行うか簡単に説明します。下図の実行プランを見てください。一見、Scan もありませんし問題のない実行プランに見えます。この実行プランのクエリを実際運用環境で実行させると、平均 15 秒程度かかっていました。下図の実行プランが示す通り単純な検索ではありませんが、遅いですよね。
f:id:koogucc11:20170107170127p:plain

 よく見ると、キー参照のコストが 62% とかなり高いです。Index Seek と合わせると、全体の 90% を占めることになります。他にも負荷の高い処理を実行しているにもかかわらず、このコストの高さは少し変です。
f:id:koogucc11:20170107171023p:plain

 ①と Hash 結合して、②の結果件数がかなり減少しているため、キー参照前に ① の条件が適用できないかインデックスの並びを調整します。
f:id:koogucc11:20170107200643p:plain 

 インデックスの並びを変えることによって、全体のプランは下図のように変化しました。
f:id:koogucc11:20170107170155p:plain

 キー参照前に、的確にデータを絞り込めるようになったため、キー参照のコストが 2% まで減少しています。
f:id:koogucc11:20170107201016p:plain

 上記のチューニングの結果、どの程度の改善があったかを簡単に確認してみましょう。結果は明らかですね。改善後は 2 秒程度で処理されるようになりました。

  • 改善前
    f:id:koogucc11:20170107201721p:plain
  • 改善後
    f:id:koogucc11:20170107201730p:plain

 実行プランから SQL Server がどのようにデータを取得し、処理しているかを的確に判断し、最適なインデックスを作成するようにしましょう。(簡単に言ってしまいましたが、そんなことが簡単にできるならデータベースチューニングなんて仕事必要ないんでしょう.....)

 大分県の銘菓ザビエル。美味しいですよ。

大分の代表銘菓 ざびえる本舗 「ざびえる18個入」

大分の代表銘菓 ざびえる本舗 「ざびえる18個入」

 別府温泉行きたかった.....

るるぶ大分 別府 湯布院 くじゅう'16~'17 (国内シリーズ)

るるぶ大分 別府 湯布院 くじゅう'16~'17 (国内シリーズ)

そうなんだぁと思ったことを記事にしてみた

 大晦日からずっと仕事なんですが、結構暇です。時間があったので、色々と調べていたら下記の記事がひっかかりました。担当しているシステムで試したくなったのでやってみましたwww
SQL Server: パフォーマンスの問題を掘り下げる

OS のパフォーマンス チューニングの 1 つ目のスクリプト例では、実行済みスレッドで発生したすべての待機に関する情報を返す sys.dm_os_wait_stats DMV を使用します。このさまざまな情報が集約されたビューを使用して、SQL Server 全体および特定のクエリやバッチに関するパフォーマンスの問題を診断できます。
次のシンプルなクエリを使用すると、全体の待機時間に対するシグナルの待機とリソースの待機の割合を算出して、潜在的な CPU の負荷を診断できます。

 ということで、下記のクエリを担当しているシステムで実行してみました。

SELECT
    CAST(100.0 * SUM(signal_wait_time_ms) / SUM(wait_time_ms) AS NUMERIC(20, 2)) AS [%signal(cpu) waits],
    CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM(wait_time_ms) AS NUMERIC(20, 2)) AS [%resource waits] 
FROM
    sys.dm_os_wait_stats

f:id:koogucc11:20170103235321p:plain

このクエリは、CPU に負荷がかかっていることを確認するのに有効です。シグナルの待機は、CPU がスレッドにサービスを提供するまでの待機時間なので、シグナルの待機の合計が 10 ~ 15% 以上になると、CPU に負荷がかかっている目安となります。この待機の統計データは、SQL Server が最後に再起動されたときから蓄積されているので、シグナルの待機の基準値を把握し、長い時間をかけて、その動向を観察する必要があります。

 ちょっと面白そうなので、しばらく観察してみよう。上記のクエリ以外にも面白そうなのがおおいなぁ。試してみよう!この手のやつは実環境と照らし合わせながらじゃないとわかんないですよね。

風邪を引いたとき、寝るときには必須です。これが一番合うかなー。

新年の挨拶してみる

 新年あけましておめでとうございます。旧年は大変お世話になりました。今年も【都内で働くSEの技術的なひとりごと】のご購読よろしくお願いいたします。

今年書いた記事を振り返ってみる

 怒涛の忘年会から、数年ぶりのインフルエンザまで、12月後半は色々と大変でした。更に、大晦日から正月明けまでお仕事です。それでは、今年一年の投稿された記事をざっくり振り返ってみます。

  • この投稿をもって目標にしていた月 10 記事、年 120 記事を達成します。
    f:id:koogucc11:20161230003303p:plain
  • Cognitive が一回で終わってる。今後の重要な技術要素の一つだと思うので来年からはもっと勉強します。
    ryuchan.hatenablog.com
  • .NET 関係ももう少し記事かかないとなぁ。プログラミングスキルがどんどん落ちていく...
    ryuchan.hatenablog.com
  • 今年も沖縄によく行ったなぁ。観光はほとんどしていませんが...
    ryuchan.hatenablog.com

 まだまだ、纏めなければいけない情報はありますね。それでは、みなさまよいお年を♪ 来年も購読をよろしくお願いします。

反省します。

反省します。

反省します。

今年たてた抱負をみてみる

 こんな事書いてました。
ryuchan.hatenablog.com

  1. 将来のことを考えてみたい。
    引き続き。
  2. 自分にあった仕事は何か考えてみる。
    引き続き。
  3. マイクロソフトの技術に強くなる。
    引き続き。
  4. MCP を更新する。( MCITP とかそのまま放置してる。)
    2016出たら考えよう。
  5. インフラ関係に強くなる。
    まだまだ知識が薄いので。
  6. ブログを継続する
    当然継続します。
  7. 勉強会も二回以上は開催する。
    去年と同様継続します。

 ふぅ。相変わらず達成していないものが多いです。MCPMCITP から全然更新していないなぁ。来年の抱負は少し少な目にしようww 一つづつ確認してみると、

  1. 将来のことを考えてみたい。
    働き方を変えたいのと、自分の好きなことをもっと生かせるようにしたい。
  2. 自分にあった仕事は何か考えてみる。
    エンジニアであることは間違いないです。
  3. マイクロソフトの技術に強くなる。
    あんまり変わってないかなぁ。本当進歩がないです。
  4. MCP を更新する。( MCITP とかそのまま放置してる。)
    2016 出ましたが、まだ考えてないです。
  5. インフラ関係に強くなる。
    ネットワーク、仮想化関係は若干強くなったかな?と思います。
  6. ブログを継続する
    継続した。
  7. 勉強会も二回以上は開催する。
    二回は開催してません....

ある程度達成可能なものにしよう。数減らそう。

今年の抱負

今年の抱負

SQL Server v.Next CTP1.0 で追加された DMF をお試してみる

 もう一つ dmf をお試ししてみます。sys.dm_exec_query_statistics_xml です。
ryuchan.hatenablog.com

 sys.dm_exec_query_statistics_xml は、実行中リクエストのクエリ実行プランを返します。一時的な統計情報を含む showplan XML を取得することが可能です。下記のクエリを SQL Server Management Studio で実行してみましょう。(別セッションで何らかのクエリを実行させ続けてください。) ん?結果が得られませんね。

SELECT
    er.*,
    eqsx.*
FROM 
    sys.dm_exec_requests er
    CROSS APPLY sys.dm_exec_query_statistics_xml(er.session_id) eqsx

f:id:koogucc11:20161227005423p:plain

 トレースフラグを設定する必要がありそうです。下記のコマンドを SQL Server Management Studio で実行してみましょう。

DBCC TRACEON(7412,-1)

f:id:koogucc11:20161227005614p:plain

 再度下記のクエリを SQL Server Management Studio で実行してみましょう。結果を得ることができました。

SELECT
    er.*,
    eqsx.*
FROM 
    sys.dm_exec_requests er
    CROSS APPLY sys.dm_exec_query_statistics_xml(er.session_id) eqsx

f:id:koogucc11:20161227005919p:plain

 若干のオーバーヘッドはあるようですが、気にするほどでは無さそうです。

In TPC-C like workload tests, enabling the lightweight statistics profiling infrastructure adds a 1.5 to 2 percent overhead. In contrast, the legacy statistics profiling infrastructure can add up to 90 percent overhead for the same workload scenario.

インフルエンザ流行してきたと思ったら、ノロウィルスも来てますね。最近の餅つきイベントはその場でついた餅は破棄して、事前に衛生面が確保された場所で作られた餅を配ることが多いようです。こちらも対策が必要ですね。

サラヤ シャボネット ユ・ム P-5泡 1kg ポンプ付

サラヤ シャボネット ユ・ム P-5泡 1kg ポンプ付