CLR(公用语言运行时)和Java虚拟机一样也是一个运行时环境，它负责资源管理（内存分配和垃圾收集），并保证应用和底层操作系统之间必要的分离。.NET提供了一个运行时环境，叫做公用语言运行时（Commen Language Runtime），是一种多语言执行环境，支持众多的数据类型和语言特性。他管理着代码的执行，并使开发过程变得更加简单。这是一种可操控的执行环境，其功能通过编译器与其他工具共同展现。
依靠一种以运行时为目标的编译器开发的代码叫做可操控代码managed code。与之相对的是unmanaged code。
元数据metadata：为了使运行时环境可以向可操控代码提供服务，语言编译器需要产生一种元数据，它将提供在使用语言中的类型、成员、引用的信息。运行时环境使用元数据定位并载入类，在内存中展开对象实例，解决方法调用，产生本地代码，强制执行安全性，并建立运行时环境的边界。
可操控执行的含义：对象在执行的过程中完全被运行时环境所控制。运行时环境提供以下服务:自动内存管理、调试支持、增强的安全性及与非可操控性代码的互操作性。条件：1、选择以运行时为目标的语言编译器，如VB、C#；2、在组件的输出类型中使用CLR要求的语言特性。
为了提高平台的可靠性，以及为了达到面向事务的电子商务应用所要求的稳定性级别，CLR还要负责其他一些任务，比如监视程序的运行。按照.NET的说法，在CLR监视之下运行的程序属于“受管理的”（managed）代码，而不在CLR之下、直接在裸机上运行的应用或者组件属于“非受管理的”（unmanaged）的代码。
CLR将监视形形色色的常见编程错误，许多年来这些错误一直是软件故障的主要根源，其中包括：访问数组元素越界，访问未分配的内存空间，由于数据体积过大而导致的内存溢出，等等。
然而，这种对受管理代码的运行监视是有代价的。虽然当前还不可能精确地得到监视程序运行所需要的开销，但从当前Beta测试版的性能表现来看，正如Microsoft所承认的那样，我们可以预料由它导致的性能降低程度至少达到10%。当然，如果监视程序运行能够将稳定性和可用性提高到一个新的档次，我们可以怀疑10%的性能降低是否还可以称为一件坏事……
以上转自：
http://www.kmcenter.org/blog/user1/191/archives/2004/386.html
http://i-t.org.cn/html/biancheng/200703/2011.html
为什么微软要集成clr 到sql server？
在我看来，clr 存储过程是非常好的东西，它弥补了t-sql 做为一门查询语言的不足，使得数据库在处理逻辑问题的时候不像以前那么蹩脚，许多DB程序员为了用 t-sql实现一个简单的过程逻辑而大伤脑筋，比如一个非常间的需求，我想传递一个数组，里面装有id,想更新这些id的行的状态，就是在传递一个数组到存储过程中并分割成若干个id,一个在C#中非常简单的实现却要为t-sql绞尽脑汁。。。。相信大多数程序员都有我类似的苦恼。而在最近的项目中，涉及到由联通过来的短信数据处理，预处理短信表是由另外一个模块插入的，我负责的模块需要对这个预处理短信表的记录读取出来，定时扫描整个表，如果有需要处理的短信，那么要由windows服务定时读取出来，并且根据短信种类的不同做业务逻辑的分发，整个模块的性能要求非常高，所有的上行短信都要经过这个表，并处理。每秒发生的开连接插入删除造作非常多。最开始的设计是使用windows服务定时扫表并更新回数据库，一条一条的更新回数据库。。。。其性能之差是难以想象的。所以准备采取clr存储过程结合job，把业务逻辑的分发也拿到数据库clr环境下做，节省往返开销和连接开销。
总之，t-sql 是一门面向查询的语言，以数据为主，但是对过程的处理支持却非常差劲,clr 集成就能非常好的弥补了这点。之所以写个开篇，是看到有些人还是对这种技术的应用环境的不了解。好了，接下来，我准备写一些关于clr 集成的 sql server 2005 下的应用，包括clr proc clr function 等。欢迎大家指正！
附上使用context connection 和使用一般数据库连接的对比图，大家可以参考一下。
以上转自：
http://www.cnblogs.com/FrameWork/archive/2007/03/16/673762.html
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1655408