SQL中国研发中心

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部门经理
吴家震

穿越时空的快乐——微软SQL团队赴川志愿活动小记

起因

一年一度的微软中国SQL部门旅游时节到了。而今年比往年新加了内容：去四川做一天志愿者。这是公司回馈社会与社区的一贯风格。“公益加油站”组织合作策划了这次活动。我们选择了汶川水磨中学，此学校目前暂时搬迁到了数百公里外的峨眉山，因而使我们避免了在这震后一周年之际去汶川添乱。而活动形式是与初一的孩子们做游戏，旨在给孩子们一个轻松的周末。

策划

这次活动的主题叫“动画城堡”。我们被分为若干小组，我是小组长。每组要选一个与动画有关的主题，带领一个班做游戏。由于条件限制，这次活动只有大半天时间，而真正游戏的时间更短。如何选主题？游戏形式怎样？首先，我确立了如下指导原则：能让一个班的同学一起乐；与动画有关；对初一学生足够简单；好玩向上。其次，上网搜索经典动画片列表，拟出一些备选主题。随后，经过全组讨论，并征求了我正在上初中的弟弟的权威意见，我们最后定下来：以“大话西游”为主题，以团队比赛为形式。理由是：《西游记》所有孩子都喜欢，容易取材，也好玩，并且乐观向上；而团队比赛有助于增强同学们的团结拼搏精神。

筹备

我上网搜罗、筛选出十几种团队游戏的玩法，挑出其中最适合的十种，写了策划案，描述每个游戏的规则、资源、时间、调度等等。对每个游戏，根据其特点起了与《西游记》有关的名称，如：八戒传牌，唐僧念经，悟空的评语，太上老君炼丹，猪八戒娶媳妇，等等。接下来，各组员分头准备资源：有人去超市，有人网上购物，有人上网下载歌曲图片，有人要去买面粉和西瓜…… 各路资源一天天地陆续凑齐了，如唐僧师徒的面具、师徒肖像工艺笔、钉耙与金箍棒，等等。然而，贴鼻子用的师徒头像很麻烦：在网上搜索了无数剧照，都找不到适合贴鼻子游戏的头像，试着打印出来总不满意。到了临行前晚，我终于悟出，游戏本身要求鼻子是夸大的、非真实的，因此不能找剧照！很快便找到了四个大鼻子的卡通师徒肖像。

补缺

上飞机时我仍忐忑不安，因为有一个道具没有凑齐，那就是八戒媳妇高小姐的服装。网上卖的秧歌服太贵；而要想在上海街头买到花红柳绿的农妇袄，何其之难！在下飞机后的傍晚，其他同事们去品尝美味的四川小吃了，只有我和同组的Shirley在做详细筹备与设计，然后在服装夜市中奔走，逢摊就问：“头巾有没得？……”在大夏天买头巾的确有点难度，所幸半个多小时后我们终于找到了理想的头饰，无论男女，戴上即羞楚动人。当我们拎着三十斤西瓜回到住处时，组员们回来了，我们开了最后的预备会。

实况

一切如意。当猪八戒们狼吞虎咽了西瓜，背着花枝招展的男媳妇儿往返时，孩子们的笑声叫声掀翻了屋顶。临走时孩子们不想让我们走，要我们明年去汶川看他们。

小结

像所有活动那样，这次活动也留下诸多可改进之处。在主持、音效、布景、裁判、协作等各方面，我们每个人都有所获益。有人打趣志愿者说“不知道是他们需要我们，还是我们需要他们”，这显然片面了：我们相互需要，就像一首老歌里唱的，“人字的结构就是相互支撑”。

从二三十岁穿越到十二三岁，从科技园穿越到山区中学，我们体验到了穿越时空的快乐。谁又知道这些孩子们会不会在未来的某一天，穿越回来成为我们呢？

软件工程师
杨珂

SQL CRD 2009慈善之旅

2008年5月12日，中国四川遭受了举世震惊的大灾难。300多个日日夜夜过去了，四川人民在全国乃至全世界爱心人士的帮助之下重建家园，百废待兴。而最让人放心不下的还是在地震阴影下生活和学习着的灾区儿童们。这一年，他们承受了外界人们无法想象的痛苦和磨难，他们往日熟悉的中小学校整个校舍因地震成为危房，甚至全部倒塌；他们中的很多人因这场灾难永远地失去了父母亲人和同学伙伴。诚然，这场大灾难摧毁了地面上的建筑物，我们可以重建，但是，留在孩子们心目中的阴影乃至伤痕，更需要我们的关心和呵护。

