开启SQL Server 2008 R2数据管理新纪元

运维 数据库运维 SQL Server 数据管理
本文将为大家介绍SQL Server 2008 R2数据管理方面的改进,包括SQL Server Utility等功能。

本文将为大家讲解SQL Server 2008 R2数据管理方面的改进,这些改进可以帮助DBA们提高效率,缩短工作时间。

尽管SQL Server 2008 R2仅仅是SQL Server 2008到下一版本间的过渡升级版本,不过对于SQL Server DBA来说SQL Server 2008 R2仍然有一些值得进行探索的数据管理特性。其中最为重要的特性莫过于SQL Server Utility 以及Data-Tier Application (简称DAC) 。

SQL Server Utility是SQL Server 2008 R2中用于多实例管理一项手段,而DAC则是SQL Server 2008 R2中数据管理的一个单元。

SQL Server Utility

下面我们简单介绍下SQL Server Utility。

SQL Server Utility主要解决的问题是当前企业数据环境中经常面临的一个困境——越来越多的服务器、越来越多的实例、越来越多的数据库以及越来越少的IT人员预算。许多调查都表明,当前企业中90%以上的数据库都小于2GB并且使用简单的单文件策略。不过为了满足日益灵活的业务模式,这样的小型数据库被不断被投入生产环境,同时为了隔离应用、不过的部门预算又使这些小数据库分布到了越来越多的实例以及服务器中。

尽管当前非常热门的虚拟化技术,例如微软的Hyper-V和Vmware的VSphere(原来称为ESX),尽管SQL Server 2008也提供了许多Central Management Server这样的概念来管理多实例,不过如何集中管理数据库本身以及如何集中管理这些数据库所依赖于的资源仍然是一项颇具挑战性的任务,而SQL Server Utility就是用于解决这一问题的。

SQL Server Utility是一项用于集中管理数据库所需资源的工具。SQL Server Utility为一个企业在使用SQL Server过程中所涉及的主要对象进行了统一建模,从而通过Utility Explorer为用户提供了一个用于观察SQL Server资源健康状况的窗口。通过SQL Server Utility用户可以在一个仪表盘中观察:

◆SQL Server实例的健康状况 (主要依据其资源消耗状况与资源利用策略的比较结果)

◆Data-Tier Application的健康状况 (稍后会有介绍)

◆数据文件

◆逻辑卷

◆CPU利用情况

◆存储资源利用情况

下图即是SQL Server Utility提供给DBA用户的管理仪表盘。从中DBA可以迅速了解被托管实例或者已注册DAC的健康状况

检查健康情况

SQL Server Utility的基础是Utility Control Point (简称UCP),UCP提供了一个用于存放所有被托管实例信息的存储中心,同时也提供了用于查询各被托管实例情况的访问中心。DBA将某个SQL Server实例注册到UCP中后,一组数据收集代码作业就会被注册到这个被托管实例上,这些作业每个15分钟运行一次,他们的主要任务是收集并上传被托管实例相关的信息,例如资源利用率、DAC配置等等。

SQL Server Utility通过UCP实现的目标不仅仅是收集信息,还有一项同样重要的任务就是提供一种称之为资源利用策略的对象,通过这种策略对象,SQL Server Utility将可以帮助用户判定某个实例、某个DAC是否健康。

DAC是否健康

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的测试版,赶紧亲身体验一下。

责任编辑:彭凡 来源: ITPUB
相关推荐

2009-11-12 10:12:21

主数据管理SQL Server

2010-10-26 09:57:44

Windows Pow

2010-02-26 16:36:46

SQL Server

2010-11-26 14:08:00

SQL Server

2010-12-27 09:48:36

2012-09-06 16:48:05

Windows Ser

2010-12-07 16:40:17

Windows Ser

2012-09-05 09:35:38

云计算微软IT平台

2012-07-10 09:50:55

SQL Server

2011-01-26 13:26:05

Windows Sto

2012-03-01 10:51:15

Windows Ser微软云管理

2010-12-20 15:59:59

SQL Server

2010-01-20 10:02:05

SQL Server

2010-05-07 09:13:26

SQL Server

2009-08-12 09:19:26

SQL Server

2010-04-22 09:17:03

SQL Server

2010-11-26 14:11:33

SQL Server

2012-02-20 22:50:48

Server 2008

2011-07-26 09:31:39

Windows Ser

2010-08-11 11:05:49

点赞
收藏

51CTO技术栈公众号