新功能

1、内存技术改进

SQL Server 2014中最吸引人关注的特性就是内存在线事务处理(OLTP)引擎，项目代号为“Hekaton”。内存OLTP整合到SQL Server的核心数据库管理组件中，它不需要特殊的硬件或软件，就能够无缝整合现有的事务过程。一旦将表声明为内存最优化，那么内存OLTP引擎就将在内存中管理表和保存数据。当它们需要其他表数据时，它们就可以使用查询访问数据。事实上，一个查询会同时引用内存优化表和常规表。

SQL Server 2014增强内存相关功能的另一个方面是允许将SQL Server内存缓冲池扩展到固态硬盘(SSD)或SSD阵列上。扩展缓冲池能够实现更快的分页速度，但是又降低了数据风险，因为只有整理过的页才会存储在SSD上。这一点对于支持繁重读负载的OLTP操作特别有好处。LSI Nytro闪存卡与最新SQL Server 2014协同工作，降低延迟、提高吞吐量和可靠性，消除IO瓶颈。

在SQL Server 2014中，列存储索引功能也得到更新。列存储索引最初是在SQL Server 2012引入的，目的是支持高度聚合数据仓库查询。基于xVelocity存储技术，这些索引以列的格式存储数据，同时又利用xVelocity的内存管理功能和高级压缩算法。然而，SQL Server 2012的列存储索引不能使用集群，也不能更新。

SQL Server 2014引入了另一种列存储索引，它既支持集群也支持更新。此外，它还支持更高效的数据压缩，允许将更多的数据保存到内存中，以减少昂贵的I/O操作。

2、云整合

微软一直将SQL Server 2014定位为混合云平台，这意味着SQL Server数据库更容易整合Windows Azure。例如，从SQL Server 2012 Cumulative Update 2开始，您就能够将数据库备份到Windows Azure BLOB存储服务上。SQL Server 2014引入了智能备份(Smart Backups)概念，其中SQL Server将自动决定要执行完全备份还是差异备份，以及何时执行备份。SQL Server 2014还允许将本地数据库的数据和日志文件存储到Azure存储上。此外，SQL Server Management Studio提供了一个部署向导，它可以帮助您轻松地将现有本地数据库迁移到Azure虚拟机上。

SQL Server 2014还增加了一个功能，允许将Azure虚拟机作为一个Always On可用性组副本。可用性组(Availability Groups)特性最初在SQL Server 2012引入，提供了支持高可用性数据库的故障恢复服务。它由1个主副本和1~4个次副本(SQL Server 2014增加到8个)构成。主副本可以运行一个或多个数据库;次副本则包含多个数据库副本。Windows Azure基础架构服务支持在运行SQL Server的Azure虚拟机中使用可用性组。这意味着您用一个虚拟机作为次副本，然后支持自动故障恢复。

愿景

Microsoft SQL Server的愿景

许多因素致使产生了信息存储爆炸。有了新的信息类型，例如图片和视频的数字化，和从RFID标签获得的传感器信息，公司的数字信息的数量在急剧增长。遵守规范和全球化的发展要求信息存储的安全性和在任何时候都可用。同时，磁盘存储的成本显著地降低了，使得公司投资的每一美元可以存储更多的数据。用户必须快速的在大量的数据中找到相关的信息。此外，他们想在任何设备上使用这个信息，并且计划每天使用，例如Microsoft Office系统应用程序。对数据爆炸和用户期望值的增加的管理为公司制造了许多挑战。

Microsoft® 数据平台愿景提供了一个解决方案来满足这些需求，这个解决方案就是公司可以使用存储和管理许多数据类型，包括XML(标准通用标记语言的子集)、电子邮件、时间/日历、文件、文档、地理等等，同时提供一个丰富的服务集合来与数据交互作用：搜索、查询、数据分析、报表、数据整合，和强大的同步功能。用户可以访问从创建到存档于任何设备的信息，从桌面到移动设备的信息

语音

Microsoft按照客户/服务器体系结构的分布进行操作。这种方法产生不必要的代价和复杂性。在Internet中，Oracle已经发现了一个较好的答案。在Internet Computing的多层(multi-tiered)体系结构中，集中(centralization)可以简化应用的部署和维护，数据的管理和备份，并向客户提供了高级的性能、安全性与可靠性，结果使总的操作成本更低。Oracle具有使所有数据和文档存储在少数几个高性能数据库的能力，这种能力使客户可以集中管理他们所有的数据，并且信息管理和访问更加容易、可靠且价格更加便宜。

