SQL Server version: 2005
.NET version: 3.5
I’m trying to work with a CLR UDF using the most efficient methods in regards to memory and performance. So it seems that SQL Server comes with pre-loaded .NET assemblies from the GAC. However, SQL server prohibits you from loading custom assemblies from the GAC to your SQL database. Trying to find an alternative approach to this, I experimented with SQL CLR by loading assemblies on a per database basis and ran SQL queries utilizing my CLR UDF to find that each database is assigned its own appdomain. In addition, each appdomain loads a copy of the assemblies (my main assembly with its dependencies). Makes sense.
OK, I then experimented with creating the assemblies into a single database and then referencing the CLR UDF via dbname.dbo.clrudfname in other databases to find something interesting. The only appdomain that loaded belongs to the database that hosts the assemblies. In addition, the only assemblies loaded are those that are hosted in that appdomain. In addition, performance was pretty much the same referencing another database’s assembly opposed to the database hosting its own copy.
Does anyone see an issue with this approach in managing CLR memory more efficiently?
There’s no reason to have duplicate assemblies on the same database server. That’s just extra copies to maintain.
Create one database, called Utilities (or CLRs or whatever) and put the CLRs there. Then you can reference them with a 3 part name (db.schema.object) from any database on the server.
Since you’re using CLRs, I’d recommend you review David Wiseman’s IO Utility solution here: http://www.wisesoft.co.uk/articles/sql_server_clr_io_utility.aspx
It’s perfect for integrating the file system with T-SQL. It’s also great for beginners learning how to build CLRs.