SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server 2016 以降では、クエリ情報の取得はクエリストアを使用して取得を行うことができるようになり、SQL Server / Azure SQL Database では、この機能 (または、クエリストアを活用した機能) により、クエリ実行情報を取得することが一般的な方法となってきているのではないでしょうか。
SQL Server 2016 より前のバージョンでは、次のような DMV を使用して情報の取得が行われるケースが多かったかと思います。
SQL Server 2016 以降の環境で、クエリストアが有効になっている環境でも、これらの DMV を活用した方が、クエリの実行状態を細かに分析することができるケースがあります。
本投稿では sys.dm_exec_requests を使用したクエリの実行状況の取得について見ていきたいと思います。
SQL Server の処理の実行状況を取得するためのシステムテーブルとして sys.sysprocesses というシステムビューが存在しています。
このシステムテーブルは下位互換のビューとして含まれているため、このテーブルを利用しているクエリについては、対応した DMV への移行が推奨されています。
sysprocesses については、3 種類の DMV を使用することになるのですが、各 DMV から単純にデータをとるだけでは、sysprocesses で「AWAITING COMMAND」となっているセッションを取得することはできません。
クエリストアによる、クエリタイムアウトしたクエリの取得 では、クエリストアの機能を使用して、コマンドタイムアウト (クエリタイムアウト) が発生したクエリの浄法を取得しました。
クエリストアが使用できない環境では拡張イベントを使用しても取得することができますので、書いておこうかと。
SQL Serve のクエリ情報を取得する際には、次のイベントカテゴリの情報を使用することがあるのではないでしょうか?
これらのイベントカテゴリの情報には、Batch / Statement / RPC / SP というようなイベントがあり、クエリの情報を取得する場合には、これらの情報を拡張イベントや SQL トレース (SQL Server Profiler / サーバーサイドトレース を使用して取得を行いますが、これらのイベントカテゴリは、どのようなクエリを実行した際に、どの部分の情報を取得することができる野でしょうか？
本投稿では、これらのイベントカテゴリで取得されている情報の基本的な考え方をまとめてみたいと思います。
イベントの考え方に関しては、拡張イベントと SQL Server Profiler で同様の考え方となりますが、蘇rぞれの機能によってイベントの名称が異なっています。
使用する機能に応じたイベントの対応については SQL トレースのイベント クラスと等価な拡張イベントを確認する のドキュメントで確認できますので、こちらを参照してください。
SQL Server のバージョンアップや、クラウド移行 (SQL Database / Managed Instance への移行) を実施する際のアセスメントと移行を行うためのツールとして Data Migration Assistant (DMA) というツールが公開されています。
このツールでは、Data Migration Assistant を使用した SQL Server 移行評価の実行 の 評価するデータベースと拡張イベントトレースの追加 に記載されているように、拡張イベント (xEvent) をインプットとして、アドホッククエリのシンタックスエラーのチェックを行うことができるようになります。
この、拡張イベントを入力としたアドホッククエリのチェックですが、4/7 時点のドキュメントに書いている内容を実施しても拡張イベントを使用した処理が行われていないように見えました。
先週 MicrosoftR Data Migration Assistant v5.1 の公開が行われたようで、本日この内容を確認していたところ、次の記載がありました。
(最新バージョンを使用すると SQL Server 2019 を移行元として使用することもできるようになっています)
sql_batch_completed event for application / xevent trace assessments
拡張イベントを入力として使用する場合、「sql_batch_completed」をイベントとして取得しないといけないようです。
「sysadmin」ロールのログインで SQL Server エージェントのジョブを設定していると、あまり意識しない点だったのでまとめておこうかと。
ドキュメントとしては Give Others Ownership of a Job となります。
タイトルの内容が気になったので少し動作を確認してみました。
以前から、イベントハブに送信された Azure の診断ログを SQL Databae に取り込むということができていたかと思います。
昨年末ぐらいに、Azure SQL Database Stream Analytics 統合という機能がプレビューとして提供され、SQL Database のブレードからも Stream Analytics によるデータ取り込みの設定を行うことができるようになりました。
ブログのログをイベントハブに送信しながら、Stream Analytics から SQL Database のテーブルにデータ取り込みを実施してみたのでその時の覚書を。
今回はブログのフロントに配置している Front Door の診断ログ (アクセスログ) をイベントハブに送信し、それをテーブルに受け取るような設定を使っています。
(1 か月回していると、それなりの金額になりそうですので、今は BLOB に出力されている JSON を Data Factory 経由で取り込みを行うようにしています。)
先日、SQL Server 2019 now available on Ubuntu 18.04, supported on SLES 12 SP5 というアナウンスがあり、SQL Server 2019 CU3 を使用することで、Ubuntu 18.04 / SELES 12 SP5 のサポートを開始したようです。
というように CU によってサポートされる OS が変わってくるのも SQL Server on Linux の特徴となりそうですね。
Release notes for SQL Server 2019 on Linux の記載も変更されています。
トランザクションレプリケーションの動作を理解する ? ログリーダー編 ? の続きです。
前回の投稿では、「ログリーダー」の動作を確認しました。
ここまでの操作で「ディストリビューターに配信用のデータが格納された状態」となります。
これを「サブスクライバー」に適用させるのが「ディストリビューション エージェント」の動作となり、今回の投稿の対象となる範囲です。
今回の投稿では、データの配信方法は「プッシュサブスクリプション」を対象としています。
