SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Azure Data Factory での Azure Private Link のサポートの提供が開始されました がアナウンスされていますが、Azure Data Factory (ADF) が Private Link をサポートしました。
詳細については、Azure Data Factory 用の Azure Private Link で公開されていますが、何ができるのかいまいちわかっていなかったので試してみました。
デフォルトの Azure 統合ランタイム (Azure IR) ではなく、Self-Hosted Integration Runtime (SHIR) を使用する場合に、通信を Private Endpoint 経由にするために使用するものなんでしょうかね。
データ周りを Private Link 経由にする方法もいろいろと調査しないと。
Azure Data Factory の Web Activity を使用すると、パイプライン内で REST API をコールすることができます。
Azure のリソースにアクセスするのであれば、Data Factory の MSI を使用するアクティビティを作成すればよいのですが、MSI を使わない場合、どうやるのかを忘れて最初から調べなおすことがあるので、まとめておこうかと。
Azure Data Factory の MSI を使用するケースについては、次の情報を参照してください。
マネージド ID (Web Activity で MSI を使用する)
今回は Data Factory の実行状況を確認するための REST API をコールしてみます。
本投稿の内容を使用すると、クエリの実行プランに大きく影響を与えますので、検証目的でクエリの実行プランを変更する場合以外、本投稿の内容は使用しないでください。
ドキュメントにも「サポートされていない」ことが明記されており、本番環境で実行して、クエリの実行に大きく影響を与えても一切の責任は取りません。
クエリの実行に影響があると、本業務に影響を与える環境に対して実施する場合は自己責任で実施してください。
ということで、検証以外では、本投稿の内容は使用しないでください。
この投稿の内容は、クエリの実行プランが大きく変わり、性能にダイレクトに影響を与えます。
本来の目的はクローンデータベースを作成する際に、検証目的で統計情報の復元を行うためのものですので、統計情報の固定に使おうとすると、予期せぬ動作を引き起こす可能性が十分にあります。
以前書いた、SQL Server のクエリプロファイリングの活用 の応用ではありますが、この方法は、非クラスター化インデックスを新規に作成するときにも活用することができます。
Enterprise Edition であれば、オンラインのインデックス操作でインデックスを作成することもできますが、データ量が大きい場合、実際のインデックス作成の状況がどこまで進んでいるのかを確認したいということはあると思います。(クエリの処理状況がわかると、メンテナンス作業を実行している最中の心理的安定性にもつながりますので)
クエリ プロファイリング インフラストラクチャ の機能を使用しており、SQL Server 2016 SP1 / Azure SQL Database であれば、オーバーヘッドを抑えて使用することができるかと。
定期的な更新とか、僕には無理だったんだ…。
ということで 2 週間分をまとめておこうかと。
SQL Server の Enterprise Edition を使用している場合は、「オンラインでのインデックスメンテナンス」を実行することができます。
オンラインインデックスのメンテナンスの動作については オンライン インデックス操作の動作原理 で解説が行われていますが、オンラインのインデックスの最後のフェーズでは、瞬間的ではありますが、「SCH-M」のロックが取得されます。
SQL Server 2016 以降 / SQL Database で利用することができるクエリストアでは、実行されたクエリの種類を、
query_store_runtime_stats から、次のような内容で判断することができます。
アプリケーションから実行されたクエリの状態が、クエリストア上で通常実行として認識される状態の理解が少し足りていなくて、調べたので本ブログでもまとめておこうと思います。
2 回目にして毎週更新ができていません (orz) が、前回更新から本日までの更新情報を。
本日、SQL Server 2019 で Cumulative Update 6 (CU6) がリリースされました。
その中で興味深い改善として次の内容があります。
SQL Server 2019 CU6 から、クエリストアを無効 (OFF) にする際に、同期的なフラッシュを行うことなく、即時にクエリストアを無効化するようにできるようになりました。
How to Turn Off Query Store…in an emergency でも話題に挙げられていますね。
構文としては、次のクエリの実行が可能となるようです。
<br />ALTER DATABASE SET QUERY_STORE = OFF (FORCED) <br />
追記 :
SQL Server 2016 SP2 CU12 でもこの機能がサポートされたようです。
Azure Functions が PowerShell 7.0 をサポートしたこで、PowerShell をランタイムとして使用した関数で、ForEach-Object の Parallel が使用できるようになり、スクリプトブロックを並列で実行することができるようになりました。
以前は Runspace を作成して、並列処理を自分で組む必要がありましたが、ForEach-Object でシンプルな記述で並列に実行できるようになったのはうれしいですね。
このような並列処理は、DB のメトリックを取得するときの収集処理で活用することができ、メトリック収集用のクエリを一つ順次実行するのではなく、いくつかのクエリを並列で実行することで、処理時間を短縮することができ、鮮度の良い情報の取得を行うことができます。
SQL Database では、標準でいくつかの方法で情報が取得されています。
これらの標準機能を使用しても、情報の収集を行うことも、もちろん可能ですが、特定の状況かで必要となる情報が不足していることがあり、SQL Database の状態を確認するためは、追加でメトリックの収集を行う必要が出るケースがあります。
そのような場合、私は PowerShell で SQL Database に対してクエリ実行を行いメトリックの収集を行い、そのメトリックを Log Analytics に格納することで確認をしているのですが、情報を取得 / 可視化を毎回一から作るのも面倒ですので、ある程度まとまった仕組みを EZMonitor (Easy Monitor) として作成してみました。
(情報収取のクエリについては、ざっくりしたもののみ追加しているため、まだ修正の必要がありますが)
↓ GitHub のリポジトリからも、こちらのアイコンからもデプロイできます。
展開時に情報の取得を行う、SQL Database を指定することで、Log Analytics に取得を行ったデータを、次の画像のように可視化することができます。
標準では、5 秒間隔で 4 スレッドで情報を取得しており、Basic / S0 のような低い性能のサービスレベルでは、CPU の使用率を上昇させる要因になります。
CPU 使用率を上昇させた場合は、取得間隔や並列度数を調整してください。
