sys.dm_clr_appdomains (Transact-SQL)
Gilt für: 
SQL Server
Gibt eine Zeile für jede Anwendungsdomäne auf dem Server zurück. Anwendungsdomäne (AppDomain) ist ein Konstrukt in der Common Language Runtime (CLR) von Microsoft .NET Framework, das die Isolationseinheit für eine Anwendung ist. Sie können diese Ansicht verwenden, um CLR-Integrationsobjekte zu verstehen und zu beheben, die in Microsoft SQL Server ausgeführt werden.
Es stehen mehrere Typen von CLR-Integrationsobjekten für verwaltete Datenbanken zur Verfügung. Allgemeine Informationen zu diesen Objekten finden Sie unter Building Database Objects with Common Language Runtime (CLR)-Integration. Wenn diese Objekte ausgeführt werden, erstellt SQL Server eine AppDomain , unter der sie den erforderlichen Code laden und ausführen kann. Die Isolationsstufe für eine AppDomain ist eine AppDomain pro Datenbank pro Besitzer. Das heißt, alle CLR-Objekte, die einem Benutzer gehören, werden immer in derselben AppDomain pro Datenbank ausgeführt (wenn ein Benutzer CLR-Datenbankobjekte in verschiedenen Datenbanken registriert, werden die CLR-Datenbankobjekte in verschiedenen Anwendungsdomänen ausgeführt). Eine AppDomain wird nach Abschluss der Ausführung des Codes nicht zerstört. Stattdessen wird er im Arbeitsspeicher für zukünftige Ausführungen zwischengespeichert. Dadurch wird die Leistung verbessert.
Weitere Informationen finden Sie unter Anwendungsdomänen.
| Spaltenname | Datentyp | Beschreibung |
|---|---|---|
| appdomain_address | varbinary(8) | Adresse der AppDomain. Alle verwalteten Datenbankobjekte, die einem Benutzer gehören, werden immer in derselben AppDomain geladen. Sie können diese Spalte verwenden, um alle derzeit in dieser AppDomain geladenen Assemblys in sys.dm_clr_loaded_assemblies nachzuschlagen. |
| appdomain_id | int | ID der AppDomain. Jede AppDomain verfügt über eine eindeutige ID. |
| appdomain_name | varchar(386) | Name der AppDomain , wie von SQL Server zugewiesen. |
| creation_time | datetime | Zeitpunkt, zu dem die AppDomain erstellt wurde. Da AppDomains für eine bessere Leistung zwischengespeichert und wiederverwendet werden, ist creation_time nicht unbedingt der Zeitpunkt, zu dem der Code ausgeführt wurde. |
| db_id | int | ID der Datenbank, in der diese AppDomain erstellt wurde. Code, der in zwei verschiedenen Datenbanken gespeichert ist, kann keine AppDomain freigeben. |
| user_id | int | ID des Benutzers, dessen Objekte in dieser AppDomain ausgeführt werden können. |
| state | nvarchar(128) | Ein Deskriptor für den aktuellen Zustand der AppDomain. Eine AppDomain kann sich in verschiedenen Zuständen befinden, von Erstellung bis Löschung. Weitere Informationen finden Sie im Abschnitt "Hinweise" in diesem Artikel. |
| strong_refcount | int | Anzahl der starken Verweise auf diese AppDomain. Dies entspricht der Anzahl der derzeit ausgeführten Batches, die diese AppDomain verwenden. Die Ausführung dieser Ansicht erstellt einen starken Verweis. Selbst wenn derzeit kein Code ausgeführt wird, weist strong_refcount den Wert 1 auf. |
| weak_refcount | int | Anzahl der schwachen Verweise auf diese AppDomain. Dies gibt an, wie viele Objekte innerhalb der AppDomain zwischengespeichert werden. Wenn Sie ein verwaltetes Datenbankobjekt ausführen, speichert SQL Server es innerhalb der AppDomain für eine zukünftige Wiederverwendung zwischen. Dadurch wird die Leistung verbessert. |
| cost | int | Kosten der AppDomain. Je höher die Kosten sind, desto wahrscheinlicher ist es, dass diese AppDomain unter Speicherdruck entladen wird. Die Kosten hängen in der Regel davon ab, wie viel Arbeitsspeicher erforderlich ist, um diese AppDomain neu zu erstellen. |
| value | int | Wert der AppDomain. Je niedriger der Wert ist, desto wahrscheinlicher ist, dass diese AppDomain unter Speicherdruck entladen wird. Der Wert hängt in der Regel davon ab, wie viele Verbindungen oder Batches diese AppDomain verwenden. |
| total_processor_time_ms | bigint | Gesamtprozessorzeit in Millisekunden, die von allen Threads beim Ausführen in der aktuellen Anwendungsdomäne ab dem Start des Prozesses verwendet wird. Dies entspricht System.AppDomain.MonitoringTotalProcessorTime. |
| total_allocated_memory_kb | bigint | Gesamtgröße, in Kilobyte, aller Speicherbelegungen durch die Anwendungsdomäne seit der Erstellung, ohne Abzug des bei Sammlungsvorgängen freigegebenen Speichers. Dies entspricht System.AppDomain.MonitoringTotalAllocatedMemorySize. |
| survived_memory_kb | bigint | Menge der Daten in KB, die die letzte vollständige Sammlung mit exklusivem Zugriff überdauert haben, und von denen bekannt ist, dass sie von der aktuellen Anwendungsdomäne referenziert werden. Dies entspricht System.AppDomain.MonitoringSurvivedMemorySize. |
Hinweise
Es gibt eine 1:n-Beziehung zwischen dm_clr_appdomains.appdomain_address und dm_clr_loaded_assemblies.appdomain_address.
In den folgenden Tabellen sind mögliche Statuswerte, deren Beschreibungen und deren Auftreten im AppDomain-Lebenszyklus aufgeführt. Sie können diese Informationen verwenden, um dem Lebenszyklus einer AppDomain zu folgen und auf verdächtige oder sich wiederholende AppDomain-Instanzen zu achten, ohne das Windows-Ereignisprotokoll analysieren zu müssen.
AppDomain-Initialisierung
| State | Beschreibung |
|---|---|
| E_APPDOMAIN_CREATING | Die AppDomain wird erstellt. |
AppDomain-Verwendung
| State | Beschreibung |
|---|---|
| E_APPDOMAIN_SHARED | Die Laufzeit-AppDomain kann von mehreren Benutzern verwendet werden. |
| E_APPDOMAIN_SINGLEUSER | Die AppDomain ist für die Verwendung in DDL-Vorgängen bereit. Diese unterscheiden sich von E_APPDOMAIN_SHARED, indem im Gegensatz zu DDL-Vorgängen freigegebene AppDomains für die CLR-Integration verwendet werden, . Solche AppDomains werden von anderen gleichzeitigen Vorgängen isoliert. |
| E_APPDOMAIN_DOOMED | Die AppDomain soll entladen werden, aber es werden derzeit Threads ausgeführt. |
AppDomain-Cleanup
| State | Beschreibung |
|---|---|
| E_APPDOMAIN_UNLOADING | SQL Server hat angefordert, dass die CLR die AppDomain entladen hat, in der Regel, weil die Assembly, die die verwalteten Datenbankobjekte enthält, geändert oder gelöscht wurde. |
| E_APPDOMAIN_UNLOADED | Die CLR hat die AppDomain entladen. Dies ist in der Regel das Ergebnis einer Eskalationsprozedur aufgrund von ThreadAbort, OutOfMemory oder einer unbehandelten Ausnahme im Benutzercode. |
| E_APPDOMAIN_ENQUEUE_DESTROY | Die AppDomain wurde in CLR entladen und festgelegt, dass sie von SQL Server zerstört wird. |
| E_APPDOMAIN_DESTROY | Die AppDomain wird von SQL Server zerstört. |
| E_APPDOMAIN_ZOMBIE | Die AppDomain wurde von SQL Server zerstört. Allerdings wurden nicht alle Verweise auf die AppDomain bereinigt. |
Berechtigungen
Erfordert die VIEW SERVER STATE-Berechtigung in der Datenbank.
Berechtigungen für SQL Server 2022 und höher
Erfordert die VIEW SERVER PERFORMANCE STATE-Berechtigung auf dem Server.
Beispiele
Das folgende Beispiel zeigt, wie Die Details einer AppDomain für eine bestimmte Assembly angezeigt werden:
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);
Das folgende Beispiel zeigt, wie alle Assemblys in einer bestimmten AppDomain angezeigt werden:
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);
Weitere Informationen
sys.dm_clr_loaded_assemblies (Transact-SQL)
Common Language Runtime Related Dynamic Management Views (Transact-SQL)