SE の雑記

アプリケーションから SQL Server / SQL Database にコマンド (クエリ) を実行する際には、「コマンドタイムアウト」(クエリタイムアウト) について考慮をしておく必要があります。

ADO.NET の SQL Server 向けのドライバーではデフォルトでは 30 秒に設定されています。

• SqlCommand.CommandTimeout プロパティ

コマンドタイムアウトの時間に達すると「Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.」「実行タイムアウトの期限が切れました。操作完了前にタイムアウト期間が過ぎたか、サーバーが応答していません。」のエラーが発生し、クエリの実行がキャンセルされます。

アプリケーション側で Exception をキャッチして、その時に実行されていたクエリなどをロギングするようになっていれば、「どのようなクエリによりタイムアウトが発生したか？」を確認することができますが、そのようなロギングの仕組みがない or 情報が不足している場合に、サーバー側観点だけでどのような情報取得の対応ができるか、考えてみました。

Read the rest of this entry »

SQL Server / SQL Database では、「sys.dm_os_ring_buffers」という Ring Buffer の情報を確認することができます。

「Using sys.dm_os_ring_buffers To Diagnose Memory Issues in SQL Server」 等で解説をされているのですが、SQL Server の様々な情報をメモリ上に確保している DMV となります。

この DMV では timestamp という値を持っているのですが、この値を加工するためには、sys.dm_os_sys_info の ms_ticks を元にして、コンピューターを起動してからの経過時間を使用していつのイベントなのかを確認するのが一般的です。

しかし、sys.dm_os_sys_info については、SQL Database では使用することができず、この DMV では、コンピューターを起動してからの経過時間を取得することができません。

SQL Database で timestamp を実際の時間に直す方法が何かないか考えてみたのですが、sys.dm_os_memory_cache_clock_hands の round_start_time の最大値で代替できそうでした。

Read the rest of this entry »

SQL Server の tempdb では、ロギング最適化という動作により、トランザクションログの書き込みを最小限にするようにされています。

最近は、「SQL Server を使いこなす」という観点での勉強を進めており、その中でトランザクションログの書き込み内容の解析も多少できるようになってきましたので、tempdb のロギング最適化による、最小のログ記録の動作についても、実際のトランザクションログの書き込み内容を元にしてみていきたいと思います。
(本投稿の最小のログ記録については、一括挿入を実行する際等の最小ログ記録とは別の動作です)

Read the rest of this entry »

先日、SQL Database Hyperscale のパフォーマンスについては SQL Hyperscale のパフォーマンスのトラブルシューティング診断 で公開されていることを書きました。

通常の SQL Database についてもパフォーマンスの調査時に重要となるリソース割り当てについてのドキュメントが、いくつか公開されていたようです。

• dm_user_db_resource_governance (Transact-sql)
• dm_resource_governor_resource_pools_history_ex (Transact-sql)
• SQL Database のリソース制限およびリソース管理

Read the rest of this entry »

SQL Server のトランザクションログの内容を確認する際のアプローチとして「DBCC LOG 」や「sys.fn_dblog」を利用して内容を確認するという方法があります。

これらの DBCC や関数はアンドキュメントとなっており、詳細な情報は公開されていません。

Read the rest of this entry »

SQL Server のパフォーマンスモニターとして、SQL Batch Resp Statistics という項目があります。
この項目は、SQL のクエリをバッチという単位で集計した際の次のような観点の情報を確認することができます。

• 特定の実行時間 (Elapsed Time) の範囲のバッチ実行回数とバッチ実行時間の合計
• 特定の CPU 使用時間 (CPU Time) の範囲のバッチ実行回数とバッチ実行時間の合計

この項目は「インスタンス内でどのような時間を消費しているクエリが実行されているか？」を把握するのに役に立つ情報となっており、単体でも便利なのですが、他の情報と組み合わせることでさらに活用の幅が広がります。

本投稿では、「CPU 使用時間の範囲のバッチ情報」を活用した方法についてまとめてみたいと思います。

Read the rest of this entry »

Azure SQL Database Edge は、x64 ならびに ARM64 のデバイス上で動作させることができる、コンテナーの SQL Server となります。

SQL Database Edge を稼働させるための準備として、RaspberryPi 4B (ラズベリーパイ4 / ラズパイ4) を購入したので下準備として Docker と IoT Edge ランタイムを動作させるまでの方法をメモとして残しておきたいと思います。

IoT 関連は全く触ってきておらず、ラズパイを使うのも初めてに近いので、そもそもとして間違っていることがあるかもしれません (

Read the rest of this entry »

SQL Server 2016 以降ではクエリプロファイリングにより、実行中のクエリの情報の分析容易性が向上しています。

• クエリ プロファイリング インフラストラクチャ

この機能は、かなり強力であり、実行中のクエリに対して、様々なアプローチが可能となります。
活用の方法として「インデックスの再構築」と組み合わせた方法を紹介したいと思います。

今回は SQL Server 2017 を例としています。

Read the rest of this entry »

SQL Server の sys.dm_exec_requests や、sys.dm_tran_locks 等の DMV では、どのオブジェクトに起因して待機が発生しているかというリソースの情報が出力されることがあります。

本投稿では、待機要因となっているリソースの見方について見ていきます。

英語の情報となりますが、Decoding Key and Page WaitResource for Deadlocks and Blocking が詳しいかと思います。

Read the rest of this entry »

SQL Server では、「待ち事象」の情報を確認することでボトルネックの解析の一助とすることができます。

クエリを実行し、処理を実行する際には、次の状態を推移しながら処理が進められます。
「待機状態」に入っている処理については、何らかの処理の実行を阻害する要因があり、実行効率が低下している状態となっていると考えられます。
(阻害する要因はハードウェアリソースの性能限界や、ロックの競合のような論理的な要因等、様々なものがあります)

SQL Server では、DMV やパフォーマンスモニターで待ち事象 (待機状態に入っていた状態) の情報を取得することができますが、それぞれの情報が「どのようなタイミングでカウントアップされるか」ということを意識しておくことは重要なポイントの一つとなります。

それでは、各情報の取得と、待ち事象がカウントアップされるタイミングについて見ていきたいと思います。

Read the rest of this entry »