图1 水磨中学

 SQL CRD 2009的慈善之旅就是选择了这样一所学校——汶川县水磨初级中学。水磨中学曾经创造了四川地震自救的奇迹。在地震发生时，校舍倾斜，墙板断裂错位，绝大部分学校建筑坍塌。但是在学校老师和员工的冷静疏导和救护之下，全校800多名学生和60多名教职工无一死亡。地震之后，水磨中学在社会各界的帮助之下终于在异地复课，地点就在峨眉山市郊的树人中学。和很多受灾严重的中学不同，虽然经历过了大地震的惊悸，水磨中学的学生们却早已脱离缺衣少食的环境。现在的水磨中学学生远离自己的父母亲人在异地生活已经200多天，独在异乡的他们缺少的是父母亲人的关怀，有的是朋友伙伴们的游戏，以及正常学校学生们普普通通生活的一天。

图2 BI部门经理晓燕代表SQL CRD向水磨中学捐书

带着对灾区同学们的眷眷期盼和深深情谊，我们SQL CRD全体员工一行70多人在2009年5月9日到达了四川省汶川县水磨中学当时所在的峨眉山市郊树人中学。除了慰问学校的老师和向同学们捐赠图书和体育器材之外，我们当天还有一项特殊的任务，就是让孩子们在那一天能快快乐乐的活动，暂时忘却远离亲人和家乡的孤独和苦恼。活动有分室内和室外共9组，每一组都得到了学生们的热烈响应和参与。

  
            图5 灌篮高手                                                            图6 场边的啦啦队员

通过和同学们一天的接触，我们不仅被同学们积极向上的精神面貌所打动，而且也对他们在艰苦环境下的乐观精神感到钦佩。虽然我们给灾区的孩子们提供了一点帮助，实际上，孩子们给予我们的馈赠却更多。

            图7 简陋的校舍                                                 图8 一间宿舍要住22个同学

离开水磨中学的时候，恋恋不舍的同学和老师一直在向我们挥手。别了，可爱的水磨孩子们，愿你们在不远的将来能重返家园，安心读书；别了，可爱的四川人民，愿你们再也不会遭受这样的苦难和磨砺，重建家园，世世代代美好生活下去。

软件测试工程师  赵明

使用微软SAP BI Connector组件分析处理数据

微软SAP BI Connector组件（Microsoft Connector for SAP BI）是由微软中国SQL Server商务智能团队开发的集成服务（Integration Services）新组件，它的主要功能是让用户更方便地在微软SSIS集成环境中与SAP NetWeaver BI交互数据。

该组件由三部分组成：

• SAP BI源：从SAP NetWeaver中取出数据
• SAP BI目标：将数据导入到SAP系统中
• SAP BI 连接：对集成服务包与SAP BI系统间的连接进行管理。

该组件已与微软SQL Server 2008 Feature Pack SP1同步发布，目前，SAP BI源已经得到了SAP的认证，而SAP BI目标的认证也正在进行中。你可以在这里下载该组件。

需要注意的是，安装使用SAP BI Connector组件必须满足以下条件：

• 操作系统为Windows Server 2003及以上的版本
• 安装SQL Server 2008 集成服务（SQL Server 2008 Integration Services）
• 安装Windows Installer 4.5 或之后的版本
• 从SAP BW中取出数据需要得到SAP Open Hub license
• 在SAP BI系统中，SAP_BW Support Package需要在16级以上
• 根据不同的安装版本，需要将32位或64位的librfc32.dll复制到%windir%\system32目录中。在WOW模式下，们需要将32位的librfc32.dll复制到%windir%\SysWow64目录中

在安装之后，我们需要打开Visual Studio并在SSIS面板中添加SAP BI组件，如图1所示。这样，我们就能够在Visual Studio中直接使用SAP BI Connector组件了。

下面，我们将结合实际数据分析的案例，来介绍微软SAP BI Connector组件同已有的微软数据库系列软件及办公软件相结合，在Excel中分析和展示SAP BI的数据。

整个方案的实施流程如下：我们首先使用SAP BI源从SAP数据仓库中抽取数据，并存储到SQL Server数据表中，然后通过SQL Server分析服务软件（Analysis Services）建立SSAS数据仓库，并最终在EXCEL中直观地显示数据仓库的内容。

解决方案的整体结构如图2所示：

为了更便捷地进行处理，我们预先在SQL Server数据库中建立了由主表和从表组成的星型结构，如图3所示，这样，我们就可以直接将SAP BI数据通过这些表导入到数据仓库中。

整个方案的核心是我们创建的SSIS包，如图2中所示，它包括2方面的内容，首先通过SAP BI源将数据从SAP数据仓库中抽取并存储到SQL Server的表中，然后通过Analysis Service处理任务（Analysis Services Processing Task）将数据导入到SQL Server分析服务（Analysis Services）的数据仓库中。

在完成了以上操作之后，我们就可以通过Excel来直观地分析和展示数据仓库中的数据了，如图4所示。

如果您需要更多的相关信息，您可以参考在SQL Server2008中使用SAP BI白皮书。

软件开发工程师 李人和

超轻量级MSXML多功能测试程序

MSXML是微软非托管代码栈中最为核心的XML服务集合，不但适合基于COM的开发应用，更是微软AJAX解决方案和客户端XSLT解决方案的核心组件。

