SQL中国研发中心

TechEd 2009 SQL Server动手实验答疑

TechEd2009上的SQL Server动手实验得到了广大学员的欢迎，不但积极与讲师们互动，还提出了许多高质量问题。在这篇博文中，我们总结了一些代表性的问题与大家共享。

问：SQL分区的最佳实践是什么？微软建议一个SQL Server上有多少个分区最佳？是10-100么？每个分区的最佳的大小是多少？
答：尽管分区表最多可以分成1000个分区（详见http://msdn.microsoft.com/en-us/library/ms143432.aspx），但数据库的性能和空间达到最佳优化的时候，应该是某一个平衡点，因为分区过少或过多都会有额外的开销。建议是根据具体条件，首先建立一个基准配置环境和基准性能尺度作为参考，然后逐步改变分区数和/或分区大小，分析变化，然后逐步找到最佳点。

问：在SQL Server 2005/2008上，当一个存储过程执行返回千万行的时候，SQL Server会占到16G的内存。有没有一个方法能让SQL Server自动的释放内存？
答：SQL Server能够很好的管理和使用所分配的内存。需要更多可用内存时，SQL Server会自动根据最旧最少使用的算法分配一些内存。当系统内存不足时，SQL Server也会自动释放一些内存。不建议使用DBCC FREESYSTEMCACHE或DBCC DROPCLEANBUFFERS等命令释放内存，这样会严重损坏系统的总体性能。

问：在SQL 2005上，对一个视图做了一个索引，但是当查询表的时候，在执行计划中，查看到那个视图的索引被采用了，这是怎么回事？
答：SQL Server查询优化器会根据索引和统计自动选择最佳的查询执行计划。

问：有一个网站每天有大量的日志，大约每天3G。用户希望把这些日志数据保存到SQL数据库中然后进行分析，SQL server有相关的解决方案么？ 听说MySQL有类似的方案 :-)
答：可以使用SQL Server对网络日志进行分析。建议是按照日志格式建立表，然后BULK INSERT日志到表中，然后可以用SQL Server Analysis Service进行数据分析。详细步骤请参考http://support.microsoft.com/kb/296085。

问：有没有一个方法把一个表的数据存放在一个指定的数据文件中？用户的场景是这样的：有一个数据量很大的表，用户希望将经常查询的数据放在一个高速磁盘上，将很少查询的数据放在一个低速的磁盘上。注意，随着时间的推移，常用的数据会变成不常用的数据，但是，SQL Server表的分区只支持在同一个分区内进行切换（SWITCH），而且，在一个分区中，无法指定将数据放到哪一个文件中，当一部分常用数据变成不常用数据时，如何将这部分新的不常用数据移到低速磁盘上？
答：SQL Server的表是基于文件组进行管理的。建议的解决方案有以下两种。第一，可以先创建一个文件组，然后在那个慢速磁盘上创建一个文件并归到这个文件组，然后用create table on filegroup 的语法方式创建表，最后将数据从表中迁移过来。第二，以2007年、2008年和2009年数据为例，可以先创建一个文件组FileGroupA，然后在那个慢速磁盘上创建一个文件并归到这个文件组FileGroupA，然后在这个文件上建表和分区PartitionA，如图1；然后SPLIT分区，从V1到V1+V2，将数据2008、2009分开为FileGroupB和FileGroupC上的分区PartitionB和PartitionC，如图2；最后合并MERGE分区PartitionB到PartitionA，如图3。

问：分析服务的备份和恢复时，选择文件路径的窗口没有 [浏览 … ] 功能，只支持用户手动输入。
答：这个问题已反馈给产品组。

曾屹 林默

精彩的微软技术大会（TechEd）- 你去了吗？

每个微软技术大会（TechEd）对我来说都具有特别的意义。因为在这个里，我能遇到许多对微软技术有浓厚兴趣和热情的朋友们。在这个里，我们一起互动，一起讨论微软的最新技术。今年IT朋友们都共聚在北京的国家会议中心参加微软技术大会。

 
在这三天里，SQL Server 团队的讲师们也与大家分享了许多对云端数据库 （SQL Azure）、商业智能 （Business Intelligence）、数据库管理、虚拟化和跟踪及排错的最新发展。今年商业智能的巨人Donald Farmer 也前来赴约。Donald与大家分享了数据挖掘的技术和自助式商务智能。从数据挖掘的讲座中，大家深入了解如何应用数据挖掘的技术在 SQL Server 动态数据库管理视图(DMV) 的数据中找出异常。从自助式商务智功能的讲座中，Donald 介绍了自助式商务智能的重要性和PowerPivot 如何让熟悉Excel 的用户分析海量的数据。在演示中，大家都对PowerPivot 如何快速的分析了一亿行数据叹为观止，不约而同的热烈拍掌！

微软技术大会（TechEd）结束了！但我深信参加大会的朋友们都增加了对微软技术的了解与热情。真棒！

项目经理
卓伟雄

我们TechEd见

2009年微软技术大会（TechEd）中国下周就将在北京召开了，SQL Server中国研发团队将派出多位项目经理、软件设计开发工程师和软件测试开发工程师，与中国程序开发者和IT从业人员分享我们最新的产品开发。以下是我们负责的课程、动手实验室和专家交流区列表，希望能在大会现场与大家面对面交流。

针对程序开发者

针对IT专业人士

此外，11月7日 14:25至15:10还会有SQL Server研发团队交流会，欢迎光临。

微軟實習經驗分享

撰文者簡介：Marcus，是土生土長於香港、半諳普通話的二十歲小伙子，正於香港中文大學修讀計算機科學與工商管理雙學位課程。2009年暑假，他加入了上海微軟的SQL Server Manageability團隊作為期兩個月的實習。

時間有如白駒過隙，兩個月的實習已近尾聲。從香港乘風來到上海、體驗微軟工作喜與樂、感受上海風土人情──一切一切，盡皆難忘！特撰此文，以初生之犢的眼光記下這兩個月的實習經驗，既為個人收藏，也與大眾分享。

在巍峨的山岳中貢獻碎石

記得實習第一天的下午，我的上司Shirley跟我作了一次的迎新詳談，向我仔細描繪我未來兩個月的工作的藍圖。那個時候，我對SQL Server一無所知，不過先把工作接下來好了，也著手開始學習使用它。

第一天接觸SQL Server，覺得它就像是一座巍峨的山岳──它高聳入雲、綿延千里，其結構之嚴謹、功能之強大、目光之遠矚，實在令人望而生畏。作為SQL Server的門外漢，真的不知如何入手，更遑論要計劃為它加添新的功能了！

投入實習工作一段時間以後，仍覺得它深不可測，卻也漸漸地覺得它平易近人多了。說到要為它貢獻一項新的功能，少不免有點膽怯，但我已經有勇氣下定決心要把這項功能做好。經過實習的第三個星期的團隊內部批閱、第五個星期的外部批閱以後，我們基本上議定了這項功能的定位；在第八、第九個星期的兩次文檔批閱以後，規格文檔也算是完成了。我自問已經在自己能力範圍以內把工作做好，算是對得起自己了吧！
 
縱使我所訂下的功能，只是整座山脈的一塊碎石、甚至可能只是在山腳邊的碎石堆裏的其中一小顆，但我真切的感受到：微軟花這麼多的人力物力構築的宏偉的山巒，是為了讓我們的顧客站得更高，看得更遠。

十月懷胎、誕下孩子

我所體驗的Program Manager（PM）的工作，就是在獲悉顧客群對產渴求的一項功能後，對這個功能作完整及準確的定位，並書寫一份便利軟件開發工程師們工作的規格文檔。據悉，PM的其他的工作還包括成本考慮、哪個小功能會留下或者刪掉、協調團隊與團隊之間的合作之類；不過作為一個只待在這裏兩個月的實習生，暫時沒能力也沒時間一嘗這些工作的滋味呢。

在兩個月實習期裏面，我就是從我的上司口述的一個概念開始，悉心計劃、評估顧客實際需要、研究可行性、對功能作精確定位、讓同事們檢閱定位是否恰當、書寫一份二三十頁的文檔、再多次批閱……以往作為使用者的我，怎麼也看不出就是一個小功能，背後的工作居然是如此繁多！