开放

SQL Server只在Windows上运行，MicroSoft这种专有策略的目标是将客户锁定到Windows环境中，限制客户通过选择一个开放的基于标准的解决方案来获取革新和价格竞争带来的好处。此外，人们也都知道，Windows平台本身的可靠性、安全性和可伸缩性也是有限的。Oracle能在所有主要的平台(其中包括Windows)上运行，并且完全支持所有的工业标准，所以，客户可以利用很多种第三方应用程序、工具、网关和管理实用程序。Oracle采用开放策略，它使得客户可以选择一种最适合他们特定需要的解决方案。利用Oracle8i，操作系统实质上将变得无关紧要。Oracle8i的Internet文件系统(iFS)是一种突破，这种突破性给所有数据类型提供了一种易于使用的数据管理接口，这样减少了客户对Windows之类的专用操作系统。

可伸缩性

由于SQLServer7.0的并行实施和共存模型并不成熟，这使得人们更加关心该产品处理日益增多的用户数和数据卷mes)的能力。Oracle在下列两个方面提供了一个优越的可伸　簇：Oracle并行服务器通过使一组节点共享同一簇中的工作负载来扩展Windows NT的能力，Oracle提供具有高可用性和高伸缩性的簇解决方案，而Microsoft只提供克服错误的簇。根据Gartner Group的一份报告(10/97)，Microsoft在2001年以前将不会有一个可伸缩的簇解决方案。Oracle自从1997年以来就已经有这种能力。伸缩到其他操作系统：因为Oracle是一个开放的解决方案，客户可以从他们的系统移到Unix或另一个操作系统，当Windows NT不能满足他们的需要。SQL Server与单个平台的结合意味着，当一个客户达到Windows NT的限制时，除了放弃他们的系统并移到一个新平台上的一个新数据库以外??一个最能节省时间和金钱的建议，他们再也没有其他选择。

安全性

由于Internet的出现而带来的全球数据访问也同时增加了潜在的安全危险。对于数据库的安全要求决不会比以前更高，而SQL Server7.0还没有获得任何类型的安全证书。相比之下，Oracle是唯一获得最高认证级别的ISO标准认证的数据库。Oracle高级的安全特性考虑了强制实施的细小权限，先进的审查，增强的访问控制，安全的分布是处理与复制，以及使用附加的外部签发机制的能力。SQL Server7.0没有这些特性。

可扩展性

今天的Internet是一个令人激动的新世界，它具有鲜明的图像，实时的视频点播，高保真的语音和声音，以及诸如金融数据趋势和地理编码之类的复杂信息。通过集中管理文本、图像、音频、视频和地理信息，Oracle8i的interMedia使客户能够利用Web的多媒体特性。相比之下，Microsoft SQL Server 7.0对非传统的数据类型缺乏内置的支持。作为一种替代的策略，Microsoft提倡将非传统的数据存储到单独的服务器里的平面(flat)文件中，然后使用OLE-DB将它们链接在一起。使用这种策略，集成在Web中发现的各种数据类型，将会产生复杂的、不安全的、维护量大的数据包(mess)，这种数据包缺乏事物的完整性。

性能

低性能可能是很致命的(fatal)，因为雇员的生产能力被阻碍，客户由于过多的等待时间而丢失。根据事物处理委员会(TPC)审查的标准与结果，Oracle提供了比SQL Server7.0更高级的性能。到1998年11月为止，Oracle一直是Windows NT中TPC-D和TPC-C标准的世界记录保持者。实际上，Oracle的NT TPC-C结果几乎比Microsoft的快两倍。Microsoft 从来没有宣布一个TPC-D结果，这就意味着尽管SQL Server7.0中有假定的环境，但它仍然不适合于数据仓库应用。Oracle也保持了SAP,Baan和Peoplesoft标准的世界记录。通过一贯地演示正式标准与实际情况之间的性能关系，acle已被证明，它可以处理最紧迫的数据仓库和OLTP应用的工作负。

操作简单

