点评：巍然耸立的SQLServer2012

【51CTO 4月26日外电头条】正如大家一直以来对SQL Server新版本的殷切期望，SQL Server 2012也确实没有令我们空等，它所带来的海量新功能可以说光是名称就能占据几页稿纸。无论是商务智能用户渴望的Reporting Service还是令IT人士望眼欲穿的查询性能与正常运行时间，它几乎能够很好地为任何类型的用户服务。SQL Server 2012可以说是一款携威而来、全线升级的产品，除了少数几点令人失望的瑕疵外，我们很难对它横行非议。

Reporting Service中专为数据探测及虚拟化添加了一款名为Power View的网络前端。Analysis Service则引入了一套全新的语义模型，为商务智能专家在构建解决方案时提供更多灵活性。此外，列式存储索引机制的出现令查询性能更上一层楼；再加上新的Data Quality Service以及对原有Master Data Service的加强，SQL Server 2012无疑将在处理企业数据方面更加得心应手。

当然，SQL Server 2012中还包含了大量专为数据库管理员们准备的新功能，旨在帮助他们在管理工作中更加高效地处理问题。这些内容我在本点评文章中也会谈到，不过首先从大家最关心的、能够帮助系统可用性达到新水平的功能开始。

锦上添花的可用性

让咱们首先聊聊新版本中最大的进化内容之一——AlwaysOn。AlwaysOn是一种新的HA技术，它的出现将传统数据库镜像彻底扔进垃圾桶。由于镜像备份机制已然启动，因此镜像被局限在某台单一目标服务器上显然并不理想。另外，除非我们关闭自己的主数据库，否则这些镜像目标根本毫无用处，甚至连内容读取都无法实现。针对以上两点问题，AlwaysOn交出了令人满意的答卷。我们完全可以为自己的主数据库轻松配置多套只读副本，并在系统运行状态良好时将其作为报告机制使用。当然，与镜像备份类似，我们也可以对AlwaysOn进行设置，指示其与目标主数据库实时同步或者延时同步。

镜像可读性本身已经解决了备份机制中的一个老大难问题，但AlwaysOn最大的贡献还不仅限于此——它实现了多套相关数据库之间的故障切换。在通常情况下，两套或两套以上数据库的正常运行往往需要彼此之间的相互支持；也就是说只要其中某一套出了问题，仅凭镜像根本不足以支撑起全局业务。而AlwaysOn利用Availability Group（可用性群组）解决了数据库之间相互依赖的问题。该功能允许我们将那些必须同时失效的数据库指定为一个群组，这样一旦某套关键性数据库失效，相关数据库也将一并失效。通过这种方式，数据库的整体切换终于成为可能。

数据库的彼此依赖性是数据库管理员们最为头痛的另一大课题。当我们将数据库恢复到不同的运行环境中时，需要考虑到各种不同的情况，例如连入服务器、用户账户以及跨数据库规程与视图等等。这一切都必须通过同步与现有工作状态相匹配方能达到目的。而在SQL Server 2012中，我们发现了一项名为ContainedDB的功能，在它的帮助下我们能够将一套数据库转化为独立体系，也就是不与任何外部因素相关联。在这项功能启用时，我们无法向目标数据库写入任何将对其它数据库产生依赖性的内容，也不允许该数据库中包含任何将被外部系统所调用的对象。事实上，ContainedDB中的用户账户甚至根本没有服务器级别的登录选项，这样大家就不必担心自己在将数据库移动到新设备中时需要进行麻烦的账户信息同步了。当然，这还只是ContainedDB功能的首个版本，其中必然存在着一些问题与局限性；但它的意义非常重大，至少为我们带来了一个良好的开端。

另一大重大改进来自事件日志与追踪系统。SQL Profiler已经被正式舍弃，新的XEvents（即扩展事件）GUI取而代之。XEvents在最新版本中得到了极大扩展，新的追踪机制也将完全以它为核心运作。对于大多数用惯了老版本的用户来说，这次大刀阔斧的改动可能会带来些许不适，但我可以保证一旦上手，各位绝对会对新方案赞不绝口。XEvents比过去的SQL Trace更为灵活，也就是说如今追踪活动给设备带来的性能影响已经变得微乎其微。不仅追踪机制发生变革，重播功能也以Distributed Replay（分布式重播）之名改头换面。顾名思义，它让用户得以从多台设备重播那些受到追踪的工作负载，这样我们就能更好地模拟所在企业的日常生产活动。如果大家正打算进行更新测试或者考察自己的设备能否应对突如其来的数据爆发，那么这些功能的出现实在是既贴心又实用。

索引体系改进

