SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
先人の知恵を借りて自宅に Azure の S2S VPN の検証環境を固定 IPで作成してみる で投稿しましたが、検証目的で Azure と VPN 接続をできるように TP-Link の ER605 を持っています。(過去からの TP-Link の機器についての批評はいろいろありますが、ファームを最新化して、常時起動の機器としてではなく、ネットワーク系の検証を行う場合だけ取り出して使用しています)
これを使用して Azure にハブネットワークを VNET ベースで作成し、Azure / オンプレミスをスポークとして接続した際に調べた内容をメモとして。
SQL Server では「ENABLE_PARALLEL_PLAN_PREFERENCE」という、クエリの並列化のコストを満たしていない状態でも、並列化の指示を出すための ヒント句 がアンドキュメントなクエリヒントとして提供されています。
このクエリヒントを使用すると、シングルスレッドで実行されているクエリを並列化することができる可能性があるのですが、並列化された際に確認をしておきたいポイントがあります。
SQL Server ベースの環境で、ロック競合に伴うブロッキングの情報を取得する際には、blocked process threshold と Blocked Process Report を使用するのが一般的な取得方法となります。
Azure SQL は変更可能な設定が制限されていますが、Azure SQL Databsae (SQLDB) と Azure SQL Managed Instance (MI) では、どのような設定ができるのかをまとめておきたいと思います。
時間が取れず、直近の SQL Server ベースの環境のアップデートをまとめられていませんでしたので、SQL Server / SQL Database Update (2023/08 上旬) 以降に発表されたものをまとめておきたいと思います。
Azure SQL Database では次のような操作を行うとプライマリからデータ同期を行い複製環境が作成されます。
上記の機能の中ではリソースのスケーリングが一般的に使用される機会が多いものかもしれませんね。
Azure SQL Database の性能を変更する場合には次の動作が行われます。
データベース用に新しいコンピューティング インスタンスを作成する
要求されたサービス レベルとコンピューティング サイズを持つ新しいコンピューティング インスタンスが作成されます。 サービス レベルとコンピューティング サイズの変更の組み合わせの中には、新しいコンピューティング インスタンスにデータベースのレプリカを作成する必要があるものがあります。これにはデータのコピーも含まれ、全体の待機時間に大きく影響する場合があります。 いずれにしても、この手順の間、データベースはオンラインのままで、接続は元のコンピューティング インスタンスのデータベースに引き続き向けられます。
変更後のサイズによっては、データベースのコピー機能が使用され新しいインスタンスにデータの同期が行われ、コピー完了後に切り替えを行うというような動作により、新しい環境の提供が行われます。
データの同期が行われる場合、データベースのサイズによって変更が完了するまでに必要となる時間が変動するのですが、この時間の予測を標準で提供されている機能より精度を高くして把握する方法について考えてみました。
現在の SQL Server では、軽量クエリプロファイリングが提供されており、様々なアプローチで「実行中のクエリの実際の実行プラン」を取得する方法が提供されています。
本機能は SQL Server 2014 SP2 / SQL Server 2016 から実装が行われ、Azure SQL Database / SQL Server 2019 以降では既定で有効になっています。
この機能を活用することで、冒頭に記載した「実行中のクエリの実際の実行プラン」を取得することができます。
Azure Stack HCI に対しての更新プログラムの提供については、更新とアップグレード に記載されています。
デフォルトの設定では Microsoft Update 経由で更新プログラムの適用が行われますが、Windows Server Update Services (WSUS) を使用して更新プログラムの適用を行うことができます。
WSUS で Azure Stack HCI 22H2 に更新プログラムを適用する際には、選択する製品で気を付ける点があったのでメモを。
Azure Migrate を使用して、Windows Server 2012 R2 を Azure VM に移行してみた際の作業メモを投稿しておきたいと思います。
Window Server 2012 R2 は UEFI の物理環境上に構築したものとなります。
SQL Server ではデータベースの操作を行うためには sysadmin 固定サーバーロールまたは db_owner 固定データベースロールの権限が必要となることがあります。
これらの権限はインスタンスまたはデータベースの管理者の権限が付与されるため様々な操作が可能となります。
特定の操作を可能にするため、sysadmin / db_owner の権限を付与する必要があるが、データの秘匿性を担保するためデータへのアクセスについては拒否したいというケースもあるのではないでしょうか。
本投稿では管理者の権限を付与した状態でデータへのアクセスを拒否する方法についてまとめておきたいと思います。
この方法は SQL Server だけでなく SQL Database でも使用することができます。
投稿時点では、Ebdsv5 / Ebdsv5 シリーズのインスタンスを使用した Azure VM では、ディスクとの接続インタフェースとして NVMe を使用することができます。
Ebdsv5 シリーズは VM サイズ: Azure VM 上の SQL Server のパフォーマンスに関するベスト プラクティス で記載されているように、幅広い SQL Server のワークロードを動作させるために推奨される VM となっています。
今後、Azure VM で SQL Server を動作させる際に最適なパフォーマンスを発揮するためには NVMe の利用を検討するシーンも出てくるかと思い検証をして得られた知見をまとめておきたいと思います。