使数据库易于安装、使用和管理??组合在一起称为“操作简单“??是一个减少成本的关键因素。尽管Microsoft产品具有易于使用的美誉，但SQL Server7.0缺乏数据库管理的特性，而这种特性是复杂的数据库系统所必须的。例如，对于SQL Server6.5和SQL Server7.0.Microsoft需要使用单独的管理工具。为了易于安装，Oracle使用了一个基于Java的实用程序，该实用程序提供了安装和运行一个预调整和预配置的Oracle8i数据库所需要的一切内容。“操作简单“的最重要部分是易管理性，Oracle Enterprise Manager(企业管理器)提供一个集成的管理控制台来集中管理多个服务器。客户也可以单独购买所有三个或其中任何一个可选的管理包，这些管理包提供了高级的功能来调整和诊断数据库，管理数据库环PC Week已经说过，“SQL Server7.0并没有向客户提供其竞争对手尚未提供的任何新东西。”根据Information Week(9/14/98)，“即使在经济的市场中：Windows NT环境，SQLServer7仍然不是OLTP数据库竞争者的对手。”在SQL Server7.0中，许多关键任务数据库应用所必需的功能(高可用性/可伸缩性、安全、性能等)仍然没有。Microsoft正在努力地追赶Oracle又一个技术领先的传统，新发布的Oracle8i也不例外。通过诸如iFS、数据库Java、WebDB、interMedia和WebToGo之类的革新，Oracle带头使各个公司获得Internet计算的好处。特别在Windows NT中，由于Oracle是第一个发布NT数据库簇解决方案的厂商，第一次支持超过大内存(VLM)，第一次将高可用性和可伸缩性带到安装有Oacle并行服务器的NT中。

技术风险

SQL Server7.0是一个完全重写的产品版本。该产品经历了联系的延迟，并且具有非常长的beta测试周期，这通常代表开发问题。一份Gartner报告(8/98)说，“引擎的重新设计时非常深的...我们建议在1999年中期以前，不要将该产品部署在规模比较大的产品应用中。”正如一份Giga报告(3/98)所说的那样，“SQL Server仍有许多需要证明。可伸缩性、可靠性、多用户的性能、簇的开发、对象特性的支持等都有问题。”一个特别危险的因素是重新加在数据库问题。由于基本的数据结构发生变化，Microsoft将要求所有SQL Server6.0和6.5站点必须先卸载然后重新加载数据，这个过程需要好几天的时间。Microsoft已经承认6.5和7.0之间存在后向兼容问题。利用SQL Server7.0.许多以前存在的基本的6.5代码将必须重写，以便利用象行级锁定和分布联合之类的新特性。公司在使它们的生产率和信息冒风险时必须非常谨慎。利用Oracle没有任何风险。Oracle8已经发布一年多了，并被部署在成百上千个用户站

点上。在500家财团公司中，将近90%的公司使用Oracle产品和服务器。如此广泛的支持是人们对Oracle信任的结果，这种信任来自于Oracle是一个安全和合理的选择。客户将询问自己，在已经有可靠的、先进的Oracle8数据库时，为什们还要冒险使用新的未被证明的SQL。

厂商风险

Microsoft的核心能力是在桌面和操作系统软件的开发，该公司在企业级数据管理没什么经验。从技术和业务来看，Microsoft进入数据管理领域，到目前为止还没有获得信任。Microsoft的成功是由于依靠客户软件的连续废弃与升级，以及硬件和操作系统尽可能的传播。在企业范围内若要获得成功，则要求高效利用已有的数据资源，并合并服务器资源。在另一个方面，Oracle已有二十多年的向客户解决方案的经验。一个公司的数据是它们最有价值的资产，Microsoft不能指望涌进这个市场，然后一夜之间获得信任。Oracle已经花费了几年的艰苦努力才赢得其客户群的信任以及它享受到的荣誉。每天成千上万的客户在Oracle上运行它们的业务所获得的成功就是Oracle技术和业务模型完美的有利证明。

性能参数

语音

当您怀疑计算机硬件是影响SQL Server运行性能的主要原因时，可以通过SQL Server Performance Monitor监视相应硬件的负载，以便证实您的猜测并找出系统瓶颈。

Memory: Page Faults / sec如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。

Process: Working Set SQL Server的该参数应该非常接近分配给SQL Server的内存值。在SQL Server设定中，如果将"set working set size"置为0.则Windows NT会决定SQL Server的工作集的大小。如果将"set working set size"置为1.则强制工作集大小为SQLServer的分配内存大小。一般情况下，最好不要改变"set working set size"的缺省值。