如果說，一項功能是孩子，那麼我感到我所做的，跟諸位十月懷胎、誕下孩子的媽媽一樣。看著孩子在懷裏漸漸成形，開始感到他滾來滾去、淘氣地踢踢，那種喜悅實在是不能言喻的。其他的同事，或溫言軟語，或強烈表達，都是為了讓我這位媽媽做得更稱職，讓孩子有更好的未來。實習期太短了，我沒有辦法看著孩子出生、茁壯成長、長大成人，然則這種看著孩子長出個雛形的喜悅，非筆墨所能形容。

結語

兩個月的實習快結束了，很感謝我的上司與導師Shirley對我的關懷與悉心指導。也感激團隊其他成員對我的包容、幫助、支持與鼓勵。日後SQL Server於我來說，不再只是一個產品了──它是活生生的回憶，是一段難忘的歲月，也是一張張的笑臉。

白德全

Balisage 2009标识技术会议（六）

第三天（8/13/2009），下午

关键词：SIMD，XML，高性能处理

首先让我揭开上篇文章里的谜底，那是一只笔（右图），有兴趣的读者可以bing一下“PenAgain”。

今天中午，和其他与会者一起用午餐，我有幸认识从加拿大温哥华专程前来参加Balisage 2009的西蒙•佛雷泽大学（Simon Fraser University）计算机科学系的罗伯特D. 卡麦隆教授（Dr. Robert D. Cameron）。他很高兴地给我介绍了他和他的学生一起正在研究的项目，简而言之是利用现在愈来愈受到关注的CPU支持的SIMD（single instruction，multiple data）[1]指令集提高XML文件的处理速度。

想了解这究竟是一项什么样的技术？得先了解什么是SIMD，所谓的“单一指令，多数据”，也就是说CPU可同时在一个集合的数据上同时执行同一条指令。这个技术现在被广泛运用在计算机的图像处理单元（GPU），而越来越多的主流CPU也具备了类似的功能。我们拿Intel最新i7架构的CPU举例，它支持SSE（Streaming SIMD Extensions）4.2指令集，内置多个128位专门用于SIMD的寄存器。也就是说，可以将16个字节的ASCII数据或是8个双字节的Unicode数据载入一个128位的寄存器，然后同时对这128位数据进行查询，索引，位操作等功能。

而让我大开眼界的是，卡麦隆教授的项目组通过他们的不懈努力终于研究发明了一项独特的技术，称为parabix（Parallel bit streams for XML™）[2]，它利用位加法可以充分利用SIMD的优势成倍地提高XML的处理速度，而这项技术更可以广泛运用在其他数据处理领域，比如他们写的UTF8到UTF16的转码程序可以平均使用0.9-6.8个CPU时钟周期处理每字节数据，速度是标准的UNIX下字符编码转换程序iconv的十倍。

经卡麦隆教授允许，我在这里借用parabix公开的技术资料[3]中的内容给读者来介绍一下SIMD位加法的基本概念。假设我们有一窜XML字符数据，如表中所示，我们想做的是找出字符串中所有用“&#数字序列；”表示的Unicode特征项：

经过以上运算，由第七步找到两个可能的特征项，而第九步结果表示其中一个是错误的，并提供了具体错误的位置。

我想通过以上的介绍，你一定会和我一样为SIMD技术在XML和其他数据处理领域所能发挥的作用而鼓舞。

网络参考链接：

1. http://en.wikipedia.org/wiki/SIMD
2. http://parabix.costar.sfu.ca/
3. http://parabix.costar.sfu.ca/attachment/wiki/WikiStart/balislides.pdf

Balisage 2009标识技术会议（五）

第三天（8/13/2009），中午

关键词：会场内外，花絮，纪念品，开小差

连续几篇都是讨论技术的话题，我想在这篇博客里改变一下，写一些会场内外的见闻。在前面说起Balisage 2009会场设置在Best Western Europa酒店（右图，由maps.bing.com的3D地图生成）。会议组织者包了也许是这小个酒店所有可供会议使用的多功能厅（其实只有两个）。都说北美洲有很好的互联网接入服务，但是第一天，酒店还是颇费了一些周折才为所有与会者提供了无线网络连接。

我曾经提起，这个会议是一个从业人员相互切磋的盛会。会议的组织者采用很多方法来促进与会者的交流，不仅提供免费早餐，会间休息的茶点等等，还在主会场四周的墙上提供空间给与会者张贴大幅学术和产品介绍，其中有一块区域取名为“会场里听到的”（Heard in the Halls），类似BBS（左图），上面钉了好多写着一两句话的便条，都是与会者们听到和想到的。比如“By real world，I mean my world”（所谓真实的世界，我指是我的世界），“Developers do not just interpret roles；they make rules”（开发者不仅解释法则，而且创造法则），诸如此类。第一次参加这个会议的我可以感觉到，虽然参加这个会议的学者和业界人员虽然来自不同国家和地区，但似乎他们互相都特别熟悉，讲演间隙往往三五成群手里端着饮料继续讨论。到了下一场讲演开始的时间，有个热心的会议组织者会绕场一周，一边走一边挥动手里的铃铛，提醒“时间到了，请回座。”

说起大会的纪念品其他也没有什么特别的，无外乎是些印有Balisage 2009字样的贴花，徽章，小包，但是其中有一件却让我爱不释手，着实领略了一下这个会议的与众不同之处。读者可以猜一猜一旁的插图中是个什么物件，我这里先不揭示谜底。

今天下午，我一到会场，大厅里一排排整齐的桌子上放着许多刻成一个个名片大小方格的卡纸。有些已经被裁成了一张张小卡片。每张小卡片上印有一串跟XML 或标识语言有关的关键字或符号，每张小卡片有一个号码，不同号码对应不同的字符串。我实在搞不清楚这些卡片除了收集来做纪念品外还有什么用处。之后才发现，那些与会的业界专家其实也会在听讲演的时候开小差，拿这些卡纸做起手工来。

Balisage 2009标识技术会议（四）

第二天（8/12/2009），下午

关键词：管道，流处理，XSLT 2.1，推与挽模型（Push and Pull Model）

在我的书架上有两本非常醒目的红色封面参考书，XSLT 2.0[1]和XPath 2.0[2]，这两本书的作者Michael Kay的讲演内容就是今天下午我想着重向大家介绍的。

会议安排了Michael连续两个主题讲演。第一个是关于“基于管道的XML处理”（Pipeline based XML processing）[3]，第二个是“制定中的XSLT 2.1标准的流处理功能”。基于管道的XML处理所指的是在对XML的处理过程中需要经过一系列的步骤，而这些步骤实际上可以通过管道（pipeline）采用流的方式处理，当然前提是这个处理的每个步骤都需要支持“流”（streamability，这个英文单词是XSLT标准制定工作组自创的）。而所谓基于“流”的处理是指一个相对内存来说巨大的XML文件可以被分割成比较小的单元进行顺序处理。而这样的单元可以是每一个SAX [4]的消息，例如startElement和EndElement，或者是一个XML的部分，比如一个节点（Node）和原子化的量值（Atomic Value）。

而对于XML的处理来说，一般只有两种方式：组构和析构（compose and decompose）。每个步骤则采用“推”或“挽”的方式对XML组构或析构。在将这些步骤连接起来的时候由于它们各自的极化方式不一样（“推”或“挽”）或对XML的单元访问方式不一样（顺序，乱序，或在一个子树中乱序，子树与子树间顺序），要么需要一个控制器（controller）将“推”模型和“挽”模型连接起来，要么需要将XML的子树或全树缓存在内存中，结果往往造成整个处理流程的效率降低。Michael举了一个他自己的XQuery处理器例子，由于使用控制器和两个线程将“推”和“挽”两个步骤联系起来，结果比起一个单一“推”或单一“挽”的处理流程效率降低了差不多45%。会后有人提问有关在多核的系统中，是否这样的架构会体现出优势，Michael表示肯定。另外，他介绍了一个非常有用但被人淡忘的概念[5]，其实所谓的“推”或“挽”模型是可以相互转换的，在多线程的代价比较大的环境里，使用“协同程序”（co-routine）的方法可以在单一线程的条件下将“挽”模型转变为“推”模型，反之亦然。

XSLT 2.1的流处理功能是Michael应邀添加的新讲座，类似在音乐会里的加演节目。作为XSLT标准的编辑（editor），Michael对于这方面的内容当然非常熟悉。由于这篇博客的长度有限，我无法深入介绍XSLT 2.1的流处理功能，况且许多标准的细节还在起草阶段，这里就一些有趣或有争议的功能稍作解读：

