Data-Tier Application

　　另外一个DBA越来越多在SQL Server 2008 R2介绍中看到的词就是DAC，它的全称其实是Data-Tier Application Component。

　　Data-Tier Application其实是一个包含了几乎某一应用所需要的数据库及实例对象的实体，例如表、视图、存储过程、登录等等。请注意“实体”这个概念。有了实体这个概念，也就意味着这些原本独立的对象现在可以被视为一个更大的对象，因此可以被开发人员打包部署、管理员整体维护，配合上面我们介绍的SQL Server Utility我们甚至可以将那些原本独立的对象视为一个应用进行统一的监控和管理，更为关键的是在升级过程中如果有这个整体对象的概念，升级过程中所涉及的版本控制问题也会变得更为简单。

　　看一下当前我们的工作流程。如果开发人员发布了一个新的应用，首先开发人员会准备一堆的脚本、代码、应用，然后一一部署到某个测试实例上，然后通知用户在这个测试实例上进行功能、业务、UAT一系列的测试。当测试结束后，DBA就需要收集这些脚本、代码以及应用，并将它们部署到生产实例上。噢，首先当然DBA还要确定哪个生产实例更加适合部署这个新的应用。这还不是最具挑战性的，正如前面所说，如果这个应用是一个升级版本……，天哪，DBA和开发人员可能还要坐下来讨论一下详细的升级过程，哪些对象需要更新?怎么更新这些对象?更新过程中怎么保证数据不受影响?

　　如果使用Data-Tier Application呢?开发人员只需要在Visual Studio 2010中通过一种被称为Data-tier Application的项目模板创建一个新项目，而后在其中定义前面提到那些对象——脚本、代码、应用等等，而后将这个项目打包成一个DAC的包 (dacpac文件) ，然后将其发布到测试服务器。注意不再是一个一个安装、运行，而是通过SSMS中的Data Tier Application管理节点直接加在这个包文件，这样就可以直接将所有相关对象注册到当前数据库引擎实例上。

　　在升级场景中Data-Tier Application的优势就更为明显了。原本开发人员需要为一个新版本准备N套脚本，一套是全新安装，而剩下是从某个特定版本升级到当前需要发布的版本。如果使用的是Data-Tier Application，开发人员只需要为新的版本编译出新的包文件，在数据库引擎部署这个新版本DAC包的时候，部署人员只需要定位到现存的DAC然后选择升级功能，升级向导会自动比对数据库引擎中已经部署的版本和准备部署的版本差异，然后自动确定需要执行的操作。

　　在一个DAC项目中，开发人员可以定义：

　　• DAC的自身属性，例如应用名称、版本等等

　　• 所有数据库级别的对象，例如表、视图、存储过程

　　• 所有数据库引擎实例级别的对象，例如登录

　　• 部署服务器需求策略，例如所需SQL Server实例版本号、操作系统版本号、硬件架构等等

　　• 其他辅助文档，例如数据生成计划、部署前准备脚本及部署后清理脚本等等

　　总结语

　　SQL Server Utility提供了一个多实例管理的新思路，而Data-Tier Application则提供了一个数据库管理的新方法。结合这两项技术，SQL Server 2008 R2毫无疑问会对DBA的工作产生深远的影响，另外一个毫无疑问的结论是，对于当前越来越庞大的基础架构规模和应用规模，这两项技术所产生的影响一定是正面积极的。

　　了解了这么多，最好的办法是什么呢?当然是下载一个SQL Server 2008 R2的测试版，赶紧亲身体验一下。