一单位的统计服务器投入使用后，运行速度较慢，经排查原因，发现SQLServer中的内存选项(Memory)仅为安装缺省值16MB(而服务器有128MB的物理内存)，在将内存值调整为100MB时却误将其改成了1000MB，使得SQL Server服务不能启动，统计数据库打不开，也就不能再次进入SQL Enterprise Manager修改内存设置了。由于未备份业务数据，不到万不得已不能重装SQLServer数据库，就试图用命令行参数命令来重新启动SQL Server服务，但均不能奏，陷入了困境。我们经过仔细分析提出：既然SQL Server可用内存设置值远远大于物理内存，造成SQLServer服务不能启动，何不扩充虚拟内存呢?经设法将机器虚拟内存扩充至1000MB并重新启动，SQL Server数据库成功启动，问题迎刃而解。

机制结构

SQL Server 是一种客户机/服务器系统

多年来，SQL Server 一直被认为是一种客户机/服务器系统。事实上，Sybase DataServer(以此为基础开发了原始的 SQL Server)正是第一个作为客户机/服务器系统开发的商用关系数据库系统。那这又说明了什么呢?这不只意味着 SQL Server 是一个双层系统。从传统上看，双层系统意味着客户机应用程序运行在一台机器上，向另一台计算机上的服务器发送请求。而对于 SQL Server，客户机/服务器意味着 SQL Server 的组成部分，即客户机 API 部分，驻留在处理结构中的远端，与服务器组件本身是分开的。

在典型的双层模型中，客户机程序部分驻留在台式机上，具有大量客户机应用程序逻辑和业务逻辑，并且会直接向数据库系统发出请求。然后，客户机得到服务器响应这些请求所返回的数据。

三层系统也采用了同样的模型。多年以来，SQL Server 一直用在事务处理监视系统中，例如 BEA 的 Tuxedo 以及 Compaq 的 ACMSxp，这些系统早在二、三十年前就采用了典型的三层模型。三层模型在今天基于 Web 的应用系统中占据了支配地位，这类系统以 Microsoft 的 MTS 以及新的 COM+ 1.0 为代表。从 SQL Server 的角度看，三层解决方案中的客户机程序是放在中间层的。中间层直接与数据库交互。实际的桌面，或瘦客户机(Thin Client)，使用其他机制并通常直接与中间层交互，而不是直接与数据库系统交互。

结构

从结构的角度看，SQL Server 关系服务器组件本身并不真正关心客户机程序运行的位置。事实上，就 SQL Server 而言，即使在运行 SQL Server 的同一台机器上运行应用程序，仍然还是客户机/服务器模型。服务器运行一个单独的多线程进程，为来自客户机的请求提供服务，不管客户机的位置在哪里。客户机程序代码本身是单独的运行在客户机应用程序内部的 DLL，与 SQL Server 的实际接口是在客户机和服务器之间对话的“表格数据流”(Tabular Data Stream,TDS) 协议。一个常见的问题是“什么是 SQL Server 的本机接口呢?”很长时间以来，很多开发人员一直都不愿意使用 ODBC 这样的接口，因为他们认为由 Sybase 开发的客户机 API，也就是 DB-Library，是 SQL Server 的本机接口。实际上，SQL Server 关系服务器本身并没有本机 API，它的接口就是在客户机和服务器之间的通信流协议 TDS。TDS 把客户机发送给服务器的 SQL 语句封装起来，也把服务器返回给客户机的处理结果封装起来。任何直接处理 TDS 的 API 都是 SQL Server 的本机接口。

让我们来看一下客户机的组件，客户机结构中的某些部分就不在这里讨论了，因为它们不属于 SQL Server 的范畴。但如果您在编写应用程序的话，就必须了解这些部分。大家知道得最多的应该是各种对象模型，如果您正在编写 ASP 或 Microsoft Visual Basic(R)应用程序，就需要通过 ADO 与数据库系统交互，而不是直接调用底层的 API，例如 ODBC 或 OLE-DB。ADO 映射到 OLE-DB，而 RDO 映射到 ODBC。因此，作为这种最常用的编程模型的对象模型，并不是 SQL Server 客户机结构中的严格意义上的组件。此外，还有另外一些组件可以插接到 SQL Server 基础结构上面的这一层。OLE-DB 的“会话池服务提供程序 (Session Pooling Service Provider)”就是这种组件的一个例子。

接口