上一次我们介绍了一个基于HTML和MSXML6的超轻量级XPATH测试程序。本次我们将推出一个更全面的MSXML测试程序。这个程序可以验证XPath、XSLT、Schema和XDR，并支持Namespace。

整个页面分为五个区域：

1、首先是功能和版本的选择区。版本支持MSXML  3.0、4.0和6.0。而可供选择的功能有XPath 1.0、XSLT 1.0、Schema 1.0 和XDR。其中XDR是MSXML 3.0中用于验证XML的规范，在MSXML 4.0和MSXML 6.0中已经被XML Schema取代。针对每一个功能，都内置了一个示例，用户可以直接点击各个功能查看效果。

2、右上方是Namespaces for XPath，这里定义的namespace可以在XPath查询中使用。每个namespace定义应该以xmlns:开头，每行一个定义。

3、左边是XML文件内容，这个文件内容是为所有功能使用的。

4、中间是XPath/XSL/Schema输入区域，这里的输入是为每个功能单独缓存的。也就是说，当你输入XPath后，切换到XSLT或其他功能，XPath的内容将被缓存并在下次切换回XPath时自动恢复在这个输入框中。

5、右边是结果显示区域。右下方是以HTML方式显示结果或错误信息。黑色代表正确，红色代表错误，灰色代表没有结果返回。

这个页面是基于19英寸显示器开发的，最佳分辨率为1280X1024或1440X900。

同上次一样，你可以把这个程序放在WEB服务器上用IE访问，或者放在自己的文件系统直接用IE打开（如果打开时碰到IE的安全提示，请选择允许）。

点击这里直接运行该程序。

宋伟 软件开发工程师

简要介绍SQL Server 2008新的事件处理系统——SQL Server Extended Events

SQL Server Extended Events（下面简称XEvent）是SQL Server 2008里新加的事件处理系统，用来取代SQL Server原先的SQL Trace的跟踪机制。事件处理系统对一个复杂服务器系统的排错，调试是极为关键的。和SQL Server原来的事件处理系统相比较，XEvent具有下列的优势：

• 消耗更少的系统资源，更适用于在产品服务器上的排错和调试。并且每收集一个系统事件所消耗的资源都是可预测的。
• 不仅仅能收集事件数据，还能收集在这事件触发点的系统动态运行信息，例如内存，T-SQL Stack等等。
• 可配置性，能够根据系统负载的需求配置所需收集的事件信息。

下面是一个简单的例子介绍如何使用XEvent来做系统排错工作。

当前台应用性能下降的时候，数据库管理员经常需要确定是否有资源锁的申请冲突，既所谓我们说的blocking。在SQL Server 2008里面，你可以查询系统视图sys.dm_exec_requests，并且能发现有一些进程正在等待资源锁，比如像下面这个结果：

我们可以看到有个Session 54的状态是Suspended,意味着一个查询的操作被blocked, 但是我们看不到是哪一个Query占用了资源，以及查询计划和T-SQL Stack等等，如果我有下面的XEvent Session我们就能够解决这个问题。（在下面的例子中我们假设XEvent Session在Block发生之前已经启动好了）

1、在查询编辑器执行下面的命令，这会创建一个XEvent Session来捕捉lock_acquired和lock_released，同时我们还会抓下sql_text，tsql_stack和plan_handle等信息。

-- Perform cleanup.

IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='FindBlockers')

    DROP EVENT SESSION FindBlockers ON SERVER

GO

-- 我们这边假设是数据库”DAA”里出了block,所以我们会使用一个predicate去过滤掉其他数据库的Block问题

--

DECLARE @dbid int

SELECT @dbid = db_id('DAA')

IF @dbid IS NULL

BEGIN

    RAISERROR('DAA is not installed. Install DAA before proceeding', 17, 1)

    RETURN

END

DECLARE @sql nvarchar(1024)

SET @sql = '

CREATE EVENT SESSION FindBlockers ON SERVER

--这里我们加了lock_acquired的Event,并要求返回sql_text，database_id,tsql_stack,         --plan_handle和session_id的信息

--

ADD EVENT sqlserver.lock_acquired

    (action

        ( sqlserver.sql_text, sqlserver.database_id, sqlserver.tsql_stack,

         sqlserver.plan_handle, sqlserver.session_id)

    WHERE ( database_id=' + cast(@dbid as nvarchar) + ' AND resource_0!=0)

    ),

ADD EVENT sqlserver.lock_released

    (WHERE ( database_id=' + cast(@dbid as nvarchar) + ' AND resource_0!=0 ))

ADD TARGET package0.pair_matching

    ( SET begin_event=''sqlserver.lock_acquired'',

            begin_matching_columns=''database_id, resource_0, resource_1, resource_2, transaction_id, mode'',

            end_event=''sqlserver.lock_released'',

            end_matching_columns=''database_id, resource_0, resource_1, resource_2, transaction_id, mode'',

    respond_to_memory_pressure=1)

WITH (max_dispatch_latency = 1 seconds)'

