前回の Update: SQL Server / SQL Database Update (2024/01~2024/03/03)
前回の投稿以降の Update をまとめておきたいと思います。
- Azure Updates
- Preview
- GA
- Azure SQL Blog
- SQL Server Blog
- SQL Server
- SQL Database
- Azure Arc
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
前回の Update: SQL Server / SQL Database Update (2024/01~2024/03/03)
前回の投稿以降の Update をまとめておきたいと思います。
私が使用している Azure SQL Database で SAL 未達の調査と返金要求の申請をする機会がありましたので、その際に実施した内容をまとめておきたいと思います。
本日、Microsoft Fabric の Mirroing Databases の機能が Public Preview で提供されました。
Mirroring については、What is Mirroring in Fabric? のドキュメントツリーから確認することができます。
Mirroring は SQL Database だけでなく Cosmos DB / Snowflake からも同期することができ、面白そうな機能ですね。
基本的な内容についてはドキュメントを確認すれば把握できますが、SQL Database からの連携について、実際に設定しながら試してみて気づいた内容を残しておきたいと思います。
本日、アナウンスがありましたが Database Watcher for Azure SQL が Public Preview で提供開始されました。
ドキュメントも公開されています。
SQL Server ベースの環境向けの Visual Studio のプロジェクトとして、データベースプロジェクト があります。
このプロジェクトは当初はオフラインデータベース開発向けの機能として実装が行われていましたが、昨今は SQL Server ベースの環境の CI/CDでも活用が行われています。
データベースプロジェクトについては Visual Studio (or SSDT) だけでなく、Azure Data Studio (ADS) の SQL Database プロジェクトの拡張機能でも作成することができます。
最近、データベースプロジェクトを活用した CI/CD について調査を行っていましたので、分かった内容をまとめておきたいと思います。
2024 年に入ってからの SQL Server / SQL Database のアップデートをキャッチアップできていなかったので、一度まとめておきたいと思います。
SQL Database で PITR の進捗状況を確認する方法として、次の DMV を確認するという方法があります。
この DMV では「percent_complete」という項目が提供されており、この値から操作の進行状況を取得することができます。
当初は「0 / 50 / 100」の 3 段階で進行状況を示していたのですが、昨年、Monitor Database Restore progress at more granular level のような機能改善が行われ、「0 / 1-99 / 100」というように操作の進行状況に合わせた値の表示が行われるようになったというアナウンスがありました。
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 の性能を変更する場合には次の動作が行われます。
データベース用に新しいコンピューティング インスタンスを作成する
要求されたサービス レベルとコンピューティング サイズを持つ新しいコンピューティング インスタンスが作成されます。 サービス レベルとコンピューティング サイズの変更の組み合わせの中には、新しいコンピューティング インスタンスにデータベースのレプリカを作成する必要があるものがあります。これにはデータのコピーも含まれ、全体の待機時間に大きく影響する場合があります。 いずれにしても、この手順の間、データベースはオンラインのままで、接続は元のコンピューティング インスタンスのデータベースに引き続き向けられます。
変更後のサイズによっては、データベースのコピー機能が使用され新しいインスタンスにデータの同期が行われ、コピー完了後に切り替えを行うというような動作により、新しい環境の提供が行われます。
データの同期が行われる場合、データベースのサイズによって変更が完了するまでに必要となる時間が変動するのですが、この時間の予測を標準で提供されている機能より精度を高くして把握する方法について考えてみました。