1. xsl:stream语句的引入
   新标准引入xsl:stream语句，用户使用该语句表示希望在xsl:stream之内的转型采用“流”处理方式。有人在会后提出疑问，认为这个语句将使用或不使用“流”处理的决定权交给用户，而用户往往不清楚自己设计的XSLT程序是否真可以采用“流”处理。理想情况应该是用户使用现有的XSLT语句，而“聪明”的XSLT处理器能够通过静态分析找出可以进行“流”处理的局部转型或全面转型。这其实也是XSLT标准工作小组一直在争论的话题。
2. xsl:iterate系列语句的引入
   新标准引入xsl:iterate语句，它同xsl:for-reach语句有一样的语法结构，但是用来在“流”处理中支持可以进行尾递归优化的迭代循环和变量传递。举个例子，比如我们希望计算一个财务报告中的累计总计（running total），用传统的XSLT 1.0的xsl:for-each 将会效率特别低，堆栈内存使用为O(n)，而即使是支持尾递归优化的XSLT 1.0处理器也需要大约O(N^2)的时间（O(1+2+…+N) = O(N(N+1)/2)）。而采用xsl:iterate语句的“流”处理可以将堆栈内存减少至O(1)，时间减少至O(N)。写出的XSLT语句类似这样：
   <xsl:stream href="accounts_10gb.xml">
   <xsl:iterate select="transaction">
   <xsl:param name="running-total" select="0"/>
   <running_total><xsl:value-of select="$running_total"/></running_total>
   <xsl:next-iteration>
         <xsl:with-param name="running-total"
             select="$running-total + total"/>
         </xsl:next-iteration>
   </xsl:iterate>
   </xsl:stream>

XSLT 2.1还引入了xsl:mode语句，它同xsl:template的“mode”属性一起用来标识某个XSL的模板是否适用于“流”处理；引入了xsl:merge语句支持多个XML文件的相互融合，这里就不一一细数了。希望了解更多XSLT最新情况的读者可以关注一下XSL标准的官方网站[6]。

