Question

We have database that relies on a CLR assembly. The assembly references other assemblies. After a Windows Framework update we need to drop and reinstall the assembly to have it work.

Now the issue is that the database is part of a failover cluster. Yesterday the secondary server was updated and with it came a framework update. The assembly no longer works on the secondary, but we cannot reinstall it because it is a read only.

The primary server hasn't been updated, so no point in reinstalling the assembly.

Does anybody has experience in dealing with these sort of issues? If so is there a recommended way of updating assemblies?

We could do a failover and update the assembly. However in this case the assembly doesn't match the Framework on the other server. I guess we need to do a failover, reinstall the assembly and update the other server to the same Framework?

Thanks!

Was it helpful?

Solution

Are you saying that the one assembly you have references unsupported .NET framework libraries that get imported implicitly when creating your assembly? In which case it would make sense that a Framework update could have this effect. SQLCLR requires that assemblies used in SQL Server that are also in the main OS GAC be the exact same version, and the version in the main GAC is now newer on the secondary due to the Framework update.

As far as I can tell, you will need to apply the same Framework update to the primary, reload the custom assembly, and failover, and then reload the assembly again. Even if the secondary was not read-only and you were able to update the assembly, if that instance failed over to the main node (assuming it still has not received the Framework update), then the SQLCLR object(s) would again fail due to the library version mismatch. And, even right now, if the primary instance fails over to the other node, the SQLCLR object(s) will error due to the library version mismatch.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top