Desconhecido, o AppDomain 66 (master.sys[runtime].65) está marcado para descarregar devido à pressão da memória

A arquitetura de memória foi alterada no SQL Server 2012, de modo que havia pouca necessidade de se preocupar mais com a MemToLeaveconfiguração, especialmente se estiver usando o SQL Server de 64 bits. E, começando com o SQL Server 2016 (que você está usando), o SQL Server está disponível apenas em 64 bits (consulte a "Observação" na parte superior da página " Novidades no Mecanismo de Banco de Dados - SQL Server 2016 "). Então, não, não se preocupe MemToLeave.

Correto, os erros de "Pressão de memória" não são específicos do SQLCLR. Esses erros não estão dizendo a causa da pressão da memória, mas sim o que está sendo afetado pela pressão da memória (o que duvido que haja alguma maneira possível de realmente ter uma visão da causa de qualquer maneira - quero dizer, se houver 10 processos ocupando memória, qual combinação é realmente a causa? não é necessariamente o que está ocupando o maior pedaço, pois isso pode ser totalmente válido). A pressão da memória também afeta outras áreas que podem não aparecer no log de erros, como liberar o cache do plano e/ou o conjunto de buffers (ou seja, páginas de dados carregadas na memória).

Existem vários recursos internos que usam SQLCLR, sendo uma lista parcial a seguinte:

• Tipos de dados:
  • HierarchyID
  • Geografia
  • Geometria
• Funções:
  • FORMAT
  • PARSE
  • TRY_PARSE
  • AT TIME ZONE(a partir do SQL Server 2016)
  • COMPRESS(mas não UNCOMPRESS; começando no SQL Server 2016)
• Características:
  • Alterar captura de dados
  • Estrutura de Gerenciamento Dinâmico
  • Replicação
  • Gerenciamento Baseado em Políticas
  • Serviços de dados mestre
  • SSISDB (o recurso "Pesquisa Fuzzy")

Um ou mais desses (ou talvez um que não listei acima) é o que está sendo afetado em seu sistema. Existem duas pistas, ambas na (master.sys[runtime].78)parte dessa informação, que nos dizem isso:

1. o banco de dados sendo master(supondo que você nunca carregaria assemblies personalizados em master;-))

2. sendo o "proprietário" (ou seja, AUTHORIZATION) da assembléia sys(não podemos atribuir a propriedade das assembléias a nenhum sysou INFORMATION_SCHEMAporque nenhum desses principais tem um SID). Se você quiser ver o proprietário de cada assembly, execute o seguinte:

   SELECT asm.[name] AS [Assembly],
          USER_NAME(asm.[principal_id]) AS [Owner],
          USER_SID(asm.[principal_id]) AS [OwnerSID]
   FROM   sys.assemblies asm;
   

O que você pode fazer é:

1. Você menciona que esse erro aparece "ocasionalmente", mas não definiu exatamente com que frequência isso realmente acontece. Uma vez por hora é diferente de uma vez por dia, que é diferente de uma vez por semana. A pressão da memória acontece, então, a menos que isso seja mais do que algumas vezes por dia, eu não gastaria muito tempo me preocupando com isso.
2. Adicione mais memória (fisicamente e/ou permitindo que o SQL Server use mais memória do sistema se você tiver o SQL Server restrito a uma quantidade menor)
3. Analise o que está consumindo memória fora do SQL Server para ver se há processos desnecessários no servidor que podem ser transferidos para outros servidores, ou talvez desligados completamente (ou seja, há outros serviços sendo usados ​​e/ou sessões de área de trabalho remota que estão em seguida, executando o SSMS, etc., que estão usando muita memória?)

Pode olhar para isso: https://learn.microsoft.com/en-us/sql/relational-databases/memory-management-architecture-guide . Especialmente a consulta sobre o que está alocado no momento. Ele lhe dará um lugar para se concentrar no diagnóstico.

Eu tive esse problema antes, e acabou sendo chamadas repetidas para um procedimento CLR que nunca se fechava quando era concluído.