1. http://www.amazon.com/XSLT-2-0-Programmers-Reference-Programmer/dp/0764569090 
2. http://www.amazon.com/XPath-2-0-Programmers-Reference-Programmer/dp/0764569104
3. Kay, Michael. “You Pull, I’ll Push: on the Polarity of Pipelines.” Presented at Balisage: The Markup Conference 2009, Montréal, Canada, August 11 - 14, 2009. In Proceedings of Balisage: The Markup Conference 2009. Balisage Series on Markup Technologies, vol. 3 (2009). doi:10.4242/BalisageVol3.Kay01. (http://www.balisage.net/Proceedings/vol3/html/Kay01/BalisageVol3-Kay01.html) 
4. http://en.wikipedia.org/wiki/Simple_API_for_XML
5. http://en.wikipedia.org/wiki/Coroutine
6. http://www.w3.org/Style/XSL/

Balisage 2009标识技术会议（三）

第一天（8/11/2009），中午

关键词：赤脚大仙，XML，命名空间（Namespace）

“大家都能认出Liam Quin，因为他赤着脚。”会议主持人这样介绍上午最后一个上台的演讲者。

我是几年前在德国海德堡的W3C印刷研讨会[1]上第一次认识Liam的，如果没有记错的话，当时他也光着脚走来走去，可见他多么会为他自己的私人技术咨询公司（Barefoot Computing）做广告（笑话而已）。之后我们只见过一次，而大部分时间就在每周一次的W3C XSL-FO工作组的例行电话会议上讨论交流。

Liam自从2001年起就全职为W3C工作[2]，参加包括XML和XSL在内的很多技术标准的制定，我低头读了一下他讲座的标题“自动XML命名空间”（Automatic XML Namespaces）[3]，不由暗地思量这又是什么新的idea呢？因为一直以来，业界对XML的命名空间就颇存争议，觉得它的本意是好的，但是现实状况表明对XML的使用者和对XML应用程序的开发者来讲，命名空间的使用和实现过于复杂。Liam在开始一段的演讲中也谈及在一个XML文件中使用多个命名空间的几个主要的困难：

1. 需要记住一些冗长的URI[4]，用户往往在拷贝、粘贴或是手工输入时发生错误，导致命名空间无法正确识别。
2. 需要每个XML的使用者记住哪个XML的元素（Element）或属性（Attribute）属于哪个地址空间。但其实这样的记忆往往不必要。
3. 在XSLT和XQuery的XPath处理中，花费太多时间来进行地址空间的比对，不够有效。

针对这些问题，Liam提出好的解决方案应具备以下几个条件：

1. 无偿提供，解决方案应该是免费的
2. 无偿实现，解决方案没有专利的束缚
3. 使复杂的生活变简单（Makes life simpler）
4. 易于开发者实现
5. 与当前的万维网标准兼容
6. 给XML的从业人员带来明显的益处

在考量了几个现有解决方案的优缺点以后，Liam最后提出了他自己的方案，即使用一个命名空间的文件来唯一标识一个元素或属性的命名空间。需要了解更对内容的读者可以在下面第三个参考文档链接中找到详细的说明。

这样的设计的确解决了现存的问题，但是我还是存有疑问：第一、这个设计和XML Schema[5]有没有重复？第二、这会不会造成一些注明命名空间的网上资源文件被过于频繁地索取，从而造成服务器的过载？有机会我会问Liam这两个问题。

网络参考文档：

1. http://www.w3c.de/Events/2006/PrintSymposium_en.html
2. http://www.holoweb.net/~liam/cv/
3. Quin, Liam R. E. “Automatic XML Namespaces.” Presented at Balisage: The Markup Conference 2009, Montréal, Canada, August 11 - 14, 2009. In Proceedings of Balisage: The Markup Conference 2009. Balisage Series on Markup Technologies, vol. 3 (2009). doi:10.4242/BalisageVol3.Quin01. (http://www.balisage.net/Proceedings/vol3/print/Quin01/BalisageVol3-Quin01.html)
4. http://labs.apache.org/webarch/uri/rfc/rfc3986.html
5. http://www.w3.org/XML/Schema

Balisage 2009标识技术会议（二）

第一天（8/11/2009），上午

关键词：标准，误区，项目管理，非目标（non-goal）

自美国西海岸飞行大约六个小时，我的班机终于降落在蒙特利尔机场，加拿大海关的工作人员和蔼可亲，我很快通关出机场，坐上出租去市中心的Best Western Europa酒店，那也是Balisage 2009会议所在地，据介绍这个旅店已经有八十多年的历史。会场设在这个小巧而精致的酒店的M层（就是位于一层和二层中间的Middle层）。到达时已近午夜，所以我没有多逛，径直回房休息，就等第二天会议开幕。

OK，闲话少叙，马上进入正题。会议组织者在第一天上午安排了三个报告，我觉得一个比一个精彩。

首先上台的是一位中年女学者，Ms. Tommie Usdin，演讲的题目是“被认为有害的标准”（Standards considered harmful）[1]。

有意思是她一上台就开始“抱怨”，究竟抱怨什么呢？她说，标准太多，泛滥成灾，有时候甚至变得有害了。她解释说，在项目的实施中采纳业界标准并不一定有助于项目的真正目的。项目的实施者必须注意最基本的要素：

1. 项目的决定性人物（Stake holder）
2. 是谁在关心什么（Who care what）
3. 项目的目标和项目的非目标（Project goal and project non-goal）
4. 项目目标的重要性顺序（Prioritize project goal）

Tommie着重说了第三点，特别提醒注意项目的非目标。一个项目必须使用有限的资源在有限的时间实现项目中最重要的目标，所以过度遵照一些冗长且对项目的目标无实际意义的标准，只会对项目的实施起反作用。Tommie举了个有趣的例子，一个年轻的人类学家到了一个偏僻村庄的破旧不堪的图书馆，找到一大堆有助于他新的论文的记录当地土著居民生活的日记。人类学家担心这些极有价值的文献会随这个图书馆和村庄一起消失，但他却无法说服管理员借出这些日记，所以想用计算机和标识语言数字化这些珍贵的文字，项目的目标是他自己可以查询就OK。一开始这个学者使用HTML，因为HTML最简单，看完一本薄薄的（六十四页）HTML书就可以上手，所以招几个大学生打工就可以完成项目。之后听人介绍采用了XML，又听人说要用业界统一的文档XML标准。突然一本六十四页的参考书变成了六十四本厚厚的参考书。而本来使用一些简单的PERL[2]就可以做到的HTML处理器，变成要使用“艰深”的XSLT。这个学者最终未能完成他的项目。

Tommie的讲座发人深省，作为一个实施软件项目的工程师，她所谈及的话题令我不由得去审视我所曾经和正在做的项目是否有的也不经意间陷入了盲从标准的误区。

网络参考文献：

1. Usdin, B. Tommie. “Standards considered harmful.” Presented at Balisage: The Markup Conference 2009, Montréal, Canada, August 11 - 14, 2009. In Proceedings of Balisage: The Markup Conference 2009. Balisage Series on Markup Technologies, vol. 3 (2009). doi:10.4242/BalisageVol3.Usdin01.
2. Practical Extraction and Report Language, http://en.wikipedia.org/wiki/Perl

Balisage 2009标识技术会议（一）

关键词：Balisage Conference 2009 加拿大 蒙特利尔 XML

自一九九七年开始，八月的加拿大蒙特利尔一直是专业标识技术人员聚会的时间和地方[1]。今年有幸参加这个会议的我在以后几天时间里将为对XML（eXtensible Markup Language 可扩展标识语言）和其相关知识感兴趣的博客读者介绍我在蒙特利尔的所见所闻。希望大家喜欢我的系列报道，并对文章的内容多提宝贵意见。这里我首先谢谢各位的热心参与，并给心急的读者简单介绍一下“Balisage”的背景知识。

“Balisage”是蒙特利尔当地对“标识”（或英文单词“Markup”）的称谓。根据维基百科[2]的叙述，这个词缘自ISO（国际标准组织）在法语版SGML（Standard Generalized Markup Language，XML的前身）[3]中对标识的称呼。而Balisage 会议是一个标识技术的从业人员相互切磋（peer-reviewed）的盛会，它旨在提供标志技术的研究人员和开发人员一个平台将这个领域的发展潜力推向极致。这个会议讨论的话题都是围绕着标识语言的不同应用，比如怎样创建标识；怎样用标识提供含义；怎样分层和重复；怎样建模，分类，转型；怎样查询，查找和获取标识信息；怎样表示和访问；使计算机系统让标识语言“跳舞”（在更小的空间里让标识发挥更大的作用）。简而言之，使用标志改变这个世界和万维网。

“Balisage”同时也是一个XML和XSL（eXtesible Stylesheet Language）[4]的会议。同时它也包括了XSD[5]、XQuery[6]、RDF[7]、UBL[8]、SGML、LMNL[9]、XSL-FO[10]、XTM[11]、SVG[12]、MathML[13]、OWL[14]、TexMECS[15]和RNG[16]等和其他已经或尚未和这些缩写挂起钩来的技术。

让我们来看一下将在这次会议上做技术讲演人员的名单[17]，其中包括了一些在XML业界耳熟能详的名字，比如Michael Kay、Liam Qiun、C. M. Sperberg-McQueen和Norman Walsh。想必你已经迫不及待等着和我一起去八月的蒙特利尔了。OK, Buckle up, and stay tuned。

以上由微软（中国）研发集团SQL事业部XML项目组的蒋欣采编提供。

网络参考文档：

1. http://www.balisage.net
2. http://en.wikipedia.org/wiki/Balisage
3. http://www.w3.org/MarkUp/SGML/
4. http://www.w3.org/Style/XSL/
5. http://www.w3.org/XML/Schema
6. http://www.w3.org/TR/xquery/
7. http://www.w3.org/RDF/
8. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl
9. http://www.lmnl.net/
10. http://www.w3.org/TR/xsl/
11. http://www.topicmaps.org/xtm/
12. http://www.w3.org/Graphics/SVG/
13. http://www.w3.org/Math/
14. http://www.w3.org/TR/owl-xmlsyntax/
15. http://decentius.aksis.uib.no/mlcd/2003/Papers/texmecs.html
16. http://relaxng.org/
17. http://www.balisage.net/2009/Program.html

微软SQL Server中文论坛

微软SQL Server中文论坛是一个由微软官方主办的论坛，在今年一月份重新改版后，以更友好的界面，更灵活的功能出现在大家面前。SQL Server中文论坛的管理团队包括十几名优秀的微软最有价值专家（MVP），以及微软全球技术支持中心的工程师，每天都有各种SQL Server的问题在上面提问和得到解答。更为重要的，这个论坛得到了微软中国SQL Server产品组的大力支持。SQL Server产品组有七十几位工程师，每个月都会活跃在论坛上，参与讨论和回答问题。通过SQL Server的中文论坛，您可以深入学习、讨论和交流各种SQL Server技术，从而让你可以安全、高效、稳定的使用SQL Server，成为微软技术领域的专家。微软的目标是把这个论坛是建成中国国内最大的SQL Server的中文论坛，从而提供给中国的SQL Server用户的最好的讨论交流社区。论坛链接：http://social.microsoft.com/Forums/zh-CN/sqlserverzhchs/threads。

ODBC Rocks！

在发布了19年之后，ODBC已经成为软件工业的基石之一。本文将为您介绍为什么ODBC会扮演如此重要的角色，微软SQL Server和ODBC的关系，还会讨论未来ODBC的发展方向。

作为一个被广泛使用、跨平台、跨数据库的数据访问技术，ODBC已经取得了巨大的成功。ODBC可能是ISO/IEC 9075-3：2003 SQL调用级接口（Call Level Interface，全部SQL标准的第三部分）最广为人知的实现。ODBC包含在Windows、MacOS和所有主要的Linux版本中，也包含在很多Unix版本中，例如AIX、HP-UX、Solaris和FreeBSD。甚至PDA和Smartphone手机都包含ODBC！

虽然人们总是把ODBC作为C和C++程序应用接口（API），ODBC也可以在其他的编程语言环境下使用。举例来说，很多COBOL程序用ODBC来做数据访问，动态语言如PHP、Perl、Python、Ruby，还有一些快速应用开发工具（RAD）如微软Access也使用ODBC。

尽管ODBC多用于关系数据库的连接，其他数据源也很少能离得开ODBC驱动：文本文件、Excel表格，dBase、Paradox、C-ISAM、Btrieve还有VSAM等索引顺序存取方法（ISAM）数据源，你能想到的基本上都有相应的ODBC驱动程序。对于没有ODBC驱动的数据源，你很容易就能找到一个第三方的ODBC驱动，或者用驱动开发工具包来填补这个空缺。总而言之，没有一个关系数据库离得开ODBC驱动。

ODBC广泛用于企业级应用开发，大多数主流独立软件供应商（ISV）都提供对其的支持。ERP、CRM、SCM和微软office，都通过ODBC来做查询、分析、报表生成，还有ETL（数据抽取、转换和加载）。

是什么让ODBC在不同的软件业细分市场都如此流行呢？为什么ODBC在可以预见的未来还会继续流行下去？

对于数据源（Data Source）的拥有者，ODBC是必须的。ODBC同ADO.NET、JDBC和OLE DB一样， 作为工业标准的应用编程接口（API），使数据源可以被程序开发者、被第三方工具和程序包访问。为所有这些数据访问技术开发相对应的驱动需要花费大量的时间、财力和物力。如果资源有限或者时间紧迫，最好的策略是什么呢？应该是先实现ODBC驱动，之后再考虑实现别的驱动。为什么？第一，其它所有的API都可以桥接到ODBC上，一旦有了ODBC驱动，你就可以通过其它任何API来访问数据库。第二，即使不考虑桥接，ODBC可以给数据源用户提供最广泛的第三方软件支持，因为ODBC是最早最成熟的数据访问技术，累计了大量的工具和应用。

ODBC能，而且通常是在专有的（proprietary）API之上实现的。在ODBC发展的早期，很多人认为这是第一代ODBC驱动的缺点。但是后来的研究表明，把ODBC建立在专有的Native （Native）API上对性能的影响微乎其微。在某些情况下，如果ODBC驱动引入策略去克服底层Native API的薄弱环节，ODBC甚至比专有API更高效。对于一些数据库来讲，包括微软SQL Server，ODBC都能满足作为专有Native API的角色。

企业IT和企业开发人员生活在一个非常多变的环境中，他们必须支持多语言、多操作系统，还有多种数据源。他们的压力一方面来自整合和标准化应用平台，另一方面来自改进现有程序，重整业务流程，提高信息整合，还有引入商业智能（Business Intelligence）。如何应付这些压力呢？

在数据集成和数据整合的情景下，从ETL到BI，ODBC的普及是很有价值的，它能将数据从数据包和客户应用中提取出来。

.Net平台现在被广泛应用于新的开发中。但在许多情况下，从时间、业务风险、整体成本因素上考量，代码重用和修改现有程序更容易被接受。在这方面，ODBC能做的很多。通常来说，应用程序开发人员通过在Visual Studio里使用/CLR编译选项，可以很容易的重新编译现有的代码，使得它能在.Net应用里被重用。这极大地简化了现有的C++和ODBC的业务逻辑与一个现代化的用户界面之间的结合，用户可以快速开发.NET平台应用。ODBC为各种不同的数据源和操作系统提供了一个通用的API，可以同步的访问多个数据源。这些是信息整合，聚集和集成的基本要求，无论是在native应用中，还是通过.Net平台的ODBC数据提供程序（Data Provider for ODBC）。

除了直接重用现有的业务逻辑，ODBC也是替换其他专有的API的一个重要候选。比如在做数据库迁移的时候，把使用如DB – Library，CT-Library或者OCI的应用程序迁移到ODBC上，要比完全用.Net重写来得高效和低成本，因为ODBC同其他Native API是很相似的 。

ISV通常会支持多种不同的数据库，从而增加市场和客户吸引力。ODBC提供了多种办法来满足这一要求。总之，ODBC提供了一个通用的API，可以处理多个数据源，而且如上所述，有广泛且可用的驱动程序。当然，不同的数据源也有不同的特性，这反映在一系列不同的ODBC驱动程序上。

解决这一问题的最简单的办法是使用最严格的行为模式和SQL方言子集（SQL dialect subset）。ODBC提供转义序列（escape sequences）来解决SQL方言之间的细小分歧。如果这还不够，下一步应用程序可以通过ODBC查询驱动程序的特性、数据库的特性，动态的来处理。应用程序也可以判断出实际的驱动程序和数据库，在通用性和驱动程序特性之间权衡，从而满足严格的功能和性能要求。而且，ODBC对应用程序提交到数据源的SQL语句没有任何限制，因此不会影响SQL方言的丰富性。

一些ISV使用内部的数据抽象层来实现功能——用不同的API访问不同的数据库。即使是在这种情况下，ODBC也可以胜任。对于一些数据库，特别是微软SQL Server，ODBC是性能最好的API。

系统集成商和增值经销商（VAR，Value Added Reseller）从两方面受益于ODBC。他们可以确信，无论什么操作平台和其他基础设施，所有数据源都会有ODBC支持，从而不需要开发一个专门的工具。其次，相比于技能相对狭窄的技术人员，熟悉ODBC的技术人员可以满足更广泛的客户需求。

ODBC和微软的SQL Server

对于软件行业的方方面面来说，ODBC有广泛而持久的吸引力。虽然有时候低调了些，ODBC仍然是Microsoft数据平台一个重要的组成部分。现在，让我们讨论一下关于ODBC和Microsoft SQL Server之间关系的更多细节。

最早的时候， DB-Library是SQL Server唯一的客户端应用程序API。后来，SQL Server　API家族又添加了ODBC，然后是OLE DB，以及最近的ADO.NET。DB-Library由于技术上的限制已经不推荐使用，只是为旧的应用程序提供向后兼容性。

“在OLE DB发布后，微软的专家们相信它将取代ODBC 。现在情况已经彻底改变了... ”

在OLE DB发布的时候， SQL Server团队相信OLE DB将取代ODBC 。实际情况已经完全改变了，ODBC的未来前景十分看好。ODBC的应用比OLE DB广泛的多，和OLE DB比，ODBC更适合于一些关键的应用，我们将在本文后面一些讨论这个问题。

OLE DB和ODBC都是用于SQL Server的Native API，它们直接映射API调用到SQL Server的网络协议——TDS（Tabular Data Stream，一种表格式数据流的协议) 。ODBC是TDS之上一个非常薄的封装，在网络数据包缓冲和应用程序之间，没有额外的中间缓冲层。因此，它具有优良的性能和很好的负载能力。

支持Microsoft SQL Server的ODBC和OLE DB驱动包含于WDAC （Windows数据访问组件）中。WDAC就是原来的MDAC （ Microsoft数据访问组件）。另外，ODBC和OLE DB驱动也包含在Microsoft SQL Server Native Client（SQL Server 本地客户端）中，用来支持微软SQL Server 2005，2008和更高版本。WDAC中的ODBC和OLE DB驱动已经不推荐新的应用使用，只是为旧的应用程序提供向后兼容性。想要有更高的性能，更好的稳定性，或使用SQL Server新特性的应用程序需要使用Microsoft SQL Server Native Client。这些新特性包括快照隔离，数据库镜像，查询通知和某些数据类型（如XML和VARCHAR （max））等。微软将继续在ADO.NET （通过SqlClient）、ODBC和OLE DB （通过SQL Server Native Client）和JDBC 中添加对SQL Server新特性的支持。

ODBC未来的角色

我现在列举一些关键的应用，来说明ODBC将在SQL Server的未来中扮演的重要角色。一些SQL Server的组件内在地依赖于OLE DB，并反映在外部接口上。由于认识到ODBC的广泛普及，微软已经决定继续支持Microsoft OLE DB Provider for ODBC, 包括Windows Server 2003、 Windows Vista、Windows Server 2008、Windows 7和Windows Server 2008 R2的32位和64位版本。 这保证了当用户认为ODBC是最好选择的时候，可以很容易的找到相关组件。

动态语言，如PHP、Perl、Python和Ruby，应用十分广泛。.NET平台支持其中一些动态语言，其他一些平台上也同样支持多种动态语言。虽然不同的库有着不同的质量和性能，几乎所有这些语言都可以通过ODBC访问微软SQL Server。微软将不断评估是否有必要对这些库进行基于SQL Server的优化。说到这里，微软已经发布了一个基于Microsoft SQL Server Native Client ODBC Driver的PHP扩展库。

应用迁移和服务器整合作为一种降低运营和许可费用的手段，越来越受到业界的重视。 SQL Server卓越的总拥有成本（TCO）在这一点上很有吸引力。正如上文所讲，ODBC在数据整合和应用迁移上扮演了一个重要的角色。微软SQL Server迁移助手（Migration Assistant）是一个用来帮助客户迁移架构（schema）和数据库本身到Microsoft SQL Server的工具。微软也致力于开发一些文档和工具，以帮助用户将应用程序迁移到ODBC和Transact SQL上。

非Windows客户端和mid-tier服务器在上述情况之下又增加一个额外的层面。目前第三方ODBC驱动程序已经基本满足客户的需求，但微软仍会不断评估提供自有驱动的必要性，以确保客户获得最好的体验。

最后，微软希望现有的客户将来能获得更大的成功。这涉及到将他们现有的代码通过应用程序更新和代码重用来获得最大的回报。如果现有的业务逻辑能继续满足业务需求,那么代码重用比重写一遍更有意义。例如，不管采用何种应用架构，金融应用程序都使用相同的算法来做预测分析。又例如，分析批处理和call center程序，并将其重新部署成SOA（面向服务体系结构）模式，从而使其适用于B2B和无人售货等情形，也很有商业上的意义。当然，.NET在开发新的通讯、用户界面程序方面很有竞争力，但是，基于C++和ODBC的业务逻辑和数据访问程序可以很容易的被重用，而且只需要很小的改动和很低的成本。Visual Studio和C + + CLI提供很好的重用和互用性，而且以后还会通过提供完善的重构（re-factoring）工具来继续拓展这些能力。

未来15年内，ODBC蕴藏怎样的机遇和挑战呢？

有两个重要的且相关联的问题。第一，作为最重要的native API，如何保证ODBC继续更新从而适应SQL Server的新功能？第二，ODBC如何继续扮演作为工业标准的跨平台、跨数据库API的角色？

ODBC驱动程序可以在核心ODBC规范的基础上添加驱动特有的扩展， 正是有了这种可扩展性，Microsoft SQL Server Native Client添加了对Microsoft SQL Server新特性的支持。其他驱动也可以添加自己的扩展。下面的两个例子演示了Microsoft SQL Server Native Client如何支持SQL Server的新特性。

SQL Server 2008增加了额外的日期/时间数据类型，以补充现有的datetime和smalldatetime类型：date和datetime2对应于现有的SQL_TYPE_DATE和SQL_TYPE_TIMESTAMP类型；time（具有7位小数秒精度）和datetimeoffset（datetime2加上时区信息）没有相对应的ODBC数据类型，所以Microsoft SQL Server Native Client添加了新的数据类型：SQL_SS_TIME2和SQL_SS_DATETIMEOFFSET。

SQL Server中，table-valued参数（TVP）是用于T - SQL语句或存储过程中、可以由多个行和列组成的参数。例如，考虑以下声明：

Insert into OrderItems (OrdID, ProdCode, Qty)
Select ?, ProdCode, Qty from ?

第一个参数是新插入的OrdID主键，但二个参数是一个TVP参数，它包含了每个OrdID相对应的列，TVP实现了在一个SQL语句中，用一个参数，来插入多行。TVP通过减少客户端和服务器端的交互以及在TDS和关系数据库引擎上的优化，有效的改进了性能。通过加强封装性，一个单一的存储过程可以执行完整的事务处理。存储过程通常限制参数为“矩阵式”，TVP弱化了这种限制，极大的提高了代码清晰度。看下面的例子：

create type OrdItemType as table(
ProdCode integer, Qty integer)

create procedure OrderEntry
(
      @CustCode varchar(5),
      @Items OrdItemType READONLY,
      @OrdNo integer output,
      @OrdDate datetime output)
as
      set @OrdDate = GETDATE();
      insert into Orders (OrdDate, CustCode)
          values (@OrdDate, @CustCode);
      select @OrdNo = SCOPE_IDENTITY();
      insert into TVPItem (OrdNo, ProdCode, Qty)
          select @OrdNo, ProdCode, Qty from @Items
)

