SQL Server 2022 / SQL Database / Managed Instance では、データベースのファイルサイズを削減するためのコマンドである、DBCC SHRINKFILE に WAIT_AT_LOWPRIORITY というオプションが追加されました。
このオプションを使用した場合のデータファイルのサイズ縮小について動作を把握しておきたかったので、調べてみました。
SQL Database で Azure OpenAI を使用したベクトルの類似性検索の記事が勉強になった件
今月 Vector Similarity Search with Azure SQL database and OpenAI という記事が公開されました。
Azure のデータストアでは次のような機能のベクター検索が提供されています。
- Azure Cosmos DB for MongoDB 仮想コアの埋め込みでのベクター検索の使用
- Azure Database for PostgreSQL で pgvector を使用する場合のパフォーマンスを最適化する方法 – フレキシブル サーバー
Azure SQL Database では、ベクターデータの生成 / 格納するためのデータ型 / ベクターインデックスや、ベクトルの類似性検索を行うためのライブラリはないのですが、この記事では JSON 形式のデータや、Azure OpenAI を組み合わせることでベクトルの類似性検索を行っており、勉強になったのでポイントとなると思った箇所をまとめておこうと思います。
SQL Server で接続のプロセスの途中でコネクションタイムアウトを発生させる
SQL Server でコネクションタイムアウトを発生させる方法としては、
- 存在しないサーバーに対しての接続
- シングルユーザーモードのデータベースに対しての接続
を実行することでコネクションタイムアウトを発生させるという方法があります。
これらの方法では初期の接続ができないためエラーとなりますが、運用環境でコネクションタイムアウトが発生するケースとしては接続プロセスの途中で、タイムアウトの設定秒数に達したため、コネクションタイムアウトが発生するということがあります。
このコネクションタイムアウトの状態を意図的に発生させるための方法を残しておきたいと思います。
Azure Monitor メトリックのプラットフォームメトリックについて
Azure のリソースのメトリックは、各リソースの「メトリック」で確認をすることや、 
メトリック エクスプローラー (すべてのサービスのメトリックまたは、Azure Monitor のブレードのメトリック) から確認することができます。 
Azure ではデフォルトで Azure Monitor による情報の取得が行われており、Azure Monitor で使用する監視データのソース にデータソースとして使用できる情報が記載されています。
パフォーマンス情報のようなメトリックについては「プラットフォーム メトリック」として、各リソースの診断設定を設定しなくても情報の取得が行われています。
このプラットフォームメトリックについての情報を確認する際には、どの情報を確認すればよいかをよく忘れてしまうので、まとめておきたいと思います。
SQL Server 2022 で追加された query_antipattern を使用したクエリ情報の取得
Bob Ward の SQL Server 2022 Hidden Gems で解説されているのですが、SQL Server 2022 ならびに Azure SQL Database では、query_antipattern という拡張イベントが追加されています。
MS のブログでも紹介されており、最近、新しい記事も公開されました。
- Watch out for performance problems due to antipattern queries in SQL
- Lesson Learned #367: Query Antipattern and Ring Buffer in Azure SQL Database
この拡張イベントについて、本ブログでも触れておきたいと思います。
Azure Stack HCI ノードを Azure Monitor のデータ収集ルールで情報を取得
Azure Stak HCI クラスターのノードを Azure Monitor のデータ収集ルール (DCR) で情報を取得しようとした場合の手順を理解できておらず、SR で情報を提供していただいたので、内容をまとめておきたいと思います。
Manaed Instance の TDE が有効な DB を SQL Server 2022 にリストアする
先日書いた Manaed Instance の TDE を無効化した DB を SQL Server 2022 にリストアする際の注意点 の続きになり、厳密にはデータベース暗号化キーが含まれているデータベースを SQL Server 2022 にリストアする際の作業となります。
基本的な考え方については、Restoring a SQL Managed Instance database backup to SQL Server 2022 now GA の記載となり、必要な作業については Azure Key Vault を使用した SQL Server TDE 拡張キー管理を設定する となります。
Key Vault へのアクセスに使用されている、拡張キー管理 (Extensible Key Management : EKM) については、Windows でのみサポートされているため、SQL Server on Linux では使用することはできず、現時点では、MI で TDE が有効な DB については、リストア可能な環境は Windows のみに限定されています。
Azure Stack HCI の評価期間の確認と Preview チャネルを使用している場合の評価期間終了後のコスト発生について
Azure Stack HCI は評価版をダウンロードし、任意の環境に展開することができます。
評価期間は 60 日間となっており、この期間であれば Azure Stack HCI のコスト (ホストサービスの料金 / アドオンワークロード (現状は Windows Server サブスクリプション) の料金) を発生させることなく検証を行うことができます。
評価をしている際に、あと評価期間がどれくらい残っているのか、評価完了後にコストが発生した場合、どのタイミング以降の利用についてコストが発生したのかを確認したいことがあります。また、Preview チャネルを使用している場合のコスト発生の考え方が通常の環境とは異なるため、これらの情報をまとめておきたいと思います。
Manaed Instance の TDE を無効化した DB を SQL Server 2022 にリストアする際の注意点
※Azure SQL Managed Instance から SQL Server 2022 へのリストアだけでなく、異なる SQL Server インスタンス間のリストアでも該当します。
Azure SQL Managed Instance (MI) で取得したバックアップについては、SQL Server 2022 にリストアすることができます。
MI からリストア可能なバックアップについては、ユーザーが任意のタイミングで取得したバックアップとなるので「COPY_ONLY」オプションを使用して取得したバックアップの必要があります。
MI で COPY_ONLY バックアップを取得するには条件があり、次のいずれかの条件を満たしている必要があります。
- TDE で暗号化されていないデータベース
- ユーザーマネージドキーを使用して TDE を設定している
「サービスマネージドキー」による TDE については、TDE のキーをユーザーが制御できないものとなるため、サービスマネージドキーを使用し TDE を実行している DB については、COPY_ONLY バックアップを取得することができません。
今回は「1.」で記載した TDE を無効にした状態のバックアップを SQL Server 2022 にリストアする際の注意点となります。
「2.」についても、SQL Server 2022 にリストアすることができるのですが、SQL Server 2022 では、Azure Key Vault を使用した SQL Server TDE 拡張キー管理を設定する の設定で、ユーザーマネージドキーの Key Vault へのアクセスをする必要があり、こちらはこちらで面倒ではあるのですが、それについては別の投稿で書こうと思います。
本投稿で対象としている TDE の無効化ですが、「TDE を有効にしている DB で、TDE を無効に変更」した場合が該当します。
「最初から TDE を無効の状態にしている DB」については、本投稿の事象は発生しません。
Power BI / Microsoft Fabric のレポート開発における Git 統合 / 開発者モードについて
Build 2023 で発表されていますが、Power BI / Microsoft Fabric のレポート開発において Git 統合 / 開発者モードが提供されます。
アナウンスについては Introducing git integration in Microsoft Fabric for seamless source control の Git integration and Power BI Desktop ‘Developer Mode’ となるのではないでしょうか。
Power BI のレポート作成を行う際に、従来までの Power BI ファイル (pbix) では 1 ファイルで管理されるため (pbix は zip 圧縮されたファイルのため、実際には複数のファイルで構成はされているのですが) 、ファイルをソース管理で管理するには効率が悪い点があったかと思います。
今回から導入される Git 統合 / 開発者モードでは、Power BI のレポートを作成する際に Power BI プロジェクト (pbip) や Power BI レポート (pbir) というようなファイルを使用して、レポートの構成要素に応じた複数のファイルで管理されるようになります。
この機能についてどの情報を確認すればよいかが、公開されている情報が増えてきたので、内容をまとめておきたいと思います。