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

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

今年の抱負を書いてみる

ひとりごと

　去年はこんな抱負を書いていました。
ryuchan.hatenablog.com

  1. 将来のことを考えてみたい。
    引き続き。
  2. 自分にあった仕事は何か考えてみる。
    引き続き。
  3. マイクロソフトの技術に強くなる。
    引き続き。
  4. MCP を更新する。( MCITP とかそのまま放置してる。)
    2016出たら考えよう。
  5. インフラ関係に強くなる。
    まだまだ知識が薄いので。
  6. ブログを継続する
    当然継続します。
  7. 勉強会も二回以上は開催する。
    去年と同様継続します。
  1. 将来のことを考えてみたい。
    私生活を充実させるようにしたいですね。もっと勉強ができる時間を確保しないと。あと趣味も。
  2. マイクロソフトの技術に強くなる。
    引き続き。Azure 関連を中心に。
  3. MCP を更新する。( MCITP とかそのまま放置してる。)
    一度 MCP 受けてみよう。まずはこれから。
    MCSA: SQL 2016 certifications | Microsoft
  4. インフラ関係に強くなる。
    ネットワーク関連とか。
  5. ブログを継続する
    当然継続します。月あたりの投稿数は目標にしませんww
  6. 勉強会も二回以上は開催する。
    去年と同様継続します。やっぱり、チューニング関連がメインですかね。

こんな本あった。久しぶりに SQL Server 本買ってみようかな。

SQL Server 2016データベース構築・管理ガイド Enterprise対応

SQL Server 2016データベース構築・管理ガイド Enterprise対応

SQL Server 関連で買った本はこれくらい。この二冊は今読んでも役に立つ。

絵で見てわかるSQL Serverの内部構造 (DB Magazine Selection)

絵で見てわかるSQL Serverの内部構造 (DB Magazine Selection)

アドバンストMS SQL SERVER 2008 構築・管理 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ)

アドバンストMS SQL SERVER 2008 構築・管理 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ)

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

SQL Server

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

　さて、今回は実行プランを見ながらどのようにチューニングを行うか簡単に説明します。下図の実行プランを見てください。一見、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 (国内シリーズ)

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

SQL Server

　大晦日からずっと仕事なんですが、結構暇です。時間があったので、色々と調べていたら下記の記事がひっかかりました。担当しているシステムで試したくなったのでやってみました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 が最後に再起動されたときから蓄積されているので、シグナルの待機の基準値を把握し、長い時間をかけて、その動向を観察する必要があります。

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

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

(PM2.5対応)フィッティ 密着ガードマスク ふつうサイズ 5枚入

(PM2.5対応)フィッティ 密着ガードマスク ふつうサイズ 5枚入

新年の挨拶してみる

ひとりごと

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

お年玉チョコ【まとめ売り】120個

お年玉チョコ【まとめ売り】120個

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

ひとりごと

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

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

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

反省します。

反省します。

反省します。