SQL Serverを再起動する以外に、SQLCLR AppDomainを強制的にリセットする方法はありますか？

SQLCLRで使用されているAppDomainを強制的にリセットしたい。SQL Serverインスタンスを再起動する以外に、どうすればよいですか？

sql-server sql-clr

回答の更新に関する通知を受け取るかどうかはわかりませんが、私はさらに簡単な方法で回答を更新しました:)。

— ソロモンRutzky

回答:

これは少し残忍なことですが、CLRを無効にして再度有効にするとどうなりますか？

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 0;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO

— マックスバーノン
ソース

このメソッドに関する重要な詳細の1つは、STANDBY（読み取り専用）データベースに対して実行したときに機能することです。私が試した他のすべての方法はしません。CLRアセンブリの更新がSTANDBYカタログへのログ配布を介して通常どおり伝播されたため、これが必要でしたが、AppDomainは再読み込みされませんでした。そのため、古いバージョンの.dllからコードを約1日間実行し続けました。

— グレンジャー

@Grangerは非常に興味深く、知っておくと便利です:)。ただし、SQL Server内のバグだと思います。Connectサイトを介してそれを報告することをお勧めします：connect.microsoft.com/SQLServer/Feedback

— Solomon Rutzky

@srutzky-提案をありがとう; 彼らはレポートを「修正しない」として閉じるだけだと思います。設定はサーバー全体であり、カタログごとではありません（「ネストされたトリガー」、「ファイルストリームアクセスレベル」などのように）。それは私が開こうとしているワームのかなりの缶です。

— グレンジャー

@Granger（およびMax）：バグだと思っていたことがはっきりしていません。アンロードの原因となる「CLR有効」設定をリセットすることはバグであると言っていませんでした。ALTER ASSEMBLYアプリドメインをリロード（または少なくともアンロード）しないログ配布を介して伝播されたことがバグだと言っていました。いずれにせよ、私はここで私の答えに追加したさらに簡単な方法を見つけました。この新しい方法をテストする能力があれば、説明したログ配布シナリオでそれが機能するかどうかを知りたいと思っています。

— ソロモンルツキー

他のすべてのアセンブリに影響を及ぼさない、よりエレガントなソリューションがあります。アプリドメイン内のいずれかのアセンブリのPERMISSION_SETを変更するだけです（アプリドメインはユーザーごとです）。

ALTER ASSEMBLY [AssemblyName] WITH PERMISSION_SET = {1 of the 2 levels that 
                                                      this assembly is not current at}

PERMISSION_SETを元の状態に戻す必要があることを覚えておいてください。また、PERMISSION_SETを変更するとアンロードされる前に、アセンブリ内のメソッドにアクセスする必要があります。現在アクティブなアプリドメインに読み込まれていないが、別のアセンブリでアセンブリを変更しても、アプリドメインには影響しません（アプリドメインは、DBごと、ユーザーごと、アセンブリごとではありません）。

更新
上記の方法は、その1つのアプリドメインのみをアンロードする最も細かいアプローチです。ただし、アセンブリを他の2つのレベルのいずれかに設定できる必要があります。としてマークされSAFEたアセンブリの場合、

データベースがに設定されているTRUSTWORTHY ON、または
アセンブリが署名され、ログイン、それ自体が、アセンブリと同じシグネチャに基づいて存在し、いずれかが付与されている非対称キーに基づいているEXTERNAL ACCESS ASSEMBLYか、UNSAFE ASSEMBLY許可を

この場合、TRUSTWORTHY設定ONをオンにしてすぐに戻すOFFと、その特定のデータベース内のすべてのアプリドメインがアンロードされます。

ALTER DATABASE CURRENT SET TRUSTWORTHY ON;
ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;

いずれにしても、データベースに1つのアプリドメインしかない場合（そして、これが95％以上の場合であると思います）、ここで説明する方法はどちらも同じ正味の効果があります。そしてそのALTER DATABASEような状況では、特定のオブジェクト名を指定する必要がなく、元のオブジェクトPERMISSION_SETが何であるかを知る必要もないので、メソッドはより単純に見えます。

また、アプリドメインが1つしかないALTER DATABASE場合は、データベースが既に設定されているTRUSTWORTHY ON場合や、適切な権限でキーベースログインを設定している場合でも、この方法はより簡単です。キーベースのログインを使用している場合は、上記のようにに設定TRUSTWORTHYしてONから、OFF再度設定できます。ただし、既ににTRUSTWORTHY設定している場合はON、それを逆にしてに設定しOFF、すぐにに戻しますON。

ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;
ALTER DATABASE CURRENT SET TRUSTWORTHY ON;

— ソロモン・ルツキー
ソース

更新されたアプローチは動作します STANDBY（READ_ONLY）データベースカタログに。SQL Serverでは、「信頼」設定を変更して、それを以前の状態に戻すことができました。の結果を確認して、変更が実際にドメインをアンロードしたことを確認しましたSELECT * FROM sys.dm_clr_appdomains;。甘い。

— グレンジャー