「Microsoft SQL Server」が稼働するデータベースシステムを運用する管理者に向け、「動的管理ビュー」の活用を軸にしたトラブル対策のためのノウハウを紹介していきます。今回は、共通言語ランタイム(CLR)統合で作成されたアプリケーションドメインの一覧の出力について解説します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で使用可能な動的管理ビューについて、動作概要や出力内容などを紹介していきます。今回は、共通言語ランタイム(CLR)統合で作成されたアプリケーションドメインの一覧を出力する「sys.dm_clr_appdomains」について解説します。対応バージョンは、SQL Server 2008以降です。
SQL Serverでは、CLR統合を使用することで「Microsoft Visual Basic .NET」や「Microsoft Visual C#」などの .NET Framework言語を使用して、ストアドプロシージャやトリガー、ユーザー定義型、ユーザー定義関数、ユーザー定義集計、ストリーミングテーブル値関数の記述が可能です。
これらのCLR統合により作成されたマネージオブジェクトを実行する場合、SQL Serverは「アプリケーションドメイン(AppDomain)」と呼ばれる分離単位を作成し、その中で必要なコードをロードして実行します。
アプリケーションドメインは、データベース別にアセンブリの所有者ごとに1つ作成されます。データベースや所有者の異なるアセンブリでマネージコードを実行した場合には、新しいアプリケーションドメインが作成されます。マネージオブジェクトの実行が終了しても、アプリケーションドメインは破棄されることなくキャッシュされ、SQL Server内でメモリが不足した場合に破棄されます。
「sys.dm_clr_appdomains」を使用することで、現在のアプリケーションドメインの状態や作成日時、CPU、メモリ使用量など、CLR統合のトラブルシューティングなどに有用な、アプリケーションドメインに関する詳細な情報の一覧を出力できます。
列名 | データ型 | 説明 |
---|---|---|
appdomain_address | varbinary(8) | アプリケーションドメインのアドレス |
appdomain_id | int | アプリケーションドメインのID |
appdomain_name | varchar(386) | SQL Serverにより割り当てられたアプリケーションドメイン名 |
creation_time | datetime | アプリケーションドメインが作成された時刻 |
db_id | int | アプリケーションドメインが作成されたデータベースID |
user_id | int | アプリケーションドメインが作成されたアセンブリの所有者 |
state | nvarchar(128) | アプリケーションドメインの状態 |
strong_refcount | int | 強参照の数。このアプリケーションドメインを使用しているバッチの実行数を反映する。現在実行中のコードが無い場合でも値は1になる |
weak_refcount | int | 弱参照の数。このアプリケーションドメインでキャッシュされたマネージデータベースオブジェクトの数を示す |
cost | int | コスト。値が高いほどメモリ不足でアンロードされる。再作成に必要なメモリ量により算出される |
value | int | 価値。値が低いほどメモリ不足でアンロードされる。アプリケーションドメインを使用する接続数、バッチの数により算出される |
total_processor_time_ms | bigint | アプリケーションドメインで実行中の全スレッドによって使用されたミリ秒単位の合計プロセッサ時間 |
total_allocated_memory_kb | bigint | アプリケーションドメインで行われた全てのメモリ割り当てのKB単位の合計サイズ。すでに解放されたメモリ量も差し引かれない |
survived_memory_kb | bigint | ガベージコレクションの実行後に残された、アプリケーションドメインによって参照されていることが判明しているKB単位の合計サイズ |
アセンブリを4つ登録し、それらを参照するユーザー定義関数を作成しました。1つのアセンブリは別の所有者に設定します(図1)。
この状態で「sys.dm_clr_appdomains」動的管理ビューを出力すると、まだマネージコードを実行していないため、アプリケーションドメインは作成されておらず、何も表示されません(図2)。
4つのアセンブリそれぞれのマネージコードを実行するユーザー定義関数を動かし、「sys.dm_clr_appdomains」動的管理ビューを出力します(図3)。
4つのアセンブリのマネージコードを実行しましたが、アプリケーションドメインはアセンブリの所有者ごとに作成されるため、2つのアプリケーションドメインが出力されました。「appdomain_name」列の値から、アセンブリの所有者が分かります。
次に、多くのメモリを使用するマネージコードを繰り返し実行した後に、「sys.dm_clr_appdomains」動的管理ビューを出力します(図4)。
「creation_time」列の値が変更されており、一度アプリケーションドメインがアンロードされたあとに再作成されたことが分かります。前回作成されたときと、「appdomain_address」列や「appdomain_id」列、「appdomain_name」列の値が変更されました。
※本Tipsは、「Windows Server 2019」上に「SQL Server 2019 CTP2」をインストールした環境を想定して解説しています。
日本ユニシス株式会社所属。Microsoft MVP for Data Platform(2017~)。入社以来 SQL Serverの評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。
日本ユニシス株式会社所属。入社以来SQL Server一筋で評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。社内のプログラミングコンテストで4回の優勝経験も持つ。趣味は輪行で週末は自転車を持っての旅行。目標は色々な日本百選を制覇すること。
Copyright © ITmedia, Inc. All Rights Reserved.
Database Expert 鬯ッ�ョ�ス�ォ�ス�ス�ス�ェ鬮ッ蛹コ�サ繧托スス�ソ�ス�ス�ス�ス�ス�ス�ス�ス�ス�コ鬮」蛹�スス�オ髫エ竏オ�コ�キ�ス�ク�ス�キ�ス�ス�ス�ケ髫エ雜」�ス�「�ス�ス�ス�ス�ス�ス�ス�ウ鬯ゥ蟷「�ス�「�ス�ス�ス�ァ�ス�ス�ス�ス�ス�ス�ス�ュ鬯ゥ蟷「�ス�「髫エ雜」�ス�「�ス�ス�ス�ス�ス�ス�ス�ウ鬯ゥ蟷「�ス�「�ス�ス�ス�ァ�ス�ス�ス�ス�ス�ス�ス�ー