SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server / Azure SQL Database では、Always Encrypted という暗号化の機能があります。
この機能は、列マスターキー (CMK) と列暗号化キー (CEK) という 2 種類の暗号化のためのキーを使用して、データの暗号化を行います。
データは常に暗号化された状態で取り扱われ、暗号化を指定した列についてはディスク / メモリ / ネットワーク上で常に暗号化された状態となり、適切な暗号化キーにアクセスができない状態では、SQL Server の管理者であったとして、暗号化されたデータを複合化することができないという特徴があります。
本ブログでもこの機能について触れていたことはありますが、改めて思い出す必要がありましたので情報を残しておきたいと思います。
以前、次の投稿で並列クエリになるようにする調整方法を投稿しました。
最近、これらの情報を確認する機会がありましたので、改めて情報を整理しておきたいと思います。
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」を使用して、情報を確認する必要があります。
これらの情報を使用して「どのキーに対してロックが取得されたのか？」を確認する方法を考えてみました。