工作中遇到一個案例：備份還原過后或者對數據庫分離&附加后（移動數據庫文件），發現一些權限為EXTERNAL_ACCESS和UNSAFE程序集對應的CLR函數,在調用的時候會出現一些錯誤。下面特意用YourSQLDba備份還原到一個測試環境，然后調用CLR函數，就會遇到如下錯誤：
USE YourSQLDba;
GO
SELECT *
FROM [yUtl].[clr_GetFolderList]('C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\',
'*.mdf');
Msg 10314, Level 16, State 11, Line 19
在嘗試加載程序集 ID 65537 時 Microsoft .NET Framework 出錯。服務器可能資源不足，或者不信任該程序集。請重新運行查詢，或檢查有關的文檔了解如何解決程序集信任問題。有關此錯誤的詳細信息:
System.IO.FileLoadException: Could not load file or assembly 'yoursqldba_clrfileop, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An error relating to security occurred. (Exception from HRESULT: 0x8013150A)
System.IO.FileLoadException:
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
檢查發現assembly_id=65537的程序集為YourSqlDba_ClrFileOp
USE YourSQLDba;
GO
SELECT a.name
,a.principal_id
,a.assembly_id
,a.clr_name
,a.permission_set_desc
,a.is_visible
,a.create_date
,a.modify_date
FROM sys.assemblies AS a
出現這種錯誤，一般是EXTERNAL_ACCESS 和UNSAFE的程序集，錯誤出現的具體原因有兩種:
1: 數據庫Owner的SID變化了。無論你是備份還原還是分離附加操作，都要確保數據庫所有者SID在數據庫屬性中顯示的內容與源數據庫元數據中記錄的內容之間匹配。如果使用備份/還原，則數據庫所有者SID可能不匹配（取決於你操作時使用的賬號），這將阻止CLR代碼運行。
2: 數據庫的TRUSTWORTHY屬性值變化了。 數據庫屬性TRUSTWORTHY用於指明SQL Server實例是否信任該數據庫以及其中的內容。 默認情況下，此設置為 OFF，但是可以使用ALTER DATABASE語句將其設置為ON.
此屬性可用於減少附加數據庫所帶來的某些隱患，該數據庫包含下列對象之一：
· 帶有 EXTERNAL_ACCESS 或 UNSAFE 權限設置的有害程序集。 有關詳細信息，請參閱 CLR Integration Security。
· 所定義的、作為高特權用戶執行的有害模塊。 有關詳細信息，請參閱 EXECUTE AS 子句 (Transact-SQL)。
這兩種情況均要求具有特定程度的權限，並且在已附加到SQL Server實例的數據庫的上下文中使用這兩種情況時，應采取相應的機制保護這兩種情況。 但是，如果數據庫脫機，則對數據庫文件具有訪問權限的用戶可能會將其附加到其選擇的SQL Server實例，並將有害內容添加到數據庫中。 在SQL Server中分離和附加數據庫時，將對限制訪問數據庫文件的數據和日志文件設置某些權限。
因為不能立即信任附加到SQL Server實例的數據庫，所以不允許數據庫訪問超出數據庫范圍的資源，直到數據庫已顯式標記為可信。 因此，如果備份或分離TRUSTWORTHY選項設置為 ON 的數據庫並將該數據庫附加或還原到同一個或另一個 SQL Server 實例后，則附加/還原完成后 TRUSTWORTHY 屬性將設置為 OFF。 此外，旨在訪問數據庫以外資源的模塊和帶有 EXTERNAL_ACCESS 或 UNSAFE 權限設置的程序集還需要其他條件才能成功運行。
下面檢查數據庫的屬性TRUSTWORTHY（is_trustworth_on）， 如下所示
SELECT database_id ,
name ,
is_trustworthy_on
FROM sys.databases
WHERE name='YourSQLDba';
但是你對比源數據庫的屬性TRUSTWORTHY，就會發現數據庫還原后，TRUSTWORTHY屬性會變化（is_trustworth_on從1變為了0）.
設置YourSQLDba的屬性TRUSTWORTHY為ON
USE master;
GO
ALTER DATABASE YourSQLDba SET TRUSTWORTHY ON;
還原數據庫時，由於可能使用不同賬號，那么就會出現數據庫的owner出現變化的情況。當然，也有可能使用相同的賬號操作，不會出現db_owner變化的情況。下面這種情況，就是源數據庫的db_owner為sa，但是我使用域賬號做了還原操作。數據庫的db_owner變成了一個域賬號。
USE [YourSQLDba];
GO
EXEC sp_changedbowner 'sa';
GO
將數據庫的db_owner修改為sa,此時問題解決。當然也可以先修改db_owner，然后設置數據庫的trustworth屬性。分離附加數據庫也會導致TRUSTWORTHY屬性變化，還有可能導致數據庫db_owner變化（這個取決於你操作時使用的賬號），另外。這種錯誤只對權限為EXTERNAL_ACCESS 和UNSAFE的程序集出現，對於SAFE_ACCESS的程序集，不會出現這個問題。
參考資料：
https://support.microsoft.com/zh-cn/help/918040/you-may-receive-an-error-message-when-you-try-to-run-an-existing-clr-o
https://docs.microsoft.com/en-us/sql/relational-databases/security/trustworthy-database-property?view=sql-server-ver15