Database Reference
In-Depth Information
where
ct.type = 'E_TYPE_USER'
option (recompile)
The results shown in Figure
13-1
include information about currently running CLR tasks. The
forced_yield_
count
column indicates how many times scheduler forced CLR code to yield.
Figure 13-1.
Identifying the sessions with non-yielding CLR code
Security Considerations
SQL Server has CLR integration disabled by default. Although it would not prevent you from deploying the database
with assemblies and CLR objects, you would not be able to call CLR routines until CLR is enabled on the server level.
You can enable CLR with the code shown in Listing 13-2.
Listing 13-2.
Enabling CLR integration
sp_configure 'show advanced options', 1;
reconfigure;
go
sp_configure 'clr enabled', 1;
reconfigure;
go
sp_configure 'show advanced options', 0;
reconfigure;
go
The requirement to have CLR enabled on the server level can lead to roadblocks for independent software
vendors (ISV) who are trying to deploy their systems in Enterprise environments. Database and security
administrators in such environments often oppose such requirement when dealing with ISVs.
It is also worth mentioning that system CLR code is always enabled. You can use system CLR types, such as
HierarchyId
,
Geometry
, and
Geography
regardless of the configuration setting.
■
Note
We will talk about system CLr types in Chapter 14 of this topic, “CLr types.”
CLR objects that access the data, break the ownership chaining in a similar manner to dynamic SQL. That leads
to additional security management overhead in the system. Let's look at the example shown in Listing 13-3 and
Listing 13-4.
