SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server でメモリサイズが少ない場合に、バックグラウンド タスクであるリソースモニター (Resource Monitor) の CPU 使用率が上昇する事象として、High CPU consumed by Resource Monitor due to low virtual memory というドキュメントが公開されています。
このような挙動は最新の SQL Server でも想定される動作として発生する可能性があります。
最近、リソースモニターのメモリ調整について動作を把握する必要があったのですが、WPR でリソースモニターの挙動を確認する際の素振りとして、この挙動を調べてみると情報の整理がわかりやすかったので、まとめておきたいと思います。
前回の Update: SQL Server / SQL Database Update (2024/03/04～2024/05/12)
半年近くまとめられていませんでした…。
直近の情報を把握できていないこともあったのでまとめておきたいと思います。
SQL Server
Azure SQL
Azure Arc
SQL Server のクエリチューニングを行う際に、チューニング対象となるクエリの実行プランの結合の処理を問題が発生している処理と同等の方法にして確認を行いたいケースがあります。
結合ヒント が使用できる個所であれば、ヒント句を追加して確認をすればよいのですが、ヒント句が指定できないようなクエリとなっている場合、ヒント句では明示的な制御ができないことがあります。
本投稿では、ヒント句で結合方法が制御できない場合の対応方法の一例を紹介します。
Non-yielding Scheduler については、本ブログでも次の内容で取り上げています。
拡張イベントで Non-yielding の情報を取得したかったのでデバッガーを接続して操作するのが面倒だったので、Process Explorer を使用して発生させたというお話です。
SQL Server のトランザクションレプリケーションで、アーティクル (複製対象となるテーブル) を追加した後には、初期スナップショットの取得が必要となります。
初期スナップショットを取得する際には、パブリケーション内に含まれている全アーティクル (新規追加したアーティクル以外も含む) に対して瞬間的に「SCH_M」のロックが取得されています。
SCH_M のロックは強力なロックとなり、初期スナップショットを取得する際にパブリケーション内のアーティクルに対して実行時間が長いクエリが実行されている場合は、広範囲のブロッキングチェーンの発生の要因となる可能性があります。
本投稿では、初期スナップショットを取得する際の SCH_M のロックですがどのような処理により取得されているのかを確認していきたいと思います。
今回はレプリケーションの初期スナップショット取得を解析のターゲットとしていますが、この考え方については他のロック競合の情報を確認する際にも共通の内容となります。
SQL Server ベースの環境で実行プランのファイル (.sqlplan) の解析を行う際に SolarWinds Plan Explorer を使用することがあります。
SSMS でも実行プランの解析はできますが、複雑な実行プランになった場合は Plan Explorer を使用したほうが効率的に実行プランの解析を行うことができます。
Plan Explorer は実行プランのファイルだけでなく、デッドロックレポート (.xdl) についても解析を行うことができます。
Unable to execute a remote stored procedure over a linked server で解説されている内容と類似のものとなりますが、レプリケーションを使用している環境でも同様の事象が発生する可能性があります。
SQL Server ベースのデータベースのデータをデータウェアハウス / データレイクに移行 / 同期をする際に使用する際に、従来からの ETL のパイプラインを作成することなく、Zero ETL (ゼロ ETL) を使用するというアプローチがあります。
Zero ETL を使用した場合、リッチな ETL のパイプラインを作成することなく、シンプルな設定ベースで、SQL Server ベースのデータベースからデータ同期を行うことが可能となります。
SQL Server ベースのデータベースでも Zero ETL を構築することができますが、その際に使用される機能 / 仕組みの特徴についてまとめておきたいと思います。
FCI (フェールオーバークラスターインスタンス) 環境の SQL Server では、デフォルトの設定で診断ログが取得されています。
グディレクトリに SQLDIAG ログが拡張イベントのファイルとして出力されており、問題が発生した場合にはこのファイルの内容の解析を行うことがあります。
スタンドアロン環境の SQL Server インスタンス (非 FCI の単一サーバー環境) では診断ログは出力されていないのですが、設定を行うことでスタンドアロンインスタンスでも取得を行うことができます。
検証環境には FCI も構築している環境はあるのですが、スタンドアロンインスタンスのほうが検証を実施しやすい内容があるため、本投稿ではスタンドアロンインスタンスで診断ログを取得する方法についてまとめておきたいと思います。
Build 2024 のタイミングで次のアナウンスがありました。
Public Preview として、JSON データ型が発表されており、最近、実際に使用することができるようになりました。