EXEC (@sql)

--

-- Create the metadata for the event session

-- Start the event session

--

ALTER EVENT SESSION FindBlockers ON SERVER

STATE = START

2、一旦XEVENT然后我们可以执行下面的语句去找到那些block了别人的查询语句： 

--

-- The pair matching targets report current unpaired events using

-- the sys.dm_xe_session_targets dynamic management view (DMV)

-- in XML format.

-- The following query retrieves the data from the DMV and stores

-- key data in a temporary table to speed subsequent access and

-- retrieval.

--

SELECT

objlocks.value('(action/value)[5]', 'int')

        AS session_id,

    objlocks.value('(data/value)[5]', 'int')

        AS database_id,

    objlocks.value('(data/text)[1]', 'nvarchar(50)' )

        AS resource_type,

    objlocks.value('(data/value)[9]', 'bigint')

        AS resource_0,

    objlocks.value('(data/value)[10]', 'bigint')

        AS resource_1,

    objlocks.value('(data/value)[11]', 'bigint')

        AS resource_2,

    objlocks.value('(data/text)[2]', 'nvarchar(50)')

        AS mode,

    objlocks.value('(action/value)[1]', 'varchar(MAX)')

        AS sql_text,

    CAST(objlocks.value('(action/value)[4]', 'varchar(MAX)') AS xml)

        AS plan_handle,   

    CAST(objlocks.value('(action/value)[3]', 'varchar(MAX)') AS xml)

        AS tsql_stack

INTO #unmatched_locks

FROM (

    SELECT CAST(xest.target_data as xml)

        lockinfo

    FROM sys.dm_xe_session_targets xest

    JOIN sys.dm_xe_sessions xes ON xes.address = xest.event_session_address

    WHERE xest.target_name = 'pair_matching' AND xes.name = 'FindBlockers'

) heldlocks

CROSS APPLY lockinfo.nodes('//event[@name="lock_acquired"]') AS T(objlocks)

--

-- Join the data acquired from the pairing target with other

-- DMVs to return provide additional information about blockers

--

SELECT ul.*

    FROM #unmatched_locks ul

    INNER JOIN sys.dm_tran_locks tl ON ul.database_id = tl.resource_database_id AND ul.resource_type = tl.resource_type

    WHERE resource_0 IS NOT NULL

    AND session_id IN

        (SELECT blocking_session_id FROM sys.dm_exec_requests WHERE blocking_session_id != 0)

    AND tl.request_status='wait'

上面的语句返回下面的结果，我们可以看到是一个Session 53的Update更新语句Block了Session 54的查询： 

有下面sql_text里可以看到，整个更新语句begin tran Update BlockTest set Col1 = 'Updated' where ID = 1中，由于少了一个Commit tran，所以block了其他查询对表BlockTest的操作，

XEvent还有很多强大的功能和更广应用，有机会的话以后再为大家介绍。

项目经理 林默

升级到MSXML 6.0

由于历史原因，MSXML有许多版本共存，比如3.0、4.0、5.0和6.0。让我们的客户把他们的应用程序移植到MSXML 6.0上去是我们的最终目标。

虽然我们希望今天每个人都在使用MSXML 6.0，但仍然清醒地意识到迁移需要相当的时间。所以我们将继续在MSXML 3.0上投入资源以支持现有的应用程序以及满足那些需要零发布需求。虽然MSXML 3.0并不具有MSXML6的新特性，不过MSXML 3.0仍然不失为一个稳定而强健的XML平台。MSXML 3.0已经随着Win2000 SP4以及以上的操作系统一起发布，对于应用程序而言可以说无需考虑发布的问题。

MSXML 4.0是MSXML 6.0的前身，不过并不曾随着操作系统发布。虽然我们刚刚发布了MSXML 4.0 SP3，但是就W3C标准以及与System.Xml的兼容性而言，MSXML 6.0是一个巨大的进步。此外，MSXML 6.0还提供64位版本。目前，我们主要在MSXML 6.0和MSXML 3.0上投入精力，所以我们希望用户尽可能迁移到MSXML 6.0，或者根据需要迁移到MSXML 3.0。

最后，如果不是针对Microsoft Office 2003或者Microsoft Office 2007编写程序却使用MSXML 5.0的开发者，应该立即迁移到MSXML 6.0。

摘要

MSXML 6.0是适用于COM和脚本语言环境中的微软XML产品线中的最新版本。本文主要涉及了MSXML 6.0 的安装和应用升级，所支持的操作系统以及其相对于MSXML3和MSXML4的变化。

本文所涉及到的MSXML 6.0的主要变化有以下方面：

• MSXML 6.0 引入一系列安全方面的改变，默认关闭了安全敏感的特性。
• MSXML 6.0 改进了对W3C XSD 1.0 标准的支持，并且提高了与.Net Framework 2.0 中System.Xml的兼容性。
• MSXML 6.0 抛弃了若干遗留在MSXML 3.0 和 MSXML 4.0中的特性。
• MSXML 6.0 不再支持通过MSM或CAB方式部属。MSXML 6.0已经是Vista和Windows XP SP3操作系统的一部分，对Vista以下系统只支持MSI方式安装。

