(function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();

在Windows Server 2012 Core上安装SQL Server 2012 Core Edition

Categories: Private Cloud, SQL
Tags: ,
Comments: No Comments
Published on: 2012 年 08 月 27 日

很久没写东西了,总觉得没什么可写的,其实主要是没思路和没时间,总是处理一些凌乱的事情。最近一段时间一直泡在实验室里面,总算是有大把的时间做点东西了,把这些东西总结总结可以写点,今天先开个头。

Windows Server大家肯定用过,但是具体到Core模式用的人就不太多了,大部分Windows的管理员都习惯于使用GUI界面来完成一些配置和操作,但是确实Core模式对于服务器系统来说是一个很不错的选择,相比之下Linux服务器的管理员很少使用GUI来管理服务器。貌似Liunx显得高级一些,但是这种功能Windows也有。

首先要谈一下为什么要在Core模式上安装SQL。主要原因就是-这是个服务器,不需要向客户端一样的华丽的GUI,只要安装配置完成之后,基本上不愿意对它进行操作。当然更重要的是对于服务器来说最重要的是性能、稳定性、安全性、可用性这些指标。从性能上来说其实Core模式上的SQL Server并没有什么变化,所以我更看重的是安全性和可用性。毕竟对于SQL Server来说GUI是不需要的,IE也是不需要的,这样相关的补丁就少多了,如果你仔细看微软的补丁,很多都与GUI相关。如果需要GUI完全可以通过远程管理的方式来实现。在客户端上安装服务器管理工具和SSMS,也就不会在意服务器是不是有GUI了。我们需要的就是服务器能在哪里老老实实的干活,究竟是什么模式?Who Care?另外有一点不得不说,在Core模式下安装SQL Server你只能选择通过命令行来进行安装,安装的速度快很多,之前安装SQL Server 2012多数时间都是在等待UI,从部署的效率来讲,Core模式是最佳选择。

整个安装的过程非常的简单,在虚拟机上安装Windows Server 2012 Core最多10分钟就能搞定。安装完成之后需要安装一下.net framework 3.5.1,这个安装可以通过dism命令来实现,只不过需要注意一点,需要指定Source参数

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:d:\sources\sxs

也就是说需要你提供Windows Server 2012的安装文件,否则没法安装。

安装完成之后就可以把ISO换成SQL Server的安装文件了,我的安装文件是从MSDN上下载的,不知道到Core Edition与其他的安装介质是否有区别,其他的应该也可以(没测试过),貌似这个Core Edition应该是一个子集。

安装的时候需要一些参数

Setup.exe /q /ACTION=Install /FEATURES=SQL /INSTANCENAME=MSSQLSERVER /SQLSVCACCOUNT="<DomainName\UserName>" /SQLSVCPASSWORD="<StrongPassword>" /SQLSYSADMINACCOUNTS="<DomainName\UserName>" /AGTSVCACCOUNT="NT AUTHORITY\Network Service" /IACCEPTSQLSERVERLICENSETERMS

那个SQLSYSADMINACCOUNTS是必须的,其他的启动帐号都可以可选,如果需要SQL验证,需要添加一个SecurityMode和PWD参数,具体的参数可以参考 http://msdn.microsoft.com/en-us/library/ms144259.aspx

如果只安装DB Engine,整个过程应该在15分钟左右。BTW,安装之前需要配置一下Windows的防火墙及服务器的IP等网络相关的参数。

也许有人会问,这个东西有何意义?装一个GUI的有什么不好?通常的好处刚才都已经说过了,但是在一些特殊的环境下,这个非常有意义。最近在做的项目是与Private Cloud相关的。哥虽然做了多年的SQL MVP,但是俺还是从Windows NT时代的MCSE,那个时代的MCSE到现在应该是还挺值钱的,扯远了。在Private Cloud上快速部署虚拟机的时候vhd越小越好,Core模式能提供一个相对较小的vhd文件,我测试时做的vhd在8G一下,这样部署的时候更加合适,及时做镜像的时候麻烦一些,后续能省很多时间。当然要想做成Private Cloud,还需要很多工作。说Private Cloud就是上嘴唇一碰下嘴唇的事,但是真要是做出来还需要相当的时间,需要解决很多事情,后面我会慢慢说。如果没有开发背景或者没有写过PowerShell的同学做这个东西就很难了,很多问题都需要开发来实现,产品只能实现部分的功能,而且产品也有很多的局限,以后慢慢说吧。

SQL Denali-FileTable

Categories: Denali, SQL
Comments: No Comments
Published on: 2011 年 05 月 02 日

Filetable是一个很有意思的一个功能。很久很久以前微软曾经想把Windows的文件系统放到SQL里面来管,这样就能将结构化和非结构化的数据整合在一个平台来管理,而且可以嵌入在Windows的内部来实现。在Windows Vista年代曾经有一个叫WinFS的原型,当然最后这个东西还是没有最终Release。在SQL Server 2008里面微软还是希望将数据的应用(包括非结构化数据)整合到数据库里面,毕竟之前已经做了Text和Image数据类型,而且在SQL 2005里面也有了Max的数据类型,基本上可以说快要准备好了,所以在SQL 2008里面提供了一个新的数据类型叫Filestream,这个数据类型就不多说了,没听过的就去Bing一下吧。我在这个SQL 2008里面也针对Filestream做了一个项目,利用了RBS的框架写了一套具有负载均衡的RBS Provider,可以通过RBS为客户提供统一的数据访问接口,后面接上我的Provider就可以在SQL中管理Blob数据,当然数据是海量的,设计容量就要20TB。但是当时也觉得会有一些问题,其中最主要的还是在接口上。Filestream提供了Win32和TSQL这2中接口,但是对于应用程序来说必须针对Win32接口做特殊的处理,因为Win32接口处理文件的时候必须要先提供一个句柄,而这个句柄必须通过Filestream的特殊函数才可以获取,总之对于应用程序来说不是很友好。虽然可以通过RBS来进行扩展和包装,但是对于遗留应用来说除了重新写接口代码别无选择。

在Denali中(CTP2)里面,我终于看到了这个FileTable。FileTable是一种特殊的表,这个表有固定的列和索引,这个表的结构是不能修改的。其中存储了文件的基本信息和内容,当然内容列肯定是Filestream。和之前最大的变化是Denali在驱动层做了一些修改,将FileTable转换成一个通用的UNC路径,也就是说我们可以通过Windows Explorer来直接访问数据库里的这个表。这样一来对于现有的遗留应用程序来说就好多了,可以在不改变应用的前提下直接使用Filestream的特性,就像访问远程的共享目录一样,而文件的管理和备份直接在SQL里面完成,与应用程序数据也能完美的结合。

在FileTable上最适合的应用就是扩展的一些文件搜索应用了,例如Lucene。如果你觉得SQL的FTS不够强大(确实差一些,尤其是中文),就可以通过Lucene直接去读取FileTable,而且不需要在写特殊的代码,只需要配上分词就可以了。在SharePoint  2010里面已经提供了一个Filestream的RBS Provider,通过这个Provider可以将SharePoint的Blob数据写到数据库里面去(存储在文件系统上),只不过原始的Filestream对于应用来说是一个噩梦,用FileTable吧,改改配置文件就够了。

另外还要说一下,FileTable毕竟还是数据库,不是NTFS文件系统(你可以把它看成一个FAT32),一些NTFS支持的加密及压缩属性还是不支持的,至少是在文件系统的驱动上不支持。还有就是负载均衡,目前还有相应的解决方案,当然这个是可以进行二次开发的,如果我把之前的那个Provider改改就行了,且也非常简单。

TechEd 2010-如何构建企业级ETL 后续补充

Categories: SQL, SSIS
Tags: ,
Comments: 1 Comment
Published on: 2010 年 12 月 16 日

在TechEd 2010上讲了一门如何构建企业级ETL的Session,可能是因为技术方面的东西太多,没有什么太炫的Slides和Demo,听众反映一般,8.08分不太高,这里在把东西解释解释。

当时主要是因为工作比较忙,准备PPT和Demo就用了1天半的时间,确实有点仓促了,但是内容上感觉还是比较丰满的,主要目的就是给听众一个理念上的引导。

目前在企业里面用SSIS的客户还是比较多,但是大多数人还仅仅停留在如何使用SSIS进行转换,很多学习的教程也都是写那些控件的使用方法。实际上工程项目中遇到的一些实际问题是不能通过简单的控件来解决的,必须要有巧妙的设计,这个道理就像写程序一样,否则也就不会有设计模式这个领域了。

SSIS中提供了一个扩展性很强的框架,Control Flow&Data Flow,具体概念我就不多说了,有人反映我讲课的时候经常重复这些东西,其实也不是重复,只是很多人没有深入的理解。我们的设计其实很多地方都会在Control Flow里面进行体现,所以要有好的设计,就必须先理解Control Flow。除了理解Control Flow外,对于Parameter和Configuration的灵活应用也非常重要,这些都是在进行控制的过程中必不可少的连接技术,没有这些东西也无法把不同功能的包和流程组织在一起。另外一个重要的功能就是Script,Script是整个包设计里面的灵魂,很多动态功能都要依赖于此,而且Script中写的不再是vbScript和VB.net,我们可以写C#了,功能上丰富多了,尤其是对象参数和C#的结合。我们可以设置任何Object对象参数,在Script里面就意味着我们可以传递更丰富的内容,而不仅仅局限在基本数据类型,例如int,string等,我们可以传递类似于array,list等更高级的参数类型,提供更灵活的调用。有了Parameter,Configuration,Script,我们可以借助于一些容器控件来实现更多功能,具体能实现什么,就看你想怎么设计了,至少SSIS已经提供了这个框架。

另外对于企业来说SSIS的性能也是需要特殊注意,因为SSIS操作过程中对于系统整体来说都会有短时的压力,需要在规定的时间窗口内完成ETL的过程,否则可能会影响其他业务系统的正常运行。大部分用户都会遇到性能问题,而多数性能问题都是由于下列原因引起的

  1. 数据源读取速度
  2. 目标写入速度
  3. 转换过程设计

数据读取速度

这个部分的原因要看数据源系统的情况。我们都希望对整个系统来说有一个有效的方式进行性能评估及性能优化,所以我建议这个数据源部分使用可以分割边界的系统,也就是说不要用可能过分依赖于网络,远程站点等异步的数据源系统。文件和本地局域网数据库都是比较好的选择,至少网络延时可以忽略不计,否则的话性能上的SLA很难评估,相比局域网数据库或文件系统性能的稳定性比远程HTTP或Web Service要好很多。有了稳定的数据源就要评估这种数据源的极限读取能力,也就是做Baseline,这个很重要,因为你的系统性能的极限和这个有很大关系,但是这个极限并不是不能突破,关键看设计,至少在没有特殊设计的情况下,极限性能就是对于数据源单纯的读取性能。如果数据源是关系型数据库,就需要对数据库或者查询进行优化。

目标写入速度

这方面我就不多说了,微软专门有相应的文章写了如何进行快速的数据装载,主要的问题就是No Log或者Mini Log的设计。这个过程也相对好进行评估。用BCP就能测试出来。

转换过程设计

这个部分相对来说可以做的事情比较多。SSIS的Data Flow就是Pipeline模式,你要做的事情就是让数据能够流动起来,别有堵塞。聚合、排序都会有阻塞,都要慎用。另外Merge Join也要注意,这个需要2个流入的数据源是排序的,这种排序最好考虑在数据源里面实现。如果数据源不支持,例如文件系统,可以通过SQL做一个Staging的数据库,临时排序使用,至少可以利用内存和tempdb排序,而SSIS都是在内存里面排序,你不一定有足够大的内存,至少我遇到在224G内存的服务器上出现内存不足的情况,当时的数据量是1TB。另外就是内存的占用和我们每行数据的长度及数据类型都有关系,要精确设计一下,不能用Select *这种方式,如果文件系统,需要在读取的时候转换一个准确的数据类型。

上面说了3中在Data Flow常见的设计问题和思路,在Control Flow里面的事情比较多,但是最常见的就是并行设计。很多情况下并行设计能大幅度提升你系统的性能。多数情况下,SSIS服务器并没有发挥出系统的整体性能,只要找到不同时期的性能瓶颈,逐步优化后都能有很好的性能提升,但是并行是大家经常忽略的一种情况。如果你发现你的IO,网络,内存都不存在瓶颈的时候,你要提升性能,就要注意看一下CPU了。对于CPU利用率来说,我们不能看整体,因为多核和多CPU情况下,我们必须要看每一个核的利用情况,很有可能一个核已经100%利用率,但是系统只能一个线程,这个时候必须要考虑多线程设计。SSIS设计上并没有直接提供对于线程的控制,真的没有做到与时俱进,目前很多服务器上都是4-6个核,4CPU的服务器也很多,通常每个核提供20MB/s以上的吞吐量,你可以评估一下,你的系统能够做到的性能极限是多少。我在一个测试过程中在96核的系统上可以做到大约1TB/s的数据吞吐,这还是我限制了40个线程。但是线程的设计比较复杂,需要考虑数据源的形式及特征以及Control Flow中流程的关系。基本上都是通过脚本结合流程控制组件来动态控制,目前除了这个没有其他的办法。微软目前可以提供一个Data Flow层面的转换组件RRD(Round Robin Distributor)在Data Flow里面实现多线程,目前这个组件还没有Release。如果大家在项目里面有需求,可以找我联系。

先写到这里,后面有时间在讲讲如何使用Control Flow。

page 1 of 1
Welcome , today is 星期一, 2017 年 03 月 27 日