盘点SQL Server 2014不为人知的新特性

    文章来源:中国互联 更新时间:2013-8-12 9:26:54
分享:

在所有用户都以为SQL Server无法进一步提升时,微软公布了其最新版本——SQL Server 2014。虽然微软还没有明确具体发布时间,但在本文中,笔者将带大家一起了解我所知晓的、关于SQL Server 2014的一切。
  1.利用SSD对高使用频率数据进行缓存处理
  用户可以指定一块SSD(或SSD阵列)作为内存扩展。SQL Server 2014能够自动对数据进行缓存处理,且不必担心数据丢失风险。(其中只保存纯粹的页面信息而不会掺杂其它数据。)新机制的最佳表现舞台在于读取频率超高的OLTP工作负载,而且能够与集群中的本地SSD顺利对接——每个节点都可配备属于自己的本地SSD(使用方式与TempDB一样),并为数据及日志文件保留足够的SAN传输能力。SSD价格低廉,而且随着技术发展,其价格会进一步下降、性能则逐渐攀升。不过在下决心使用这项功能之前,大家可能会提出以下几个问题:
  ?全局主动查询数据集是否会超过内存容量?请注意,我指的不是全部数据:数据库中的一部分信息会被归档、成为历史记录或者审计表格,这些内容永远不会成为查询对象;即使如此为其提供缓存自然毫无意义。
  ?是否已经对服务器上的内存进行最大化扩展?如果这项工作还没完成,我劝各位最好马上着手——内存要承载的内容可远不止纯页面这么简单。
  ?实际业务需求是否强迫我们使用共享化存储或者本地存储磁盘?如果答案是否定的,不妨考虑将数据全面迁移到本地SSD当中。
  ?服务器是否有足够空间来容纳接入PCI Express或者SAS/SATA的固态硬盘?
  如果大家对上述问题的答案都是肯定的,那么SSD缓冲池扩展可能更适合您。微软本可以在此止步,但我仍然强烈建议大部分客户尝试新版本,其实际性能表现完全可以用“杀手级”来形容。
  2.更多在线维护操作
  分区列表中充斥着大数据?管理者根本没有为维护工作预留出充足的时间?每天的工作已经极度繁忙,大家没有任何精力再做其它尝试?在SQL Server 2014中,我们可以重建一套单分区在线索引,并随意向其中添加或清除DBA指定的锁定分区。对于全天候工作负载而言,这意味着数据库管理员能够在低锁定、低CPU以及内存占用的前提下完成维护工作。扩展事件也迎来新增强,可以利用它监控当前网络中的带宽使用大户并将其关闭。下面是语法的使用方式:

 其中所涉及的新参数包括:

 

