SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
今まで、SQL Server のバージョンアップ / SQL Server ベースの環境間の移行に使用することができるツールとして、Data Migration Assistant (DMA) というツールが提供されていました。
しかし、2024/06/29 にドキュメントの更新が行われ、DMA は非推奨の機能となりました。
データベースの移行については Azure Data Studio の SQL Migration 拡張機能 で代替することが可能なのですが、データベースの評価については Azure Data Studio (ADS) の機能は DMA よりリッチな機能となっておらず、この部分を代替する機能が提供されていない状態となっていました。
SQL Server /SQL Database のような SQL Server ベースのデータベースエンジンで、設定可能な権限を確認する際には、権限 (データベース エンジン) / 権限の階層 (データベース エンジン) に記載されている Database Engine Permissions Poster を確認するのが定番の方法となるかと思います。
しかし、この情報は SQL Server 2017 ベースの情報となっており、数世代前の SQL Server の情報となります。
現在の SQL Server ベースの環境でもこの情報は有益ではあるのですが、最新バージョンで増えた権限については確認することはできません。
SQL Server で取得されたロックの情報を確認する方法として lock_aquired / lock_released イベントを拡張イベントで取得する方法があります。
取得されているロックを確認する方法としては sys.dm_tran_locks を参照する方法もあります。
この DMV から情報を取得した場合は、次の画像のように、resource_description から、どのロックリソース (%%lockres%%) のキーに対してロックが取得されているのかを確認することができます。
しかし、DMV の参照はトレースとして情報を時系列で取得することは難しく、ロックのような短時間で取得される内容が細かに変わっていくような特性のある情報については DMV を連続でダンプしても解析することは難しいです。
本投稿を各モチベーションとなったのは「キーに対してどのような順序でロックが取得されているか」を確認したかったのですが、このような情報については DMV で取得することは難しく、拡張イベントのようなイベント駆動のトレースの情報を取得する必要があります。
しかし拡張イベントで「取得されるロック」の情報を確認した場合 、上述の DMV のような resource_description のような可視性の高い情報が無く、次の画像のように、「resource_x」「associated_object_id」を使用して、情報を確認する必要があります。
これらの情報を使用して「どのキーに対してロックが取得されたのか？」を確認する方法を考えてみました。
SQL Database で T-SQL で Vector データ型用の埋め込みを作成する際には、sp_invoke_external_rest_endpoint で Azure Open AI の 埋め込みのモデル を使用して、ベクトルデータを作成するという方法があります。
SQL Database の Vector データ型 の次元の最大数は「1998」となっており、これを変更することはできません。
Azure Open AI の埋め込みのモデルとしては、次のモデルを使用することができます。
ada / embedding-3-small であれば、1536 の次元となるため、Vector データ型にはそのまま登録することができるのですが、text-embedding-3-large については、単純に呼び出しただけでは 3072 の次元となるため、Vector データ型に登録することができません。
生成 AI (Generative AI) を使用した SQL Server の最適化としては次のような機能があります。
これらの機能は DB から情報を直接取得して解析を行う方法となります。
SQL Server 以外の環境も含まれますが、これ以外の方法としては次のような記事の活用があります。
DBA に関しての作業についても今後は生成 AI を使用して、専門的なスキルが無くても一定のレベルで自動化 / 効率化を行う必要が出てくるのではないでしょうか。
スロークエリの原因を見つけて対処する方法の記事で、SQL Server ベースの環境のクエリチューニングについて触れられていますが、ChatGPT を使用して、実行プランをベースとして、どのようなプロンプトを記載すればクエリチューニングの一助となる提案を得ることができるかを自分なりに考えてみました。
.NET9 で Guid.CreateVersion7 がサポートされたことで、.NET から UUID v7 のフォーマットの GUID を作成することができるようになりました。
SQL Server ベースのデータベースエンジンで UUID v7 フォーマットの GUID を格納するとどのような格納となるのかをまとめておきたいと思います。
SQL Server の UUID v7 サポートについては、すでにフィードバックが Support UUID v7 でフィードバックが上がっていますので、v7 サポートについては、こちらのフィードバックへの Vote も検討いただければと思います。
なお、本投稿では「SQL Server にデータを格納した際の挙動」をメインテーマにしており、格納するためのデータプロバイダーの挙動については触れておりませんので、その点は留意してください。
のいえさんの CysharpのOSS Top10まとめ / Ulid vs .NET 9 UUID v7 / MagicOnion もとても参考になりますのでこちらも確認していただければ。(この話題から本投稿をまとめようと思ったので)
Ignite 2024 で SQL Server 2025 のセッションである SQL Server 2025: an enterprise AI-ready database platform が開催されました。
SQL Server 2025 について解説が行われたセッションは、これが最初のものになるかと思いますが、このセッションの内容をメモとして。
SQL Server 2025 のメインセッションは上記のセッションだと思いますが、それ以外にも SQL Server roadmap: the next gen で Product Manager からSQL Server 2025 に触れられています。
本日から Ignite 2024 が開催されています。
発表内容については Book of News で公開されていますが、Ignite 2024 付近公開された SQL Server / SQL Database の発表についてまとめておきたいと思います。
PASS 2024 で Exciting Announcement: Public Preview of Native Vector Support in Azure SQL Database! として SQL Database のベクターサポートの Public Preview がアナウンスされました。
MI については、今後数か月で Public Preview が公開されるということで、Azure の SQL Server ベースの環境でベクターサポートの一般公開の作業が進められています。
EAP 時点の情報とは多少異なっている内容がありますので、現時点の情報をまとめておきたいと思います。
SQL Server 2025 でもベクターサポートが入りますので、今後の SQL Server でも活用できる知識となるのかと。
以前、Windows 11 / Windows Server 2022 で NVMe にインストールした OS のシステムドライブに SQL Server のインストール時にエラーが発生する件について という投稿を書きました。
これは、4 KB を超えるシステム ディスク セクター サイズに関連するエラーのトラブルシューティング の対応となり、512 バイト / 4KB 以外のネイティブセクターサイズを使用している場合に、データ ファイルのストレージの種類 に記載されているサポートされているネイティブセクターサイズ以外が使用されている状態となり、SQL Server のインストールに失敗するという事象となります。