SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server で分散トランザクションを実行する場合、MSDTC (Distributed Transaction Coordinator) を使用して実現を行います。
SQL Server on Linux の当初は MSDTC をサポートしていなかったのですが、SQL Server 2017 CU16 以降は、MSDTC がサポートされ、以下の情報の設定を実施することで SQL Server on Linux でも MSDTC を使用することができるようになりました。
SQL Server on Linux で MSDTC を動作させる際の関連情報をまとめておきたいと思います。
SQL Database / SQL Server 2025 では、JSON データ型 をサポートしており、JSON フォーマットのデータを格納するための専用のデータ型を使用することができます。
JSON データ型は「Latin1_General_100_BIN2_UTF8」の照合順序により UTF-8 のエンコードが使用されるという特徴の他に「圧縮用に最適化された、より効率的なストレージ」もメリットとして挙げられています。
通常の文字列データ型と比較して、JSON データ型がどの程度ストレージの格納効率が変化するのかが気になったので、SQL Database で確認してみました。
SQL Server ベースのデータベースエンジンで統計情報の自動更新が発生した際の情報を取得するための方法についてまとめておきたいと思います。
SQL Server のバックアップをシステムデータベースを含めて、バックアップの取得元と異なるサーバーにリストアする際には、次の情報を参考にする機会が多いのではないでしょうか。
異なるサーバーにバックアップをリストアする際にはこれらの情報を参考にしてデータベースのリストアとリストア後の設定変更を行っていきます。
バックアップの取得元でレプリケーションが有効となっていた場合も、この作業だけでリストアを完了することができるのかを調査してみました。
概念検証として実施したため、T-SQL ベースで設定を強制的に変更している箇所がいくつかありますが、実運用環境で実施する際にはレプリケーションの再設定で検討をしたほうが良いかと思います。
SQL Server では、バックアップを取得したサーバー以降のバージョンの SQL Server であれば、異なるサーバー名の環境に対してもデータベースのバックアップをリストアすることができます。
バックアップを取得した環境にリストアする場合は問題ないのですが、他のサーバーにリストアをした際に、データベースの所有者が設定されていない状態になることがありますので、すべてのデータベースに所有者が設定されているかの確認と修正方法を本投稿で記載しておきたいと思います。
今まで、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 を使用して、実行プランをベースとして、どのようなプロンプトを記載すればクエリチューニングの一助となる提案を得ることができるかを自分なりに考えてみました。