如果没有TVP，你需要用两个存储过程：每个数据表对应一个存储过程。

因为我们可以把TVP和传统的单值参数在一个SQL语句中混用，绑定ODBC参数时，SQL Server Native Client必须提供一种方法来处理这种嵌套表。具体是这样的：首先把TVP绑定成SQL_SS_TABLE——一个代表嵌套表的新SQL类型；然后通过SQLSetStmtAttr将SQL_SOPT_SS_PARAM_FOCUS 设置为TVP参数的序号，这表明接下来的SQLBindParameter是用来绑定该TVP中各列的（而不是“顶层“的参数）。一开始我们认为TVP这个ODBC扩展过于复杂和困难，通过上述实现，这变得十分简单，代码紧凑而且清晰可读。SQL Server中完整的TVP实现建立在已有的ODBC规范——array binding和“data at execution“之上。这允许TVP中的各行数据可以在运行时提供，这些数据既可以是内存中的数组，也可以是分批地传到服务器的一行或者多行数据。

到目前为止，一切都很顺利。 SQL Server Native Client的实践表明，一个ODBC驱动程序可以添加一些重要功能，而无需更改ODBC规范。但是如果一个SQL Server新的功能超出ODBC的扩展能力怎么办？ODBC的结构是否会在新的SQL Server应用下显得捉襟见肘？这些都是棘手的问题，其中可能的解决办法包括：更新ODBC核心规范，或者将SQL Server Native Client变成一个Native API ，可以从ODBC驱动程序管理器（ODBC Driver Manager）上剥离，从而不再受到ODBC规范的限制。这两个办法都影响深远。

