Is it a good-practice to enable SQL Server CLR integration in a server-cluster scenario? The policy at my organization disallows deploying CLR assemblies on their production servers; I was informed by the DBA’s this is because the CLR UDFs runs in-process and the databases are on a cluster.
I’m just curious if the policy is to simplify the DB admin (and perhaps ensure all code is open for review by DBA’s), or is there a technical reason to prohibit CLR integration in a server-cluster scenario? Thread safety?
Related questions:
- Threading in CLR in SQL Server 2008
- IN SQL Server is CLR Threadsafe
- Why doesn’t SQL Server come preinstalled with .net Framework for CLR Integration?
(By the way, my primary use-case is for string-manipulation UDFs, as described in this answer)
afaik there is no correlation between a clustered sql server instance and the CLR integration. SQL Server acts as a CLR host. When CLR functionality is used (e.g. calling a CLR UDF) the assembly is loaded from the database.
A passive cluster node does not have SQL Server service started so why should it bother? An active/active cluster will have two SQL Server instances running which are independent from each other. One is active on node one the other one on node two.
Well, with unsafe assembly code you can surely cause issues and bring down a sql server instance (and make it failover back and forth in a clustered environment). DBAs not necessarily have a clue of .net programming and probably want to avoid dealing with such problems. Otherwise I would see no solid reasoning behind this policy that would stand technical argumentation. Just be careful about what code you want to run on SQL Server. There is definitely a reason behind the security gates for CLR code (safe, external_access and unsafe).
Cheerio