如果-BLOCKERS,那么 SQL Server将中止阻碍索引重建的查询请求。如果=SELF,索引重建工作将停止、从而向用户的查询请求让位。如果=NONE,两套进程都将处于暂停状态,等待管理员手动调整。当前的SQL Server 2012就采取这种处理方式,它也将在SQL Server 2014中作为默认方案出现。
  3.AlwaysOn可用组支持更多次级服务器
  如果迫切需要向外扩展读取效果,SQL Server 2014准备了多达八套次级服务器的支持能力(由上版本的四套上调至八套)。当然,我们需要使用付费的企业版才能拥有对应授权,如果已经决定将数据副本保存到其它报告或商务智能服务器中,那么此次功能提升将大大简化日常工作。
  4.AlwaysOn AG可读取次服务器更加可靠
  在SQL Server 2012中,如果主服务器发生离线故障或者集群仲裁机制失效,可读数据库副本也将一同陷入瘫痪(这种情况颇具讽刺意味,因为读取次级服务器中的内容正是遭遇故障后的第一反应)。过去我们对此毫无办法,因为整个流程会自动完成。但在SQL Server 2014中,即使主服务器无法正常工作,次服务器也将继续在线并允许用户访问。不过需要注意的是,典型的AlwaysOn AG连接会以AG监听名称为依据从主服务器的可读取副本中获取名单。这意味着为了保证报告查询功能始终可用,我们必须首先禁用AG监听器——即必须直接接入副本的服务器名称。个人倾向于使用一套专门的可读取副本DNS记录,例如readonly.mydomainname.com,并将其作为报告服务器的指向目标。
  5.将Azure虚拟机作为AlwaysOn AG副本
  相信几乎没有多少客户愿意为了偶尔出现的停机事故而部署长年闲置的离线数据中心。现在,在AlwaysOn副本添加引导功能中,大家可以利用“添加Azure副本”按钮轻松将本地设施与Azure订阅登录加以整合。这套引导功能允许大家选择虚拟机镜像、虚拟机大小(例如核心数量与内存容量)、云副本名称、管理员密码等等。下面我们对其进行细化说明:
  ?副本初始化是指由内部部置指向Azure虚拟机的全面数据库备份/恢复流程,如果各位基础设施的带宽有限、数据量又比较庞大,这可能不算什么理想的解决方案。
  ?内部与Azure虚拟机之间的连接要求使用将自有数据中心与Azure数据中心对接的VPN机制,就当前的主流方案来说,这应该是一套硬件设备、就是说需要一小笔额外投入。即使如此,新方案还是要比以往购买额外设施便宜得多、灵活性也更高。
  ?如果以此为基础实现灾难恢复,则需要在Azure端拥有一套Windows域控制器。缺乏域控制器的辅助,所有Windows设备都会在主站点崩溃后丧失登录能力,灾难恢复也就无从谈起。SSMS(即SQL Server管理工具)不会自动部署灾难恢复机制(也不会主动提醒用户进行部署)。
    6.故障转移集群支持集群化共享分卷
  搭配普通分卷时,分卷在同一时间只能归属于同一节点,也就是说整个分卷都受某个特定节点的管辖,其它节点无法发现/读取/写入该驱动器分卷。不过Windows Server集群提供一种名为集群化共享分卷的特殊驱动器分卷类型,其实际灵活性更高。多集群节点可同时被接入同一分卷,且各个节点可单独访问驱动器中的不同文件。Windows与Hyper-V也将在短期内支持这项新特性,但目前还属于SQL Server的专利。新特性的最大好处在于,如果SQL Server集群中的某个节点无法接入存储体系,它仍然能够通过网络向其它节点中的SAN连接写入数据、读取信息。
  7.在Azure中实际智能备份
  SQL Server 2012 CU2已经允许用户将数据库备份至Azure存储体系。我已经不只一次听人问起:“我该如何让备份机制速度更慢、频率别那么死板?”他们希望通过自己的互联网连接实现内部数据库与云存储体系间的备份,而且要求备份频率不要太过死板。为了满足这种需求,微软推出了智能备份方案。在这项新功能的帮助下,SQL Server会根据情况判断是否需要执行全局或者差异化备份,决定多久生成一次事务日志等。此举对于某些将服务器交由虚拟机供应商托管、手中拥有大量免费带宽资源的客户来说极具吸引力——尤其是那些在Windows Azure虚拟机中托管SQL Server的用户。
  8.内部SQL Server搭配Azure存储中的数据/日志文件
  ?昂贵的内部授权许可
  ?昂贵的云对接带宽成本
  ?向微软支付数据存储费用
  ?更低的备份速度(因为无论实际数据走向如何,大家的数据都必须采取由Azure存储向本地内部存储传输的路线;值得庆幸的是,微软禁止用户从本地将数据再度传回Azure存储、从而产生二次带宽使用成本)
  具体语法如下:

 

      9.Hekaton:专用内存内OLTP列表
  如果应用程序正面临严重的并发问题,即成千上万并发连接造成可怕的数据锁定状况,Hekaton带来一种神奇的解决方案。其具体原理相当复杂,它所引发的部分负面影响如下:
  ?需要改变自己的数据模式。举例来说,它不支持标识字段——需要利用GUID作为集群化主键。
  ?需要变更现有代码。Hekaton与已存储程序协作良好,而且能够将某些已存储程序编译为本地代码。
  ?整个处理流程在内存中进行。如果发现自己的Hekaton表格体积暴增,这就意味着可供其它表格使用的缓存空间已经大幅削减。如果大家的内存空间已然告罄,整套系统将陷入瘫痪。
  其它出色改进:
  ?可更新的集群化列式存储索引;
  ?基数估计值更合理、查询性能也因此提升;
  ?IO迎来资源监管工具;
  ?Sysprep(系统准备工具)显著增强;
  ?提供向Azure虚拟机中部署数据库的引导机制;
  ?职责分离机制得到强化,现在无权读取数据的数据库管理员或者审计人士终于获得了数据管理权——但无法管理服务器;
  ?Windows Server 2012 R2协作改进——支持ReFS、VHDX容量在线调整、存储分层以及SMB(即服务器信息块)改进。
  个人分析意见
  新一代SQL Server为各类用户都带来切实的改进。如果你是一位统领数TB信息的数据库管理员,SSD缓冲池扩展以及细化索引重建将成为你的最爱。如果你是商务智能拥护者,集群化列式存储索引则是你不可错过的重要方案。如果你是一位客户众多的软件即服务供应商,支持CSV的故障转移集群功能与查询性能提升很可能令你尖叫。如果你是一位专注于SQL Server后端的开发人员,各类扩展成果也足以满足你贪婪的需求。
  不少数据库管理员都担心微软如今所选择的“全云化”路线是否会影响到传统内部产品的发展脚步。SQL Server 2014的出炉向全世界宣布,微软仍然在努力打造令人惊叹的内部解决方案。