改变ODBC规范并非完全无风险。ODBC最大的优点之一是它的稳定性。改变ODBC规范和现有的驱动程序，可能会让应用程序产生新的不确定的行为。如果从当前的规范中分离出来，能满足某些应用但是可能会破坏其它更多的应用。对于ODBC和SQL Server Native Client来说，有没有一个乌托邦式的“第三种选择”呢？IBM　DB2的调用级接口（Call Level Interface）可以运行在两种模式下：作为ODBC 驱动（通过驱动管理器Driver Manager）或者独立的call level interface. 对于SQL Server Native Client和ODBC来说，这可能是一个渐进的过程。另一个选择是，让现有的和将来的ODBC版本并存。目前，ODBC驱动程序管理器已经做到ODBC2和ODBC3的并存。

有没有其他组织对扩展ODBC现有规范感兴趣呢？在这方面，微软要鼓励有关方之间的讨论，评估某些广泛共识的可行性。而某些社区形式为基础的创新，比起ISO或ANSI，可能反应更快速，投入更广泛。不过有一点可以肯定，不管发生什么，没有什么可以破坏ODBC丰富的遗产和其持久的产业价值。

微软把实体数据模型（Entity Data Model，EDM）视为一个改变整个软件产业的革命性技术，在现有的ADO.NET实体框架（Entity Framework）上得到了很好的应用。想象一下，如果把ODBC和EDM结合起来，将是多么的激动人心。ODBC可以来支持实体SQL（Entity SQL）上的查询，返回有多行和嵌套实体值的实体结果。TVP中处理非矩阵性数据的经验表明在SQL Server Native Client上对EDM做驱动层面上的扩展是完全可行的。另外，除了SQL Server，微软正在引入越来越多的数据源来支持EDM，其他的一些关系数据库产品也可以通过ADO.NET Entity Framework来支持EDM。所以为什么我们不能直接在ODBC的核心规范层面上来支持EDM呢？答案在一定程度上取决于ODBC应用程序在哪个层面上使用EDM：EDM和关系型访问分别在不同的驱动上？同一个驱动的不同连接上？还是在同一个连接上？是渐进的将EDM应用到现有的代码里，还是只在新的代码里使用？这是另一个微软希望能听到有关各方讨论的领域。

ODBC已经走过了漫长的道路，希望这篇文章能给你带来对ODBC一些新的理解：ODBC有哪些已经存在了很久而且还将一直为你所用的功能；它今后会如何发展；微软保证将长期提供对ODBC的改进和支持。

如果你想就本文中所提及的内容做进一步的讨论，请发送电子邮件至odbcfut@microsoft.com 。

你可以在以下链接找到更多关于ODBC的信息：

1. ODBC Rocks！英文原文 
   

   http://www.code-magazine.com/Article.aspx?quickid=0712172

2. Mike Pizzo：微软数据访问APIs 的历史
   http://blogs.msdn.com/data/archive/2006/12/05/data-access-api-of-the-day-part-i.aspx
3. Wikipedia ODBC
   http://en.wikipedia.org/wiki/Open_Database_Connectivity
4. Ken North：SQL and ODBC in integration frameworks for Business Integration Journal
   http://www.sqlsummit.com/PDF/BIJ_North_Nov2004.pdf
5. Ken North：ODBC portal
   http://www.sqlsummit.com/ODBCPORT.HTM 
6. ODBC MSDN文档
   http://msdn2.microsoft.com/en-us/library/ms710252.aspx 
7. Microsoft SQL Server Native Client MSDN文档
   http://msdn2.microsoft.com/en-us/data/aa937705.aspx 
8. SQL Native Client 博客
   http://blogs.msdn.com/sqlnativeclient/
9. MSDN DATA 博客
   http://blogs.msdn.com/data/
10. SQL Server Data Access论坛
    http://social.msdn.microsoft.com/forums/en-us/sqldataaccess
11. SQL Server 中文论坛
    http://social.msdn.microsoft.com/forums/zh-CN/sqlserverzhchs/

软件测试工程师
于凯

Microsoft SQL Server 2008故障转移群集在Hyper-V虚拟机上的多种组建方式

Hyper-V虚拟机给我们带来了诸多便利，比如应用程序整合、节能、节约成本、提高资源利用率等等。随着Hyper-V虚拟机的推广，用户的使用越来越普及。很多用户在Hyper-V虚拟机中用到了MS SQL Server。但是单独（standalone）的SQL Server 不能提供高可用性和灾难恢复的功能。在对可用性有较高要求的Hyper-V用户面前，故障转移群集（Failover cluster）是必然用到的功能。当虚拟的生产服务器宕机时，热备份中的虚拟的服务器可以很快投入工作中。 然而在虚拟机上搭建故障转移群集比在物理机上搭会有更多种组合。

本文中介绍各种搭建方式的优点和缺点。您可以在虚拟机上搭建SQL Server 故障转移群集以供学习与自娱。需要提醒的是，搭建需要满足如下前提条件：

