Yukon CLR 基本 架构
** 概述 **
随着 ** SQL Server ** ** ** “Yukon” Beta1 （也许也有人说： ** SQL ** ** Server ** 2 005 ）的推出 , 人们发现微软在 Yukon 中集成了非常多的新功能，其中最引人瞩目的是在数据库引擎中集成了对 Windows .NET Framework Common Language Runtime (CLR 公用语言运行环境 ) 的支持。在 2000 年 7 月的专业开发者大会（ PDC ）上，微软第一次向世界展示了这个新特征。
作为 ** SQL ** ** Server ** 2000 的开发人员，编写数据库的应用程序往往只局限于 T- ** SQL ** ，而宿主了 CLR 的 Yukon ，引入了许多强大的新特征，我们可以用 Visual Basic.NET, C# 等面向对象的语言完成以前 T- ** SQL ** 难于完成的任务。比如，以前我们如果要调用一些系统函数（ WIN32API 或 COM 组件），我们必须写扩展 存储过程 ，通过 ODS(Open Data Services) 开放式数据服务层和数据库引擎交互，而现在我们通过 CLR 提供的托管对象可以非常方便的调用 Windows .NET Framework Class Library (FCL).NET 框架类库。这些托管对象包括：
· 托管存储过程
· 托管函数
· 托管触发器
· 自定义复杂数据库类型
· 自定义复杂类型索引
· 自定义集合函数
首先 , 我们要了解数据库引擎集成 CLR 的优势和 CLR 可以提供的一些关键特征。
CLR 是一个托管的运行环境，所谓“托管”的意思是许 多任务 过去需要程序员负责的（比如内存管理）现在可以委托 CLR 来处理。作为托管代码的一部分， CLR 控制代码执行过程中的每一个部分，同时 CLR 是基于类型安全（ CLR 扮演了代码验证的角色）和安全许可的环境――彻底地编译为本地代码（ Native Code ）。 CLR 可以“辨识”出运行的代码是否企图直接处理内存或调用非 .NET 的代码。
.NET 的可执行代码在 CLR 中被装载为程序集（ _ assemblies _ ）的形式。程序集中包括中间语言代码（ IL 指令），描述代码的元数据（ Metadata ）和其它资源 ( 比如：引用其它文件列表 ) ，源代码并不是直接保存在程序集中，而是编译为一种 CLR 可以读懂的中间语言（ IL ） , 在程序执行之前 CLR 通过即时编译（ JIT ）将代码转换为本地代码（通常是 X86 代码）。如果代码在本地运行，这个本地代码会被加载到一段拥有生命周期的缓存，这就是说 .NET 的代码是非解释型的――它在运行时最终会被编译成本地代码。
CLR 拥有自己管理内存的方式：如果一个对象或一组对象没有被其它运行的代码引用，从理论上说要回收所有不在使用的内存，但是对于 CLR ，内存只是在运行资源不足时才会被回收， CLR 在需要额外的内存资源时才调用垃圾 收集 器，这种内存管理机制使程序员不用担心内存泄漏。
所有的代码都运行在自己的应用程序域（ _ Application Domain _ ）。在 CLR 环境中，应用程序域的作用是在单个进程中宿主不同的应用程序域，用来隔离不同的执行代码 ―― 换句话说，在一个应用程序域中的运行失常的代码不会影响其它应用程序域中运行的代码。 每个进程中都存在至少一个拥有 CLR 的应用程序域， 当然， 也可以有多个――这是由寄宿进程和运行的托管代码决定的。当一个程序集被 CLR 加载时，是指被加载（即时编译（ JIT ））到一个指定的应用程序域中，同时这个程序集也可以被加载到同一个进程中不同的应用程序域中。也可以加载一个中立的程序集――在这种情况下，一个程序集的单独备份可以为一个进程中所有的用户提供服务。
** 寄宿 ** ** **
宿主 了 CLR 的 Yukon 数据库引擎有一些特殊需求。数据库引擎对于资源管理是非常谨慎的――比如：通过 直观推断数据库使用的资源变化， 在不同的缓存之间移动内存。因此， 应该在数据库引擎和 CLR 的资源管理方式保持某种默契关系。
在 CLR 的 1.0 和 1.1 的版本中， CLR 提供一个 API 来加强进程的控制――比如判断 CLR 线程 池的大小。当然，这个 API 并非强大到可以替代 CLR 在 Yukon 中的作用， 比如：考虑以下几种情况：
** 内存管理 ** ** **
Yukon 数据库引擎完全控制已经被分配的内存空间，在不同的缓存之间切换，比如：存储过程缓存和数据缓存。在这种情况下， Yukon 数据库引擎需要有更加灵活的方法来运行 CLR 的垃圾收集器，同时对 CLR 垃圾收集器发生的条件，分配或释放多少内存产生影响。
** 线程管理 ** ** **
CLR 通过线程技术完成异步任务和多元化的并发操作。 CLR 拥有自己的托管线程池，用来计划执行线程池中的任务。然而， ** SQL ** ** Server ** 使用更精致的纤程机制（ mechanism of fibres ）来应对可能的巨量并发请求，因此， ** SQL ** ** Server ** 需要接管 CLR 的线程管理。
并且，由于存在 CLR 的运行机制和 ** SQL ** ** Server ** 的需要之间的微妙关系，我们意识到这需要对 CLR 的寄宿接口进行扩展。因此随着 Whidbey （是微软 Visual Studio .NET 的下一代版本）的发布 .NET 会提供更多和更强大的寄宿 API （ Yukon 发布的 .NET 版本和 Yukon 支持的 .NET 版本将保持一致）
Whidbey 寄宿 API 的特征
在 Whidbey 中，有 7 处寄宿 API 的关键部分得到了扩展：
1. 内存管理
现在 CLR 允许宿主机（ Yukon ）取代 WINDOWS 和 C 运行库分配常规内存，因此现在宿主机可以控制和判断 ** 内存的分配 ** 或释放多少。同时，宿主机可以用自己的内存通知机制取代标准的内存通知机制，从而可以触发垃圾收集器。宿主机也可以不进行内存分配，这时 CLR <SPAN style="FONT-SIZE: 10pt; COLOR: #2d3741; mso-asci