sys.dm_clr_appdomains (Transact-SQL)
サーバー内のアプリケーション ドメインごとに 1 行のデータを返します。アプリケーション ドメイン (AppDomain) は、Microsoft .NET Framework 共通言語ランタイム (CLR) 内の構造であり、アプリケーションの分離の単位となります。このビューを使用すると、Microsoft SQL Server 内で実行されている CLR 統合オブジェクトの理解やトラブルシューティングに役立ちます。
CLR 統合マネージ データベース オブジェクトにはいくつかの種類があります。これらのオブジェクトに関する一般的な情報については、「CLR (共通言語ランタイム) 統合によるデータベース オブジェクトの構築」を参照してください。これらのオブジェクトを実行するたびに、SQL Server により、必要なコードを読み込んで実行することができる AppDomain が作成されます。AppDomain の分離レベルは、所有者ごとのデータベースにつき 1 つの AppDomain です。つまり、1 人のユーザーによって所有されるすべての CLR オブジェクトは、常に同じ AppDomain で実行されます。AppDomain は、コードの実行が終了した後に破棄されません。代わりに、以降の実行に備えて、メモリ内にキャッシュされます。その結果、パフォーマンスが向上します。
詳細については、「アプリケーション ドメイン」を参照してください。
列名 |
データ型 |
説明 |
|---|---|---|
appdomain_address |
varbinary(8) |
AppDomain のアドレス。1 人のユーザーが所有するすべてのマネージ データベース オブジェクトは、常に同じ AppDomain に読み込まれます。この列を使用すると、sys.dm_clr_loaded_assemblies のこの AppDomain に現在読み込まれているすべてのアセンブリを参照することができます。 |
appdomain_id |
int |
AppDomain の ID。各 AppDomain には一意の ID が付けられています。 |
appdomain_name |
varchar(386) |
SQL Server によって割り当てられる AppDomain の名前。 |
creation_time |
datetime |
AppDomain が作成された時刻。AppDomains はパフォーマンス向上のためにキャッシュされて再利用されるため、creation_time がコードの実行時刻を示しているとは限りません。 |
db_id |
int |
この AppDomain が作成されたデータベースの ID。2 つの異なるデータベースに格納されたコードで、1 つの AppDomain を共有することはできません。 |
user_id |
int |
この AppDomain で実行可能なオブジェクトを所有するユーザーの ID。 |
state |
nvarchar(128) |
AppDomain の現在の状態の記述子。AppDomain には作成から削除まで、さまざまな状態があります。詳細については、このトピックの「解説」を参照してください。 |
strong_refcount |
int |
AppDomain への強参照の数。この数は、この AppDomain を使用している現在実行中のバッチの数を表します。このビューを実行すると、強力な参照カウントが作成されます。現在コードが実行されていない場合でも、strong_refcount の値は 1 になります。 |
weak_refcount |
int |
AppDomain への弱参照の数。この数は、AppDomain 内のキャッシュされているオブジェクトの数を表します。マネージ データベース オブジェクトを実行すると、それ以降再利用できるように SQL Server によってこのオブジェクトが AppDomain 内にキャッシュされます。その結果、パフォーマンスが向上します。 |
cost |
int |
AppDomain のコスト。コストが高くなると、この AppDomain がメモリ不足でアンロードされる可能性も高くなります。コストは、通常はこの AppDomain を再作成するのに必要なメモリの量によって決まります。 |
value |
int |
AppDomain の値。値が小さくなると、この AppDomain がメモリ不足でアンロードされる可能性が高くなります。通常はこの AppDomain を使用している接続またはバッチの数によって、この値が決まります。 |
説明
dm_clr_appdomains.appdomain_address と dm_clr_loaded_assemblies.appdomain_address の間には一対多のリレーションシップがあります。
次の表に、状態の有効値とその説明、およびそれらの値が AppDomain のライフサイクルでいつ生じるかを示します。この情報を使用すると、Windows イベント ログを解析しなくても、AppDomain のライフサイクルを追跡し、AppDomain インスタンスの疑わしいアンロードや反復的なアンロードを監視することができます。
AppDomain の初期化
状態 |
説明 |
|---|---|
E_APPDOMAIN_CREATING |
AppDomain は作成中です。 |
AppDomain の使用状況
状態 |
説明 |
|---|---|
E_APPDOMAIN_SHARED |
ランタイム AppDomain は複数のユーザーが使用できる状態です。 |
E_APPDOMAIN_SINGLEUSER |
AppDomain を DDL 操作で使用できる状態です。これらは E_APPDOMAIN_SHARED とは異なり、CLR 統合の実行に DDL 操作ではなく共有 AppDomain が使用されます。このような AppDomain は他の同時実行操作から分離されます。 |
E_APPDOMAIN_DOOMED |
AppDomain はアンロードされるようスケジュールされていますが、AppDomain 内のスレッドが現在実行中です。 |
AppDomain のクリーンアップ
状態 |
説明 |
|---|---|
E_APPDOMAIN_UNLOADING |
SQL Server が CLR に対し、AppDomain をアンロードするよう要求しました。これは通常、マネージ データベース オブジェクトを含むアセンブリが変更されたか、破棄されたことが原因です。 |
E_APPDOMAIN_UNLOADED |
CLR が AppDomain をアンロードしました。これは通常、ThreadAbort、OutOfMemory、またはユーザー コード内で処理が記述されていない例外によるエスカレーション プロシージャの結果です。 |
E_APPDOMAIN_ENQUEUE_DESTROY |
AppDomain が CLR でアンロードされ、SQL Server によって破棄されるように設定されました。 |
E_APPDOMAIN_DESTROY |
AppDomain は SQL Server によって破棄の処理が実行中です。 |
E_APPDOMAIN_ZOMBIE |
AppDomain は SQL Server によって破棄されました。ただし、AppDomain へのすべての参照がクリーンアップされたわけではありません。 |
権限
データベースに対する VIEW SERVER STATE 権限が必要です。
例
次の例は、特定のアセンブリについて AppDomain の詳細を表示する方法を示しています。
select appdomain_id, creation_time, db_id, user_id, state
from sys.dm_clr_appdomains a
where appdomain_address =
(select appdomain_address
from sys.dm_clr_loaded_assemblies
where assembly_id = 500)
次の例は、特定の AppDomain 内のすべてのアセンブリを表示する方法を示しています。
select a.name, a.assembly_id, a.permission_set_desc, a.is_visible, a.create_date, l.load_time
from sys.dm_clr_loaded_assemblies as l
inner join sys.assemblies as a
on l.assembly_id = a.assembly_id
where l.appdomain_address =
(select appdomain_address
from sys.dm_clr_appdomains
where appdomain_id = 15)