在线咨询
  • 在线时间
  • 8:00-21:00
盘点SQL Server 2014不为人知的新特性-中国互联

盘点SQL Server 2014不为人知的新特性

    文章来源:中国互联 更新时间:2013-8-12 9:26:54
分享:

在所有用户都以为SQL Server无法进一步提升时,微软公布了其最新版本——SQL Server 2014。虽然微软还没有明确具体发布时间,但在本文中,笔者将带大家一起了解我所知晓的、关于SQL Server 2014的一切。
  1.利用SSD对高使用频率数据进行缓存处理
  用户可以指定一块SSD(或SSD阵列)作为内存扩展。SQL Server 2014能够自动对数据进行缓存处理,且不必担心数据丢失风险。(其中只保存纯粹的页面信息而不会掺杂其它数据。)新机制的最佳表现舞台在于读取频率超高的OLTP工作负载,而且能够与集群中的本地SSD顺利对接——每个节点都可配备属于自己的本地SSD(使用方式与TempDB一样),并为数据及日志文件保留足够的SAN传输能力。SSD价格低廉,而且随着技术发展,其价格会进一步下降、性能则逐渐攀升。不过在下决心使用这项功能之前,大家可能会提出以下几个问题:
  ?全局主动查询数据集是否会超过内存容量?请注意,我指的不是全部数据:数据库中的一部分信息会被归档、成为历史记录或者审计表格,这些内容永远不会成为查询对象;即使如此为其提供缓存自然毫无意义。
  ?是否已经对服务器上的内存进行最大化扩展?如果这项工作还没完成,我劝各位最好马上着手——内存要承载的内容可远不止纯页面这么简单。
  ?实际业务需求是否强迫我们使用共享化存储或者本地存储磁盘?如果答案是否定的,不妨考虑将数据全面迁移到本地SSD当中。
  ?服务器是否有足够空间来容纳接入PCI Express或者SAS/SATA的固态硬盘?
  如果大家对上述问题的答案都是肯定的,那么SSD缓冲池扩展可能更适合您。微软本可以在此止步,但我仍然强烈建议大部分客户尝试新版本,其实际性能表现完全可以用“杀手级”来形容。
  2.更多在线维护操作
  分区列表中充斥着大数据?管理者根本没有为维护工作预留出充足的时间?每天的工作已经极度繁忙,大家没有任何精力再做其它尝试?在SQL Server 2014中,我们可以重建一套单分区在线索引,并随意向其中添加或清除DBA指定的锁定分区。对于全天候工作负载而言,这意味着数据库管理员能够在低锁定、低CPU以及内存占用的前提下完成维护工作。扩展事件也迎来新增强,可以利用它监控当前网络中的带宽使用大户并将其关闭。下面是语法的使用方式:

 其中所涉及的新参数包括:

 