可以在http://msdn2.microsoft.com/en-us/library/ms753751.aspx找到关于MSXML 6.0的更新信息。

安装和升级

MSXML 6.0 随着Vista和Windows XP SP3发布，对其他低版本操作系统，可以从这里下载，然后及时运行Windows Update以便升级到最新版本。安装成功后，会增加以下两个文件：

• %SYSDIR%\msxml6.dll
• %SYSDIR%\msxml6r.dll

要将一个应用程序升级为使用MSXML 6.0的程序，所有对MSXML对象的引用必须修改为使用MSXML 6.0指定版本的ProgIDs，例如：MSXML2.DOMDocument.6.0。

MSXML 6.0 支持以下操作系统：

• Windows 2000
• Windows XP
• Windows 2003
• Windows Vista

MSXML 6.0的技术支持将根据http://support.microsoft.com/default.aspx?pr=lifesupsps#Windows 所列的Windows Service Packs支持策略进行。

安全迁移——理解“默认关闭”

在MSXML 6.0 中，若干安全敏感的特性默认被设置为关闭状态。当升级的时候，这些特性可能需要通过设置打开。但请注意，当从不信任的或未授权的客户端解析数据时，请务必谨慎。可以在http://msdn2.microsoft.com/en-us/library/ms754611.aspx找到更多的安全注意事项。

改进与W3C XSD 1.0一致性以及与System.Xml 2.0兼容性：XmlSchemaCache的变化

为了改进与W3C标准的一致性以及与其他schema的兼容性，MSXML 6.0在XmlSchemaCache中对XSD schema编译和校验模型引入了一系列的变化。无论文档是通过DOMDocument还是SAXXMLReader来校验，这些变化都适用。

XmlSchemaCache既被IXMLDOMDocument2接口的schemas和namespaces属性所使用，也被做为一个属性，由ISAXXMLReader.putProperty所支持。

IXMLDOMSchemaCollection/XMLSchemaCache对象是线程自由的，可以被同时用于多个文档。发送到schema集合的XML schema文档会被克隆，XML schema文档仍然可写。在XML schema文件装入SchemaCache后，任何对XML schema文件的修改都不会反应到它的克隆镜像上。一个schema缓存可以被添加到多个schema集合中去。

MSDN中关于这个主题的文档在http://msdn2.microsoft.com/en-us/library/ms764692.aspx

被废弃的特性和类

• XDR Schema不能在MSXML 6.0中继续使用。可以用XSD.EXE将XDR Schema转换为XSD格式。XSD.EXE跟随Visual Studio .NET 1.0 和1.1一起安装。
• MSXML 6.0不支持DSO（MSXML2.DSOControl.6.0）。这个特性很少有用户使用。

总之，让我们的客户把他们的应用程序移植到MSXML 6.0上去是我们的最终目标。如果您在迁移过程中遇到任何问题，请直接留言或者在MSDN论坛上提问。

英文原文可以在这里找到。

MSXML团队

30分钟内加载1TB 的数据——SSIS打破商业ETL工具的记录

许多企业拥有海量的数据，并将其存储在多个不同的数据源。为了给用户提供有意义和可靠的信息，企业需要提取、转换和加载数据（Extract, Transform, and Load data，简称 ETL）。SQL Server 集成服务 （SSIS）可以让企业把来自异构数据源的任意数据加载到数据库。

2008年2月，微软宣布了SQL Server 集成服务数据加载的一个破记录壮举：SQL Server集成服务用不到30分钟的时间把1 TB 的数据从平面文件加载到SQL Server 2008。这比其他商业ETL工具的最佳时间快了30%。

该项测试把数据源分布在四台服务器中，每一台数据源服务器都是UNISYS ES3220L（2 sockets each with 4 core Intel 2GHz CPUs, 4GB RAM, Windows Server 2008, SQL Server 2008）。数据目的地的服务器是一台UNISYS ES7000/One（32 sockets each with 2 core Intel 3.4 GHz CPUs 256 GB RAM, Windows Server 2008 and SQL Server 2008）。集成服务将海量的数据通过千兆以太网络加载到数据目的地。测试用的数据来自TPC-H的数据生成程序DBGEN。

从MSDN白皮书中，我们可以详细了解关于该项测试所使用的软件、硬件和配置。同时，文章中也详细提供与这些技术相关的典型方案的建议。

SQLCRD BI团队

听微软大牛们谈“怎样成为优秀的工程师”