索引体系迎来两大改进——在线重新索引与列式存储索引。相对于大多数企业针对数据库管理员们所做的管理简易化宣传，少数几项功能似乎一直并未受到多少重视，而在线重新索引正是其中最被忽视的项目之一。相信大家跟我一样，都曾为SQL Server 2005中的在线重新索引功能而感到兴奋不已；然而事实证明那套东西根本无法作用全部数据类型。在实际操作中，我们很快发现任何包含可变长字符、n长度可变长字符、可变二进制以及XML列数的索引都无法被在线重新索引功能接受。因此，我们不得不为自己的重新索引规范添加定制逻辑，以其使理解这两种不同类型的索引内容。现在，革命终于迎来新的进展，各种数据类型都可以为在线重新索引所支持，而我们也真正对全天候运行的应用程序提供在线索引维护。只要我们能够对在分区表进行在线重新索引处理，这项新功能也就真正服务于业务流程了。

SQL Server 2012还引入了一套新型索引机制，名为列式存储索引。传统的索引会将数据以行为单位进行存储，并将这些行添加到索引当中以完成索引任务。列式存储索引则是以列为单位存储数据，并将这些列添加到索引中以完成索引任务。根据微软公司的说法，这种新机制能够在相同情况下带来十倍于传统索引的性能表现。然而，这一次微软似乎有些过谦：根据我本人的实际体验，性能提升远远不止十倍。列式存储索引的出现主要是为了迎合大数据集仓储所带来的需求。但我相信大家可能不会在OLTP（即联机事务处理）方面使用这套新机制，因为列式存储具有只读属性。

除了显著的性能提升之外，SQL Server 2012还能够被安装在Windows Server内核之中。这不仅增加了服务器的全局处理能力，而且强化了安全性。在服务器内核中运行的服务项目相比较少，这意味着其中的安全漏洞也会相应减少，同时可能导致性能低下的软件bug也会得到有效扼制。

T-SQL强化

T-SQL倒没有太多新功能，但目前的这些已经足以应对业务需求。我个人最喜欢的是新的LAG与EOMonth窗口化功能。LAG为我们结果集中的每一行配备了访问前一行中列数据的接口，也就是说只要我们拥有给定列，就能随心所欲地显示同一行当中的当前值与过去值。说完了LAG，再来看看EOMonth。它的功能在于帮助我们直接访问每月最后一天发生的赋值变化。以上二者只是新功能中的一部分，其它的就请各位读者在使用中亲自发掘吧。

在所有T-SQL强化项目当中，FileTable可能算是最引人注目的功能了。从根本上说，它可以直接从文件系统中访问文件流数据。这里我需要解释一下，文件流允许我们将文档保存在文件系统当中，但这些文档必须与数据库同步备份，这样我们才能确保资料的安全性。FileTable则更进一步，将数据库与文件系统之间的交互关系透明化。首先，我们要将指定列表定义为FileTable，并为其分配一个文件系统中的目录。接下来，我们要做的是从Windows资源管理器中将要管理的文件拖动到该目录中。整个过程就是这么简单，如此一来我们不仅能够像以前那样在文件系统层面管理这些资料并保存到数据库中，也可以直接从T-SQL或者Windows系统层面对这些文件直接加以改动。

说了这么多优点，咱们再来谈谈SQL Server 2012中不尽人意的地方。就我个人而言，感到最失望的一点在于PowerShell在这个版本中所蒙受的冷落。比起AlwaysOn以及备份/恢复等功能所获得的大幅度强化，SQL Server 2012中的PowerShell似乎没有得到任何实质性提升。至少在当初微软无比倚重PowerShell的那些年，一个全新的版本中绝不会只为其配备这么一丁点改进。另一点让人失望之处在于几乎原封不动的SSMS（即SQL Server管理器）。微软已经把SSMS移植到Visual Studio 2010当中，但相对于这一改动的影响力（比起Team Foundation Server中对片段管理与整合效果的提升），数据库管理员几乎没能从中获得任何实质性的工作能力强化。其实在我看来，这方面的改进空间还是满大的，比如更好的多服务器管理及报告功能、将PowerShell与SSMS严密整合等都是不错的主意。可惜，一条也没实现。

在数据库升级方面，我一直抱持着所谓“满五原则”。也就是说，至少得有五大显著的功能提升才能让我们真正有兴趣对自己的数据库进行大规模升级。不过在这里我只要从某些方面对SQL Server 2012做出点评，还有很多方面是目前还不适合拿出来讨论的。SQL Server Integration Services得到大幅修整，SQL Server Analysis Services与SQL Server Reporting Services也有令人惊艳的强化，这一切倒已经足够令人满意了。相信在大家拿到正式版之后，一定不难从中找到说服自己升级到SQL Server 2012的五条理由。

原文链接：http://www.infoworld.com/d/microsoft-windows/review-sql-server-2012-stands-tall-191706?page=0,0