Hyper-V要求的宿主机（host machine）必须是Windows 2008 x64 或 Windows2008 第二版 x64（差点忘了，用免费的securable软件可以检查你的宿主机CPU是否支持硬件虚拟化，2009年买的新机通常都是支持的）。虚拟机的操作系统可以是Windows 2003、Windows 2008、Windows 2008第二版（x64或x86）等不限。

熟悉Windows Cluster service的兄弟们都知道要搭建Cluster的机器必须拥有共享硬盘。Hyper-V还有个更严厉的要求：两个虚拟机搭cluster需要的共享硬盘必须是支持iSCSI的共享硬盘才行。可以是支持iSCSI的SAN或iSCSI的仿真软件（iSCSI Target和iSCSI Initiator）。 真实生产环境中的当然得买老贵的iSCSI SAN了。如果只是搭一个供自己欣赏或者搞个开发、测试环境的话当然是用仿真软件来仿真出几个共享硬盘省钱了，仿真软件可在网上搜索下载。有了仿真软件普通台式机就可以搭建，SCSI的物理设备可以统统不用。幸福吧？做过Cluster的老人们都还记得在Hyper-V出现之前，搭个故障转移群集有多麻烦，软件硬件都有特殊要求啊。

2节点的SQL Server故障转移群集是最常见的，更多节点的故障转移群集（最多16个）的搭建方式和2节点故障转移群集的搭建方式类似，所以在本博文中不讨论。

在Hyper-V虚拟环境中有很多种搭建故障转移群集的方式足有5、6种之多。哪种方式比较实用用户往往无所事从。本文中我们将分析虚拟环境中有很多种搭建故障转移群集的方式及其利弊，供各位IT兄弟们参考。为了描述清楚，各种搭建方式用A、B、C、D、E和F来编号。

方式A如下图

 
方式A 需要2台宿主机，两台宿主机的本地硬盘（例如E:）上各放着一个虚拟机的虚拟硬盘文件（.vhd），映射为虚拟机的操作系统C:。2个虚拟机在每个宿主机上分别启动，共同组建成一个SQL Server故障转移群集。可以看到2个虚拟机要用到iSCSI SAN了吧？ 那个就是共享盘。SQL Server跑在虚拟机Child1中，当Child1宕机的时候就会发生failover，共享盘Q:, R:就自动被第二台虚拟机Child2上的SQL Server抢到，第二台虚拟机上的SQL Server就开始工作了，如下图所示：

 
方式A是最容易想到的一种搭建方式。而且提供了高可用性的支持。如果有带冗余的网络和SAN, 可以用在生产环境中。（我可没说iSCSI仿真软件可以用在生产环境中啊，仿真软件感觉有点慢，而且没有冗余）

方式B如下图

 
方式A看起来有点费钱了，要2台物理机，想省物理机吗？那么试试方式B，您只要1台够了。既然每台宿主机可以同时跑多台虚拟机，我把2台组建SQL Server cluster的虚拟机跑在同一台宿主机上不就可以了? 如上图所示。如果你青睐iSCSI仿真软件，iSCSI SAN的钱也可以省掉，彻底的虚拟化了。你可以在唯一的宿主机上跑2个虚拟机的同时，宿主机还装了iSCSI Target可以模拟虚拟机所需要的共享盘。爽！

方式B的好处是，你可以把SQL Server cluster整个放到自己的笔记本中去。要演示SQL Server cluster怎么工作只要带着1个笔记本就够了（俺的笔记本是支持Hyper-V的 J，检查一下你自己的）。Cluster的2个节点及共享硬盘都是虚拟的。但是注意：这种方式省了不少钱也省了不少性能，而且不提供高可用性的支持，如果笔记本完了，覆巢之下焉有完卵， 你的SQL Server应用也无法健壮的挺起腰板啊。当然如果一个虚拟机去了，还是可以故障转移到另一个虚拟机的, 看下图。但如果宿主机坏掉会造成单点失败（Single point of failure）。小心啊！

方式C 如下图

方式C是一种奇特的设计，宿主机和虚拟机之间搭SQL Server cluster。当然这需要两台宿主机。

这种虚拟机和物理机之间的cluster有什么用？据我看起来可以作为一种临时的解决方案。例如某客户要把当前的2台物理机搭建的cluster改为2台虚拟机搭建的cluster，为了不打断正运行在物理机上的SQL Server生产环境（Active node）， 他可以先改造完Passive node再说。先把这台待命的物理机（Passive node）改造成虚拟机，然后做个failover, 让改造完的虚拟机（这时候变成了Active node）继续干活，再把另一台物理机（现在是Passive node）改造成虚拟机。这样在业务不中断的情况下完成了从物理机cluster到虚拟机cluster的升级。这样看来方式C也不失为一种升级时临时用用的方案了。升级到虚拟机时要用到SQL Server 2008中往cluster中添加以及删除节点的功能。 方式C也提供了高可用性的支持，如果2个机器中的一个宕机，不管是物理机还是虚拟机，故障转移的功能还仍旧能起作用，看下图：

方式D如下图

Windows 2008第二版的快要推出了，很多用户都迫不及待想用用其中的新版Hyper-V提供的一个很酷的功能——live migration。利用这一功能，用户可以在几秒钟之内很容易地把虚拟机从一台物理机挪到另外一台物理机上，而且虚拟机上运行的程序不中断。如果把live migration和failover cluster结合起来，就组成了方式D中更加健壮的cluster搭建方式。

方式D需要在2台物理机上建2台虚拟机。注意这种方式需要宿主机和虚拟机2个不同层次上搭建cluster。首先在2台物理机之间搭建Hyper-V 的cluster来支持live migration。虚拟机的虚拟硬盘文件（.vhd）放在物理机cluster的共享盘上（虚拟机的OS放在上面)， 这样在做live migration的时候才可以把虚拟机在两台物理机之间变魔术似得搬来挪去。

然后在2个虚拟机之间搭建SQL Server failover cluster，但为了清楚起见，在虚拟机层次上所需要的共享硬盘在上图中没有画出来。这里有一篇手把手的搭建live migration的文档：http://technet.microsoft.com/en-us/library/dd446679(WS.10).aspx, 但其中不涉及怎样搭建SQL Server cluster。

这种搭建无疑是最复杂的。但方式D提供了两种情况下的热备用：不可预料的宕机（Unplanned down time），例如硬件故障，以及可预料的宕机（Planned down-time），例如Windows打补丁。例如物理机2需要打Windows补丁，如果物理机2上的虚拟机是正运行着SQL Server的活动节点（Active node）， 你可以做live migration把这个虚拟机弄到物理机1上， 如下图所示。等物理机2打完补丁再同样挪回来。这样保证了你的SQL Server应用系统的高可用性。如果任何一个物理机或虚拟机宕机了（Unplanned down time，谁也无法预料什么时候发生），还可以依靠SQL Server failover cluster来保证你的SQL Server应用系统的可用性。好处多多啊。

方式E如下图

方式E需要2台物理机。其中1个虚拟机可以做live migration，另外一个虚拟机不做live migration。能做live migration的机器当然要放在物理机上事先建好的cluster中的共享盘上，就是和方式D中同样的做法。不做live migration的虚拟机放在物理机的本地硬盘上（D:\N1.VHD）。

这种配置没有太大的意义，实际上是方式A和方式D的混合。其中的一个虚拟机采用了方式A中的配置，另一个虚拟机采用了方式D中的配置。

方式E能提供高可用性。 如果物理机1需要打Windows补丁，可以把上面正在运行SQL Server应用的虚拟机（Active node）live migrate到物理机2上，如下图所示。打完Windows补丁再同样地挪回去。

如果物理机2需要打Windows补丁，而且上面的虚拟机中SQL Server是活动（Active node）的。因为它不支持live migration，那只能将SQL Server 转移到物理机1上的虚拟机VM2上去继续干活。当然Failover的过程比live migration的过程要慢。

方式F如下图

 
方式F是一种更怪异的搭建方式，需要3台物理机。只不过这种方式比较浪费硬件，从软件角度来说和方式C是类似的，是一种虚拟机和物理机混合构建的SQL Server cluster，只不过这里的虚拟机可以做live migration。虚拟机VM1和物理机3之间构建了SQL Server cluster。虚拟机VM1位于物理机1和物理机2之间构建的Hyper-V cluster中，所以可以在2个物理机1和2之间做live migration。Live migration的一个好处是负载均衡。在物理机1上面可能有别的应用突然占用了90%的CPU，这样运行着SQL Server 应用的VM1可以在不停机的情况下挪到CPU不忙的物理机2上继续运行。同样道理，如果物理机1需要安装Windows补丁，也可以利用live migration把所有的虚拟机负荷搬到物理机2上去而不影响SQL Server故障转移群集，如下图所示。这种要求在方式D中也能很好的满足。