这天正午，上海紫竹园晴空万里，微软服务器与开发工具事业部（STB）正在会议室进行一个午餐谈话，主题是“怎样成为优秀的工程师”。听众是来自各个部门的员工，大部分是年轻面孔。面对听众的是主持人和四位“大牛”，其中有三位是经理，一位是资深的个人贡献者（Individual Contributor，IC）。他们相同的是都有很强的技术背景，深谙什么是优秀的工程师。我们SQL Server中国研发中心的总经理孙博凯（Prakash Sundaresan）也落座其中。主持人先后问了数个问题请大牛们谈论，我将这些谈论记录下来，和大家分享：

个人故事

在回顾多年个人职业发展历程时，每位大牛似乎都有一条“线索”指引着他们。博凯说，当时他在开发组长（dev lead）的职位上，通常下一步会朝经理职位发展。而他却问自己：“我还需要什么经验？”他发现自己还缺少与客户打交道的经验；而开发一个优秀产品，不深入了解客户怎么行呢？于是他转而进入客户部门锻炼了一年。可以看到，博凯很早就知道他想要成为什么，即技术的全面手。另外三位大牛的职业线索也很清晰：那位IC想成为“Hard core（技术牛人）”； 另两位经理的分别是“快乐”和“为机遇做好准备”。这些线索一直引导他们的行为和选择。我想，这些线索殊途同归，都使他们做出了优秀的产品，并使他们成为今天的大牛。我不禁问自己：我的线索是什么？

应对挑战

博凯以前就强调，唯一不变的是改变本身。这在金融危机背景下的今天尤为适用。他说，人人都知道，工程师的成功秘诀是“成为专家”。可是“在什么方面”成为专家呢？ 具体的领域知识天天在变，今天的技术也许会是明日黄花。因此，应在“成为专家”方面成为专家（be an expert on being an expert）！——看来，这种隐性的能力才是以不变应万变的秘诀啊！

Individual Contributor （IC）与经理之间的切换

IC是微软内与经理平行的另一职业类别，不管理人而专注技术。众所周知，微软对IC的重视无出其右。IC与经理这两条职业路径都可以上升到最顶端，并可在中途相互交叉。有不少人在IC与经理之间来回穿梭，四位大牛中就有这样的例子。他们不约而同地认为：（1） IC与经理在微软同等被重视（we value both equally），（2）IC与经理的经验互相补充，并且（3）两种职位都需要有激情。针对中国官本位文化对经理的偏好，博凯幽默地引了一句笑话： “Management is overhead（管理是额外开销）”。呵呵，可以看出他们对优秀IC的求贤若渴，这也许也反映出一个优秀的IC是如何之难得吧。

校园入职者（Campus Hire）面临的挑战

微软有大量员工从应届毕业生中招聘而来，因此主持人提出了这个问题。我记得STB总经理谢恩伟在Campus Hire入职时讲过，Campus Hire的优势是“一张白纸好画最美的图画”。然而，在座的大牛们也发现一些Campus Hire欠缺的地方。一个是批判性思维（critical thinking），在互相诘难中共同成长。当有人诘难甚至质疑你的工作内容时，应该想的是“谢谢你，你是想让它更好。”此外，博凯提到，美国和印度的Campus Hire在自由形式讨论（free form discussion）中比中国的Campus Hire更积极些，发言更多。他还说了一句直译过来是《大话西游》台词的话：“你不说我怎么知道呢？”显然，此时大家在很有诚意地看着他。

可见性（Visibility）

可见性主要是指让上级看到自己做的工作。对此，大牛们认为，一般来说工作都是可见的，因为主要矛盾总是被上级意识到的，而我们在工作中自然应首先解决主要问题。看来，毛主席教导我们要“抓主要矛盾”真是无往而不胜啊。一位大牛说，一个“非常常见的错误”是排错工作的优先级。如何知道此时最应该干哪件事呢？他的建议是，与上级的交互与沟通是非常重要的。

出国培训的作用

一般，新员工入职后都会去美国培训一段时间。当问及这段经历的作用时，大牛们说，出国交流把我们曝光在不同的思考方式面前，使思想更开放（open）。他们说，以前微软仅在美国时，还没有什么国际交流，而现在我们则幸运得多，中国的工作环境中也有不少老外。他们还说，相比于是否与老外交流，更重要的问题是“从谁身上学习”。在公司文化中，20%的学习来自学习他人。每个新员工入职时会被安排一个“师兄”，此外还有长期跟踪的“导师组”等等。在这里，只要想学，总能博采众人之长，为我所用。

工作/生活平衡与工作效率

社会上都说“搞IT很辛苦”。怎样才能平衡工作与生活呢？一位大牛说，首先，“平衡”没有绝对标准，与个人幸福感受相关。有人觉得每周工作40小时是平衡的，有人却乐意工作更多。为了认识自己的偏好，他建议我们列一个“工作/生活平衡清单”，分析一下哪些情况会让自己快乐，哪些情况反之。显然，我不能承受每天加班之重，但也不能承受不上班之空虚。由于微软的评价体系是结果导向（result oriented），“不在乎你花了多少时间”，因此，工作效率尤为重要，效率高的人工作时间少，也就在工作/生活平衡中更有主动权。对于如何提高工作效率，博凯提出一条“三件事”方法：每天只记住三件小事，每年只完成三件大事即可。呵，依旧是“抓主要矛盾”。是啊，记得我以前每天花多少时间处理各种琐事，而主要任务却被耽搁。后来只集中抓主要任务，才发现很多琐事其实可以推后，等等再做。

