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

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

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

 大晦日からずっと仕事なんですが、結構暇です。時間があったので、色々と調べていたら下記の記事がひっかかりました。担当しているシステムで試したくなったのでやってみました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 ポンプ付

SQL Server 2012 と SQL Server v.Next CTP1.1 の DMV と DMF の違いをチェックしてみる

 過去に 2012 と 2016 の dmv、dmf の違いを抽出しました。同じように 2012 と v.Next の違いもチェックしてみましょう。
ryuchan.hatenablog.com

 リンクサーバ名を VNEXTto2012 と定義します。下記のクエリを v.Next 側のインスタンスから実行します。

SELECT
    [SQLServerVNEXTのDMVとDMF] = sqlserverVNEXT.name,
    [SQLServer2012のDMVとDMF] = sqlserver2012.name,
    [種別] = sqlserverVNEXT.type,
    [備考] = sqlserverVNEXT.type_desc
FROM
    master.sys.system_objects sqlserverVNEXT
    FULL OUTER JOIN( SELECT
                         so.name,
                         so.type,
                         so.type_desc
                     FROM
                         VNEXTto2012.master.sys.system_objects so
                   ) sqlserver2012 ON
    sqlserverVNEXT.name = sqlserver2012.name
WHERE 
    sqlserverVNEXT.name LIKE 'dm_%'
ORDER BY 
    sqlserverVNEXT.name

f:id:koogucc11:20161225230443p:plain

 結果をざっと見てみると、見慣れない dmf がいました。赤枠の dm_db_stats_histogram です。object_id と stat_id を引数で渡せばいいようです。
f:id:koogucc11:20161225230726p:plain

 下記のクエリを SQL Server Management Studio で実行してみましょう。

SELECT
    s.*,
    sh.*
FROM 
    sys.stats s
    CROSS APPLY sys.dm_db_stats_histogram(s.object_id,s.stats_id) sh

f:id:koogucc11:20161225232130p:plain

 エラーになってしまいますね。しかし、単体で実行すると結果が出力されます。

SELECT
    *
FROM 
    sys.dm_db_stats_histogram(418100530,1)

f:id:koogucc11:20161225232903p:plain

 どうしてなんでしょう? CTP だから仕方ないんでしょうか。このあたり、統計の詳細情報を一覧で出せると結構便利そうですね。もう少し色々試してみよう....

YOGABOOK 用に買ってみたんですが、中々いい感じでした。