SQL Server 有两个接口可以认为是 SQL Server 7.0 的本机接口，即 OLE-DB 和 ODBC。DB-Library 接口也是本机的，它与 TDS 通信，但是 DB-Library 使用的是 TDS 较老的版本，需要在服务器上进行一些转换。现有的 DB-Library应用程序仍然可以继续与 SQL Server 7.0 协同使用，但是很多新的功能和性能提高等好处只能通过 ODBC 和 OLE DB 才能利用。更新 DB-Library 使其支持 SQL Server 7.0 的新能力，将会导致与现有应用程序的很多不兼容性，因此需要修改应用程序。ODBC 在五年之前就替代了 DB-Library，是新的 SQL Server应用程序更理想的 API，因此引入不兼容的 DB-Library 新版本并不明智。从图 2 可以看到，所有这些客户机 API 都有三个部分。最上面的部分实现 API 的细节，例如行集和游标应该是什么样等等。TDS 格式化程序负责处理实际请求，例如 SQL 语句，并将其封装成 TDS 消息包，发送给 SQL Server，获得返回的结果，然后再把结果反馈到接口实现。

还有一些供所有提供程序使用的公共库代码。例如，BCP 设备就是 ODBC 和 OLE-DB 都可以调用的库。DTC 也是这样。第三个例子是 ODBC 规范的 SQL 语法，即带有参数标记的 CALL 语法，这些对于所有提供程序都是通用的。

除了我们在前面已经提到的局限性，即 DB-Library 仍然只能使用 SQL Server 6.5 版，TDS 协议对于所有 API 都是相同的。ODBC 和 OLE-DB 在与 SQL Server 7.0 通信时使用 SQL Server 7.0 版，但也能够与 6.5 或 6.0 服务器通信。另一个是 Net-Library，这是一个抽象层，客户机和服务器都在此层上同网络抽象接口通信，不必为 IPX 还是 TCP/IP 困扰。在这里我们将不讨论 Net-Library 的工作细节;只要知道它们的工作基本上是将来自的网络通信底层的细节隐藏起来不让软件的其他部分看到就可以了。

服务器

前面已经提到过，客户机与 SQL Server 通信的主要方法就是通过使用 TDS 消息。TDS 是一种简单协议。当 SQL Server 接收到一条消息时，可以认为是发生了一个事件。首先，客户机在一个连接上发送登录消息(或事件)，并得到返回的成功或失败的响应。当您希望发送 SQL 语句时，客户机可以把 SQL 语言消息打包发送给 SQL Server。另外，当您希望调用存储过程、系统过程或虚拟系统存储过程(我们后面还要详细讨论)时，客户机可以发送 RPC 消息，这种消息相当于 SQL Server 上的一个 RPC 事件。对于上面的后两种情况，服务器会以数据令牌流的形式送回结果。Microsoft 没有把实际的 TDS 消息写入文档中，因为这被认为是 SQL Server 组件之间的私用契约。

目录存储过程是另一类关键的客户机/服务器的交互部分。这些存储过程首先在 ODBC 的 SQL Server 6.0 中出现，包括诸如 sp_tables 和 sp_columns 等存储过程。ODBC 和 OLE-DB API 定义了描述有关数据库对象的元数据的标准方法，这些标准需要适用于所有类型的 RDBMS 服务器，而不必调整为 SQL Server 自己的系统表。不是客户机向服务器发送对系统表的多个查询，并在客户机端建立标准的元数据视图，而是创建一组存储在服务器上的系统存储过程，并对 API 返回适当格式的信息。这种方法使得通过一次通信就可以完成很多重要的元数据请求。为 ODBC 编写的过程已经写入文档，通常适合需要从系统表中获取信息但其他机制没有提供这种方法的情况。这使得Transact-SQL过程和 DB-Library应用程序可以访问元数据，而不需要编写对 SQL Server 系统表的复杂查询，并且使应用程序不受今后 Microsoft 修改系统表的影响。OLE DB 定义了一组架构行集，它们类似于 ODBC 的元数据，但又和它不同。它创建了一组新的目录存储过程，以更有效地为这些架构行集植入数据。但是，这组新的存储过程没有写入文档，因为这些存储过程重复了早先提供的功能。通过现有的若干种方法都可以得到元数据，因此 SQL Server 开发组决定不显露这些并没有为编程模型增加新内容的对象。

计数器

服务器上新建性能监控的日志，取所需计数器，设定计划任务定时启动或建立SQL JOB定时执行命令：logman start 计数器名

想要了解更多关于SQL Server 2014的信息，请继续关注中培伟业。