人际关系

公司有几种人际关系：与同事的当然最重要，同时还有与上级的，与“师兄”和“导师”的，与位于国外的团队成员的，等等。我们公司这些关系已经纯得不能再纯了。博凯提出一个“品牌（brand）”概念：一个公司有一个品牌，同样地，我们每个人也有一个品牌。我们应该在职业之初就想好，自己想成为哪种品牌。换言之，希望别人怎样看自己？他们首先想到的是“善于合作的”，抑或“值得信赖的”，等等。博凯说，今后的漫长生涯中，我们可能更换工作或职位，但品牌会一直伴随着自己。

这几位大牛的品牌都是响当当的，因此他们的观点值得我好好回味。这些谈话对我的自我反省和职业规划提供了有益的指导，也希望对读者你有用 ：）

软件工程师
杨珂

使用HTML和MSXML6.0 创建一个超轻量级XPATH测试程序

在开发和调试基于XML的应用的时候，程序员往往为找不到合适的快速桌面XPATH测试软件发愁。诚然，市面上有成套的XML编辑软件，但是它们往往要么太过于庞大，安装维护不是很方便，要么就是不免费，自己写一个吧，又觉得处理UI很烦。特别是在利用MSXML开发软件的程序员，很想使用MSXML直接测试自己写的XPATH对不对。笔者这里提供各位程序员一个基于HTML和MSXML6的超轻量级XPATH测试程序参考和使用：

你可以把这个程序放在WEB服务器上供其他同事共享，或者放在自己的文件系统直接用IE打开（对不起，这个程序只在IE上测试过）。打开后左面的窗口可以贴你的测试XML文本，右边可以随心所欲的敲入你的XPATH语句。在XPATH下方会随你的输入立刻输出可能的XPATH输出结果。红色代表错误，黑色代表正确，灰色代表XPATH的执行没有任何结果返回。

点击这里直接运行该程序。笔者真诚的希望这个小程序会对你的XML和MSXML开发工作有所帮助。

蒋欣 高级软件开发主管

现在可以下载MSXML4.0 SP3了

今天，我们很荣幸地宣布MSXML4.0 Service Pack 3 (SP3)可以在微软下载中心下载了！

MSXML4.0 SP3支持多种语言。MSXML4.0 SP3修复了许多安全缺陷并提高了软件的可靠性，可以完全取代以前的MSXML4.0、MSXML4.0 SP1和MSXML4.0 SP2。

MSXML4.0大约是九年前发布的，不过早已被MSXML6.0取代，MSXML4.0的存在仅仅是为了更安全地支持遗留系统。目前没有任何在MSXML4.0 SP3中添加新功能的计划。同时，对MSXML4.0 SP2的支持将会在2009年11月结束。

我们强烈建议MSXML4.0的用户尽早迁移到MSXML6.0平台上。MSXML6.0拥有许多新功能，在性能以及安全性上也更胜一筹。此外，MSXML6.0更接近W3C规范，与
System.XML的兼容性也更好。请参考Upgrading to MSXML6.0以了解MSXML4.0 和MSXML6.0之间的差异以及迁移时需要注意的事项。

注意：如果你安装过MSXML4.0 SP3 BETA，请务必在安装MSXML4.0 SP3正式版之前先行卸载MSXML4.0 SP3 BETA。对于安装了MSXML4.0 SP3 BETA的Windows Vista和Windows Server 2008的用户，请阅读发行说明。

SQL中国研发中心近况

嗯，我该说些什么好呢——这是一个漫长、有趣而又繁忙的一年。当然，与我最后一次发帖子时相比，很多事情已经发生了变化：

• 最开始只是出现在美国部分房产抵押市场上的金融危机，现在已经演变为一场世界性的经济危机。这场危机几乎影响到了所有经济领域中的所有人。
• 我们在世界各地都有了重要的政治进展，而绝不仅仅是在美国选举产生了一位新总统。
• 在离我们最近的领域，微软在PDC 2008上推出了Azure服务平台。考虑到它的广度和深度，这是对软件+服务世界的一次无比有力的推进。虽然Azure平台仍处于早期阶段，但这标志着一个转变的开始。这场转变将从根本上影响到微软公司的几乎所有产品，乃至整个软件产业。

在我们SQL Server部门，我们也度过了非常繁忙和富有成效的一年。我们继续朝着完全数据平台的愿景迈出强有力的进展。我们发布了SQL Server 2008，它代表着向我们的使命迈出了一大步——一个服务于所有数据的平台，涵盖从出生到存档的整个生命周期。我们在世界各地举行了产品发布活动，包括2008年11月在中国北京举办的TechEd大会。在那次大会上SQL Server部门的副总裁Ted Kummert在主题演讲中启动了产品发布。整个行业对此的反应都非常积极，包括客户、合作伙伴、来自世界各地的分析家和新闻等。我们期待着未来几年市场上的强劲势头。通过密切参与SQL Server 2008规划，我个人也非常高兴地看到这有力地证明了我们的核心愿景和价值主张，以及我们软件开发的质量。