如果-BLOCKERS,那么 SQL Server将中止阻碍索引重建的查询请求。如果=SELF,索引重建工作将停止、从而向用户的查询请求让位。如果=NONE,两套进程都将处于暂停状态,等待管理员手动调整。当前的SQL Server 2012就采取这种处理方式,它也将在SQL Server 2014中作为默认方案出现。
  3.AlwaysOn可用组支持更多次级服务器
  如果迫切需要向外扩展读取效果,SQL Server 2014准备了多达八套次级服务器的支持能力(由上版本的四套上调至八套)。当然,我们需要使用付费的企业版才能拥有对应授权,如果已经决定将数据副本保存到其它报告或商务智能服务器中,那么此次功能提升将大大简化日常工作。
  4.AlwaysOn AG可读取次服务器更加可靠
  在SQL Server 2012中,如果主服务器发生离线故障或者集群仲裁机制失效,可读数据库副本也将一同陷入瘫痪(这种情况颇具讽刺意味,因为读取次级服务器中的内容正是遭遇故障后的第一反应)。过去我们对此毫无办法,因为整个流程会自动完成。但在SQL Server 2014中,即使主服务器无法正常工作,次服务器也将继续在线并允许用户访问。不过需要注意的是,典型的AlwaysOn AG连接会以AG监听名称为依据从主服务器的可读取副本中获取名单。这意味着为了保证报告查询功能始终可用,我们必须首先禁用AG监听器——即必须直接接入副本的服务器名称。个人倾向于使用一套专门的可读取副本DNS记录,例如readonly.mydomainname.com,并将其作为报告服务器的指向目标。
  5.将Azure虚拟机作为AlwaysOn AG副本
  相信几乎没有多少客户愿意为了偶尔出现的停机事故而部署长年闲置的离线数据中心。现在,在AlwaysOn副本添加引导功能中,大家可以利用“添加Azure副本”按钮轻松将本地设施与Azure订阅登录加以整合。这套引导功能允许大家选择虚拟机镜像、虚拟机大小(例如核心数量与内存容量)、云副本名称、管理员密码等等。下面我们对其进行细化说明:
  ?副本初始化是指由内部部置指向Azure虚拟机的全面数据库备份/恢复流程,如果各位基础设施的带宽有限、数据量又比较庞大,这可能不算什么理想的解决方案。
  ?内部与Azure虚拟机之间的连接要求使用将自有数据中心与Azure数据中心对接的VPN机制,就当前的主流方案来说,这应该是一套硬件设备、就是说需要一小笔额外投入。即使如此,新方案还是要比以往购买额外设施便宜得多、灵活性也更高。
  ?如果以此为基础实现灾难恢复,则需要在Azure端拥有一套Windows域控制器。缺乏域控制器的辅助,所有Windows设备都会在主站点崩溃后丧失登录能力,灾难恢复也就无从谈起。SSMS(即SQL Server管理工具)不会自动部署灾难恢复机制(也不会主动提醒用户进行部署)。
    6.故障转移集群支持集群化共享分卷
  搭配普通分卷时,分卷在同一时间只能归属于同一节点,也就是说整个分卷都受某个特定节点的管辖,其它节点无法发现/读取/写入该驱动器分卷。不过Windows Server集群提供一种名为集群化共享分卷的特殊驱动器分卷类型,其实际灵活性更高。多集群节点可同时被接入同一分卷,且各个节点可单独访问驱动器中的不同文件。Windows与Hyper-V也将在短期内支持这项新特性,但目前还属于SQL Server的专利。新特性的最大好处在于,如果SQL Server集群中的某个节点无法接入存储体系,它仍然能够通过网络向其它节点中的SAN连接写入数据、读取信息。
  7.在Azure中实际智能备份
  SQL Server 2012 CU2已经允许用户将数据库备份至Azure存储体系。我已经不只一次听人问起:“我该如何让备份机制速度更慢、频率别那么死板?”他们希望通过自己的互联网连接实现内部数据库与云存储体系间的备份,而且要求备份频率不要太过死板。为了满足这种需求,微软推出了智能备份方案。在这项新功能的帮助下,SQL Server会根据情况判断是否需要执行全局或者差异化备份,决定多久生成一次事务日志等。此举对于某些将服务器交由虚拟机供应商托管、手中拥有大量免费带宽资源的客户来说极具吸引力——尤其是那些在Windows Azure虚拟机中托管SQL Server的用户。
  8.内部SQL Server搭配Azure存储中的数据/日志文件
  ?昂贵的内部授权许可
  ?昂贵的云对接带宽成本
  ?向微软支付数据存储费用
  ?更低的备份速度(因为无论实际数据走向如何,大家的数据都必须采取由Azure存储向本地内部存储传输的路线;值得庆幸的是,微软禁止用户从本地将数据再度传回Azure存储、从而产生二次带宽使用成本)
  具体语法如下:

 

      9.Hekaton:专用内存内OLTP列表
  如果应用程序正面临严重的并发问题,即成千上万并发连接造成可怕的数据锁定状况,Hekaton带来一种神奇的解决方案。其具体原理相当复杂,它所引发的部分负面影响如下:
  ?需要改变自己的数据模式。举例来说,它不支持标识字段——需要利用GUID作为集群化主键。
  ?需要变更现有代码。Hekaton与已存储程序协作良好,而且能够将某些已存储程序编译为本地代码。
  ?整个处理流程在内存中进行。如果发现自己的Hekaton表格体积暴增,这就意味着可供其它表格使用的缓存空间已经大幅削减。如果大家的内存空间已然告罄,整套系统将陷入瘫痪。
  其它出色改进:
  ?可更新的集群化列式存储索引;
  ?基数估计值更合理、查询性能也因此提升;
  ?IO迎来资源监管工具;
  ?Sysprep(系统准备工具)显著增强;
  ?提供向Azure虚拟机中部署数据库的引导机制;
  ?职责分离机制得到强化,现在无权读取数据的数据库管理员或者审计人士终于获得了数据管理权——但无法管理服务器;
  ?Windows Server 2012 R2协作改进——支持ReFS、VHDX容量在线调整、存储分层以及SMB(即服务器信息块)改进。
  个人分析意见
  新一代SQL Server为各类用户都带来切实的改进。如果你是一位统领数TB信息的数据库管理员,SSD缓冲池扩展以及细化索引重建将成为你的最爱。如果你是商务智能拥护者,集群化列式存储索引则是你不可错过的重要方案。如果你是一位客户众多的软件即服务供应商,支持CSV的故障转移集群功能与查询性能提升很可能令你尖叫。如果你是一位专注于SQL Server后端的开发人员,各类扩展成果也足以满足你贪婪的需求。
  不少数据库管理员都担心微软如今所选择的“全云化”路线是否会影响到传统内部产品的发展脚步。SQL Server 2014的出炉向全世界宣布,微软仍然在努力打造令人惊叹的内部解决方案。

在线咨询
  • 在线时间
  • 8:00-21:00