总结

下面的表格中把几种组建方式做个对比，可以看的更清楚一些：

这几种方案中最有使用价值的是方式A和方式D。A是生产环境中最常用的配置。如果需要live migration的功能则可选用D。其次是B和C。方式B主要用于测试、开发以及演示的环境。但它没有高可用性，也就失去了应用到生产环境中的意义。C可作为从物理机的群集到虚拟机的群集临时的升级方案。

软件测试工程师
赵振宇

SQL Server 2008故障转移集群概述

故障转移集群（Failover Cluster）是实现SQL Server高可用性解决方案之一。一个集群通常由多台服务器组成，每台服务器称为一个节点。通过使用冗余节点来减少宕机时间，为客户关键业务的高可用性提供了有力的保障。与以前版本相比，SQL Server 2008故障转移集群做了很大改进，不但简化了安装和维护，而且提供了新功能减少系统维护时的宕机时间，比如循环升级、循环打补丁等。本文将简述一下SQL Server 2008故障转移集群的基本结构和原理。

SQL Server 2008支持本地集群，即所有节点都在同一个子网内，通常位于同一个物理地点；如果节点跨越不同区域，则必须把所有的节点都配置到同一个VLAN中，所以在上层的集群看起来还是同一个子网内。一个典型的故障转移集群的架构如图1所示。

 
首先要指出的是，SQL Server故障转移集群有两个核心层次，一个是Windows层，一个是SQL Server层。Windows故障转移集群是一个平台，提供了与应用无关的故障转移的基本功能，比如节点之间心跳检测、故障转移策略管理等。在其上可以构建很多故障转移集群的具体应用，而SQL Server故障转移集群正是其中之一（其他故障转移集群的应用还有很多，比如邮件服务器、文件服务器、打印服务器等）。因此，安装SQL Server故障转移集群前，必须要先把所用的节点加入到同一个Windows故障转移集群中。向现有的集群中增加新节点也是如此。SQL Server 2008故障转移集群推荐安装在Windows Server 2008上，因为该版操作系统大大简化了Windows故障转移集群的管理维护。

和独立的SQL Server一样，SQL Server的故障转移集群也支持多实例。每一个SQL Server故障转移集群的实例都有一个虚拟的网络名字，客户通过该名字访问集群数据库就和访问一台物理的数据库服务器一样。所以虽然集群内部有很多节点，但客户是感觉不到的。正常运行时，只有一个节点上的SQL Server实例进程在运行，此节点称为活动节点（Active Node），而所有其他节点则称为被动节点（Passive Node）。集群的虚拟网络名字总是映射到当前活动节点的IP上。

和独立的SQL Server不同的是，SQL Server故障转移集群的数据不能存储在本地磁盘上，而必须存储在共享的SAN（Storage Area Network）上。实际上SAN是在Windows故障转移集群中配置，然后分配给SQL Server故障转移集群的实例使用的（在安装时指定）。通常SAN总是被当前的活动节点独占使用的，从而避免了多节点同时访问可能造成的数据损坏。

故障转移有两种形式，一种是由管理员发起的，一般是在对当前活动节点进行系统维护之前先把整个集群转移到其他节点上；另一种是系统检测到故障时自动进行的故障转移。故障转移过程如图2所示。Windows故障转移集群会首先停止当前活动节点上的SQL Server实例进程，然后根据该实例的故障转移策略选择一个新的节点，最后在此新节点上启动SQL Server的实例进程，同时获得对SAN的独占访问权。这个节点就成为了新的活动节点，虚拟网络名字也随之映射到此新节点上，从而保证客户应用还能正常连接数据库。由于数据都是存储在共享的SAN上的，在故障转移过程中并不需要数据复制。宕机时间只发生在故障转移时短暂的瞬间，即旧的活动节点的实例进程被停止后，到新的活动节点的实例进程正常工作之前。当然，故障转移之前的客户连接都会被中断，所有未完成的事务都会被回滚，并且故障转移完成之后，客户端需要重新连接数据库。

那么在系统自动触发的故障转移中，系统是如何检测故障及采取措施呢？这就需要探讨一下故障的检测和转移策略。

故障的种类多种多样。如前所述，Windows故障转移集群为集群应用提供了底层服务，与之对应，一些底层的故障，比如网络故障、磁盘故障等，也是由它来检测的。而每个SQL Server集群实例自身的故障（比如拒绝客户端连接、无响应等）则是由一个为SQL Server定制的集群资源来检测的，称为“SQL Server资源”，其任务就是定期去查询数据库的状态。具体来说有两种查询：一个是“LooksAlive”，另一个是“IsAlive”。前者是一个轻量查询，缺省配置下每5秒钟检查一下SQL Server服务的状态，并不去连接数据库，所以对数据库的影响很小，查询次数也比较多；而后者是要连接到数据库中去执行一下SQL语句“SELECT @@SERVERNAME”判断是否能返回正确的结果，对数据库的影响较大，尤其是系统繁忙时，所以只在每60秒钟，或者“LooksAlive”查询失败时才会去执行一次。

故障发生时，默认的转移策略就已经能满足很多用户的需求了。当然，用户还可以随时根据自己的特殊需求，用Windows集群管理器（Failover Cluster Manager）对集群实例内的每个资源单独配置不同的策略。同时，同一集群实例内的资源之间会通过特定的依赖关系（如图3所示）而互相影响。如果出故障资源变成“失败”状态从而导致其上层资源的依赖关系不能成立，则该上层资源也会变成“失败”状态；如果要转移到新节点，则同实例内部的所有其他资源都会跟着转移。

集群内部的状态信息都会同时记载到集群日志和Windows事件浏览器中，所以一旦集群发生了异常，总可以通过研究这些信息了解系统状态变化的全过程。

您可以参考以下链接获得Windows和SQL Server故障转移集群更详细的信息：

• Windows Server 2008 Failover Clustering
  http://www.microsoft.com/Windowsserver2008/en/us/failover-clustering-main.aspx
• SQL Server 2008 Failover Clustering
  http://msdn.microsoft.com/en-us/library/ms189134.aspx

李凌伟
SQL Server引擎测试工程师

SQL HADR多个技术概览和比较

对于企业级用户和关键系统来说，最重要的要求之一就是系统的高度可用性和数据的安全性（High Availability and Disaster Recovery，HADR）。我们先来了解一下HADR的问题空间。HADR有两个目标和衡量方式：

• 保证系统可用
  目标恢复时间（Recovery Time Objective，RTO）：出了故障后把系统恢复正常工作状态所需要的时间。
• 保证数据安全
  目标恢复点（Recovery Point Objective，RPO）：系统数据能恢复到故障前的哪个时间点。换而言之，故障后你能容忍多少数据损失。

故障又主要有两大类别：

• 计划宕机时间
• 硬件升级
• 软件补丁（操作系统，应用程序），应用程序升级
• 维护操作
• 意外宕机时间
• 无法预料的故障
• 硬件故障，软件故障，电力中断，数据损坏
• 站点故障：火灾，地震，洪水
• 用户或应用程序错误
• 意外更改，不正确的数据操作

针对不同的可用性要求和故障类别，SQL Server提供多样的HADR技术来满足用户的需要。但怎样从中选择最合适的技术？下面是对SQL可用性技术和功能的一个概览：

• 意外宕机时间
• SAN/RAID
• 备份和恢复（Back Up and Restore）
• 日志传送（Log Shipping）
• 数据库镜像（Database Mirroring）
• 故障转移群集（Clustering）复制（Replication）
• 计划宕机时间
• 轮流升级和打补丁（Upgrade and Patching）
• 在线操作（Online Operations）
• 资源管理器（Resource Governor）
• 数据库快照（Database Snapshot）

这些技术都有自己的特点和要求，用户可根据自已需求，配置，和预算来选择，以满足HADR在目标恢复时间（RTO）和目标恢复点（RPO）的要求。

希望您能通过本文对SQL HADR技术有个大致了解，以后我们会再详细介绍其中的一些技术，谢谢。

SQL Engine部门经理
吴家震