SQLCLR_ASSEMBLY is recorded while a thread waits for access to the list of loaded assemblies in an appdomain. When CLR code runs, the host tracks which assemblies are loaded per domain, and threads consulting or updating that list briefly serialise on it.
It is bookkeeping inside the CLR hosting layer, adjacent to SQLCLR_APPDOMAIN in the same machinery.
Is It a Problem?
Rarely; it has not been a contention point, and normal CLR workloads generate only traces. It can tick up during bursts of assembly loading, which mostly means appdomain restarts (every reload re-loads every assembly in the domain) or deployments swapping assemblies. In both cases the assembly-list wait is a symptom of the churn, not the cost driver.
Sustained visibility here almost always accompanies SQLCLR_APPDOMAIN activity, and the diagnosis is shared: why are domains cycling?
Common Causes
- Assembly loading during appdomain startup or after deployments.
- Appdomain unload/reload cycles multiplying load events.
- Many distinct assemblies in heavy first-call use.
What To Do
- Read it with
SQLCLR_APPDOMAINand the error log’s appdomain messages; stability there quiets this wait too. - Consolidate micro-assemblies where practical; fewer, larger assemblies mean fewer list operations.
- Otherwise leave it alone; there is no direct knob.
How To See It
Rank it against everything else with Get-WaitStatistics; expect traces unless appdomains are churning.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply