SQL Server / SQL Database アーキテクチャ ドキュメント
絵で見てわかる SQL Server の仕組み が発売されましたので一通り読んでみました
2020/9/14 に 11 年前に発売された 平山さん の著書である 絵で見てわかるSQL Serverの内部構造 の改訂版となる 絵で見てわかるSQL Serverの仕組み という SQL Server の書籍が発売されました。
Kindle 版の販売がまだ先だったので、紙の書籍を購入したものが今日届き、一通り目を通すことができましたので感想などを。
最新の SQL Server をターゲットとして、日本語で内部の動作に触れている書籍は、現時点ではこの書籍だけで、前作と同様に今回の改定版も良著ですので、「SQL Server を単純に操作するのではなく、内部動作を理解して製品を使用できるようになりたい」という思いがある方にとっては、最適な書籍ですので一度読まれてみてはいかがでしょうか。
Azure Data Factory の Private Link 対応が GA したので試してみる
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 をコールする (MSI を使用しないケース)
Azure Data Factory の Web Activity を使用すると、パイプライン内で REST API をコールすることができます。
Azure のリソースにアクセスするのであれば、Data Factory の MSI を使用するアクティビティを作成すればよいのですが、MSI を使わない場合、どうやるのかを忘れて最初から調べなおすことがあるので、まとめておこうかと。
Azure Data Factory の MSI を使用するケースについては、次の情報を参照してください。
-
マネージド ID (Web Activity で MSI を使用する)
今回は Data Factory の実行状況を確認するための REST API をコールしてみます。
検証目的で UPDATE STATISTICS で統計情報を手動で書き換える (update_stats_stream_option)
本投稿の内容を使用すると、クエリの実行プランに大きく影響を与えますので、検証目的でクエリの実行プランを変更する場合以外、本投稿の内容は使用しないでください。
ドキュメントにも「サポートされていない」ことが明記されており、本番環境で実行して、クエリの実行に大きく影響を与えても一切の責任は取りません。
クエリの実行に影響があると、本業務に影響を与える環境に対して実施する場合は自己責任で実施してください。
ということで、検証以外では、本投稿の内容は使用しないでください。
この投稿の内容は、クエリの実行プランが大きく変わり、性能にダイレクトに影響を与えます。
本来の目的はクローンデータベースを作成する際に、検証目的で統計情報の復元を行うためのものですので、統計情報の固定に使おうとすると、予期せぬ動作を引き起こす可能性が十分にあります。
非クラスター化インデックス作成時の処理状況 (進行状況) を確認する
以前書いた、SQL Server のクエリプロファイリングの活用 の応用ではありますが、この方法は、非クラスター化インデックスを新規に作成するときにも活用することができます。
Enterprise Edition であれば、オンラインのインデックス操作でインデックスを作成することもできますが、データ量が大きい場合、実際のインデックス作成の状況がどこまで進んでいるのかを確認したいということはあると思います。(クエリの処理状況がわかると、メンテナンス作業を実行している最中の心理的安定性にもつながりますので)
クエリ プロファイリング インフラストラクチャ の機能を使用しており、SQL Server 2016 SP1 / Azure SQL Database であれば、オーバーヘッドを抑えて使用することができるかと。
