Non-yielding Scheduler については、本ブログでも次の内容で取り上げています。
- 調査のために意図的に Non-yielding scheduler の状態を作り出す
- SQL Server 2022 で Non-yielding Scheduler 発生時の出力内容が追加されていました
拡張イベントで Non-yielding の情報を取得したかったのでデバッガーを接続して操作するのが面倒だったので、Process Explorer を使用して発生させたというお話です。
Archive for the ‘SQL Server’ Category
Process Explorer を使用して Non-yielding Scheduler を発生させる
トランザクションレプリケーションでアーティクル追加後の初期スナップショット取得時のロック競合について
SQL Server のトランザクションレプリケーションで、アーティクル (複製対象となるテーブル) を追加した後には、初期スナップショットの取得が必要となります。
初期スナップショットを取得する際には、パブリケーション内に含まれている全アーティクル (新規追加したアーティクル以外も含む) に対して瞬間的に「SCH_M」のロックが取得されています。
SCH_M のロックは強力なロックとなり、初期スナップショットを取得する際にパブリケーション内のアーティクルに対して実行時間が長いクエリが実行されている場合は、広範囲のブロッキングチェーンの発生の要因となる可能性があります。
本投稿では、初期スナップショットを取得する際の SCH_M のロックですがどのような処理により取得されているのかを確認していきたいと思います。
今回はレプリケーションの初期スナップショット取得を解析のターゲットとしていますが、この考え方については他のロック競合の情報を確認する際にも共通の内容となります。
SolarWinds Plan Explorer を使用した xml_deadlock_report の解析
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 ベースのデータベースからの Zero ETL について (2024/07 版)
SQL Server ベースのデータベースのデータをデータウェアハウス / データレイクに移行 / 同期をする際に使用する際に、従来からの ETL のパイプラインを作成することなく、Zero ETL (ゼロ ETL) を使用するというアプローチがあります。
Zero ETL を使用した場合、リッチな ETL のパイプラインを作成することなく、シンプルな設定ベースで、SQL Server ベースのデータベースからデータ同期を行うことが可能となります。
SQL Server ベースのデータベースでも Zero ETL を構築することができますが、その際に使用される機能 / 仕組みの特徴についてまとめておきたいと思います。
スタンドアロン環境の SQL Server インスタンスで診断ログ (SQLDIAG ログ) を取得する
FCI (フェールオーバークラスターインスタンス) 環境の SQL Server では、デフォルトの設定で診断ログが取得されています。
グディレクトリに SQLDIAG ログが拡張イベントのファイルとして出力されており、問題が発生した場合にはこのファイルの内容の解析を行うことがあります。
スタンドアロン環境の SQL Server インスタンス (非 FCI の単一サーバー環境) では診断ログは出力されていないのですが、設定を行うことでスタンドアロンインスタンスでも取得を行うことができます。
検証環境には FCI も構築している環境はあるのですが、スタンドアロンインスタンスのほうが検証を実施しやすい内容があるため、本投稿ではスタンドアロンインスタンスで診断ログを取得する方法についてまとめておきたいと思います。
SQL Database の JSON データ型のデータ格納効率を確認してみる
Build 2024 のタイミングで次のアナウンスがありました。
Public Preview として、JSON データ型が発表されており、最近、実際に使用することができるようになりました。
データベース (データストア) 内での AI 関連の機能の利用について (2024/06 版)
データベース (データストア) 内で AI に関連する機能の利用が様々なデータベース時で実施することができるようになっています。
私が確認した範囲でのデータベース (またデータベースに関連するサービス) になりますが、どのように AI の機能を利用することができるのかをまとめておきたいと思います。
SQL Server on Azure VM の SQL Server 日本語化後の IaaS Agent の導入を Bicep で実施する
Azure では、Marketplace から SQL Server インストール済みの VM イメージが公開されており、Azure VM で SQL Server を使用する場合は、このイメージで展開して PAYG で利用するのが一般的かと思います。
イメージは英語版を使用して構築されているため、日本語化する場合には、当ブログで書いた SQL Server on Azure VM (インストール済みイメージ) の日本語化 (2021/1 版) の方法や、SQL Server Support Blog で公開されている次の記事の対応を行う必要があります。
基本的な作業としては、次の流れとなるのではないでしょうか。
- OS に日本語の言語パックをインストールし、各種言語設定を日本向けに設定
- 導入済みの英語版 SQL Server / SSMS をアンインストール
- SQL Server の日本語版評価版メディアをダウンロードして「C:\SQLServerFull」内のプロダクトキーでインストール
- 日本語版の SSMS をインストール
- SQL Server IaaS Agent 拡張機能を Remove-AzSqlVM 等で登録解除
- New-AzSqlVM で SQL Server IaaS Agent 拡張機能を登録
基本的な作業の流れとしてはこのようになりますが、この手順だけでは、VM の展開時に指定した SQL Server 構成の設定はクリアされた状態となってしまっています。
展開時に指定した内容と同等の設定で IaaS Agent を導入するためには、New-AzSqlVM で様々なオプションを指定して再導入をする必要があるのですが、オプションを一つ一つ設定するのは手間がかかるため、今回はその設定を Bicep で実施してしまおうというのが今回の趣旨となります。
JDBC で HikariCP を使用した SQL Server (SQL Database) への接続について調べてみる
JDBC で接続をする際のコネクションプールで使用するライブラリとして HikariCP があります。
HikariCP を使用して SQL Server に接続をする際の挙動について、いくつか調査する必要があったのでその時に確認した内容を残しておきたいと思います。