Я хочу заставить AppDomain, используемый SQLCLR, быть сброшенным. Как я могу сделать это, кроме перезапуска экземпляра SQL Server?
Я хочу заставить AppDomain, используемый SQLCLR, быть сброшенным. Как я могу сделать это, кроме перезапуска экземпляра SQL Server?
Ответы:
Я знаю, что это немного жестоко, но как насчет отключения 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
ALTER ASSEMBLY
распространяемый через доставку журналов, который не перезагружал (или, по крайней мере, не выгружал) App Domain, был ошибкой. В любом случае, я нашел еще более простой метод, который я добавил к своему ответу здесь. Если бы у вас была возможность протестировать этот новый метод, это было бы здорово, мне было бы очень интересно посмотреть, работает ли он в описанном вами сценарии доставки журналов.
Существует более элегантное решение, которое не повлияет на все остальные сборки: просто измените PERMISSION_SET одной из сборок в домене приложения (домены приложения для каждого пользователя).
ALTER ASSEMBLY [AssemblyName] WITH PERMISSION_SET = {1 of the 2 levels that
this assembly is not current at}
Просто помните, что вам нужно будет установить PERMISSION_SET обратно к тому, что было. Кроме того, вам нужно получить доступ к методу в сборке, прежде чем изменение PERMISSION_SET будет выгружать его; изменение сборки, которая в данный момент не загружена в домен приложения, который активен, но с другой сборкой, не влияет на домен приложения (домены приложения для каждой БД, для пользователя, а не для каждой сборки).
ОБНОВЛЕНИЕ
Метод, описанный выше, является наиболее детальным подходом, когда он выгружает только один домен приложения. Но для этого требуется, чтобы сборка могла быть установлена на один из двух других уровней. Для сборок, отмеченных как SAFE
это будет возможно, только если
TRUSTWORTHY ON
илиEXTERNAL ACCESS ASSEMBLY
либо UNSAFE ASSEMBLY
разрешениеВ этом случае вы можете просто повернуть TRUSTWORTHY
настройку, ON
а затем сразу же OFF
снова вернуться, и это разгрузит все домены приложений в этой конкретной базе данных:
ALTER DATABASE CURRENT SET TRUSTWORTHY ON;
ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;
Если у вас есть только один домен приложений в базе данных в любом случае (и я подозреваю, что это имеет место в 95% или более случаев), тогда оба описанных здесь метода имеют одинаковый чистый эффект. И в этой ситуации ALTER DATABASE
метод кажется более простым, так как он не требует указания конкретного имени объекта и не требует знания оригинала PERMISSION_SET
.
ТАКЖЕ, если у вас есть только один домен приложения, то этот ALTER DATABASE
метод проще, даже если база данных уже установлена TRUSTWORTHY ON
или вы настроили регистрацию на основе ключей с соответствующим разрешением. Если вы используете логин на основе ключей , то вы можете установить , TRUSTWORTHY
чтобы ON
затем OFF
снова , как уже упоминалось выше. Но если вы уже TRUSTWORTHY
установили на ON
, то просто измените его и установите на, OFF
а затем немедленно вернитесь к ON
:
ALTER DATABASE CURRENT SET TRUSTWORTHY OFF;
ALTER DATABASE CURRENT SET TRUSTWORTHY ON;
SELECT * FROM sys.dm_clr_appdomains;
. Милая.