在SQL Server中国研发中心这里，我们也度过了繁忙的一年，主要埋头于SQL Server 2008和其他数据平台组件的发布工作中。现在整个团队正紧张地工作于SQL Server下一个版本的规划。除了研发工作，我们也通过各种渠道努力与中国本地客户和合作伙伴建立联系：通过我们的SQL Server中文论坛；通过TechEd等活动——我们在TechEd 2008上发表了几次演说，并主持了SQL Server在中国的第一次Ask the Experts活动；通过与MVP、客户、合作伙伴的紧密合作等。通过查看SQL中国研发中心团队博客上团队成员自己的帖子，你可以看到我们更多的工作。

为SQL Server这样复杂的系统级产品建设一个世界一流的开发团队是一个具有挑战性的过程，需要时间和耐心。但是，随着我们在若干方面有系统，有条理地进行着，我非常高兴地看到我们正在为实现这一目标所取得的进展。随着在这个征途中不断取得进展，我期待着和大家更多的交流经验和共同学习。

再见！

孙博凯

点击这里查看英文原文

使用Trace Management Object监测和诊断SQL Server（二）

在这篇文章中我们将介绍一个replay trace的示例，通过重放抓到的trace文件来诊断应用程序在SQL Server上运行是否有问题。

Replay trace示例

这个例子模仿你使用Profiler工具对抓到的trace文件进行重放，从而对SQL Server及你的应用程序进行诊断的过程。下面是详细的步骤和描述。

1、TraceReplay类是对trace file或trace table进行重放的关键类，你需要设置TraceReplay的三个属性，Connection属性代表你将在哪个数据库实例上进行重放，Source属性代表重放哪个文件或数据表，OutputFile代表重放的结果将输出到哪个文件，你也可以使用OutputTable属性指定将重放结果输出到数据表中。下面的代码将使用capture trace例子里抓到的trace file作为重放的输入并将结果存为traceoutput.trc文件。

TraceReplay replay = new TraceReplay();
SqlConnectionInfo connInfo = new SqlConnectionInfo(".");
connInfo.UseIntegratedSecurity = true;
replay.Connection = connInfo;
TraceFile traceFile = new TraceFile();
traceFile.InitializeAsReader(@"c:\tracefile.trc");
replay.Source = traceFile;
TraceFile traceFileOutput = new TraceFile();
traceFileOutput.InitializeAsReplayOutputWriter(@"c:\replayoutput.trc");
replay.OutputFile = traceFileOutput;

2、TraceReplay类还有个比较重要的属性Options，你可以通过设置Options属性来控制如何重放。Options属性是个TraceReplayOptions对象，Profiler工具中重放配置对话框上的很多配置项都可以通过Options属性来设置。下面的代码中设置了3个属性，Mode设置重放模式为连接层面上同步（另一个模式为SequentialReplay，指在所有连接上完全同步），NumberOfReplayThreads设置重放的线程数为2，KeepResults将控制在重放结果文件中是否出现SQL等的执行结果，比如你的trace里有select 1语句，那设置KeepResults为false将避免在结果文件中出现select 1返回的result set。

replay.Options.Mode = ReplayMode.ConnectionLevelSync;
replay.Options.NumberOfReplayThreads = 2;
replay.Options.KeepResults = false;

3、TraceReplay类提供了5个事件，你可以通过提供你自己的event handler来进一步控制重放操作，其中最有用的event是ReplayEvent，它将在每个event被重放之前调用，你可以控制是否跳过该event的重放。下面的代码在设置了ReplayEvent的处理函数后启动重放。请注意Start函数是同步操作，它将一直阻塞直到重放结束，所以如果你需要在中途停掉的话，你可以在event handler里或者其它线程中调用Stop函数。 

replay.ReplayEvent += new ReplayEventHandler(ReplayHandler);
replay.Start();
traceFile.Close();

4、这里我们的ReplayHandler处理函数将对SPID进行过滤，所有SPID不是54的事件都将被忽略。代码中空的catch是为了避免某些event不含有SPID列会造成读取该列失败。 

private static void ReplayHandler(Object sender, ReplayEventArgs args)
{
    IDataRecordChanger recordChanger = args.CurrentRecord;
    int spid = 0;
    try
    {
        spid = (int)recordChanger["SPID"];
    }
    catch { }
    if (spid != 54)
        args.SkipRecord = true;
}

5、Replay的结果文件可以用Profiler工具打开查看，当然你仍然可以通过TraceFile打开，只要简单的调用InitializeAsReader然后循环调用Read即可，下面的代码将打出TextData列的内容。