SQLエラーログでこのエラーに時々気づきました。
spid20s、Unknown、AppDomain 79(master.sys [runtime] .78)は、メモリ不足のためにアンロード用にマークされています。
SQL Server 2016 SP1 CU5を使用しています(パッチの適用を強く求めていますが、会社には抵抗があります)。
私が読んだすべてのものは、CLR固有ではないメモリプレッシャーを示しています。起動パラメータのMemToLeave
設定の変更に関する提案があります。これは、SQL Serverの新しいバージョンでも同じですか?それとも他の推奨事項はありますか?
特に64ビットSQL Serverを使用している場合は、MemToLeave
設定について心配する必要がほとんどなくなるように、SQL Server 2012でメモリアーキテクチャが変更されました。また、SQL Server 2016(使用中)以降、SQL Serverは64ビットでのみ使用できます(「 データベースエンジンの新機能-SQL Server 2016)の上部にある「注意」を参照してください = "ページ)。したがって、いいえ、MemToLeave
について心配する必要はありません。
正しい、「メモリプレッシャー」エラーはSQLCLRに固有のものではありません。これらのエラーはメモリプレッシャーの原因を示しているのではなく、メモリプレッシャーの影響によって何が影響を受けているのか(とにかく原因を正確に洞察するための可能な方法はないと思います。つまり、プロセスが10個ある場合)メモリを占有している場合、実際にはどの組み合わせが原因ですか?完全に有効である可能性があるため、最大のチャンクを占有しているとは限りません)。メモリプレッシャーは、プランキャッシュやバッファープール(つまり、メモリに読み込まれたデータページ)のフラッシュなど、エラーログに表示されない可能性のある他の領域にも影響を与えます。
SQLCLRを使用する組み込みの機能がいくつかあり、部分的なリストは次のとおりです。
FORMAT
PARSE
TRY_PARSE
AT TIME ZONE
(SQL Server 2016以降)COMPRESS
(ただしUNCOMPRESS
は不可、SQL Server 2016以降)それらの1つ以上(またはおそらく上記に記載しなかったもの)がシステムで影響を受けています。その情報の(master.sys[runtime].78)
の部分に2つの手がかりがあり、これがわかります。
master
である(カスタムアセンブリをmaster
にロードすることは決してないと想定している;-))アセンブリの「所有者」(つまりAUTHORIZATION
)はsys
です(アセンブリの所有権をsys
またはINFORMATION_SCHEMA
に割り当てることはできませんSID
)。各アセンブリの所有者を表示する場合は、次を実行します。
SELECT asm.[name] AS [Assembly],
USER_NAME(asm.[principal_id]) AS [Owner],
USER_SID(asm.[principal_id]) AS [OwnerSID]
FROM sys.assemblies asm;
あなたができることは:
これを調べてみてください: https://docs.Microsoft.com/en-us/sql/relational-databases/memory-management-architecture-guide 。特に、現在割り当てられているものに関するクエリ。診断に集中できる場所を提供します。
私は以前にこの問題を抱えていましたが、CLRプロシージャの呼び出しが繰り返されてしまい、完了時にCLRプロシージャが終了することはありませんでした。