本文讲的是SQL Server 2012研发团队背后的故事,在切入正题之前，就让浸泡在数据海洋里的我们，看几个并不陌生的场景吧。
场景一：痛苦的升级
三十六岁的吴桐坡是一个电商网站的首席技术官，最近有点头疼：业务旺季就在眼前，现在的内存、盘阵、操作系统和应用平台已经有点扛不住。老板却已发话，今年要基于用户消费行为的统计与分析，上线更多的新品类。唉，又要和部门里的兄弟们熬夜了。好在之前做了不少准备工作，对这次升级的成本和问题心里大概有底。“但过去几年，哪次硬件变更和软件升级没出过岔子?我怎么敢跟老板拍胸脯，说升级后的系统马上能顺利支持5000-6000次/秒的在线交易请求，而不影响任何业务?“
场景二：郁闷的IT
修养很好的俞年发火了，让这位年届不惑、掌控某跨国餐饮连锁品牌的职业经理人失控的原因很简单，当他早上10点走进办公室，没有看到昨天的运营报表——这让他想起昨晚从一位消息灵通的分析师朋友处得知，竞争品牌最近两个月的营业额大幅超过自家，这是什么原因?现在居然连头一天的运营报表都没正常出现，IT部门干什么去了?被俞年召来猛K一顿的IT经理任愿也很郁闷。“不知道为什么，头天晚上从各个营业点上传来的原始数据，未按正常流程进行匹配和清洗，最终没导入数据仓库，导致今天早晨没法生成报表，但老板也不至于这样生气吧?” 检查数据集成进程时发现原先仅需半小时的一个步骤用了近两小时，还是通不过，也找不出原因，郁闷…
场景三：抓狂的网购
二十九岁的白领史博妍与姐妹们一样，紧张的工作节奏让她无暇逛街，幸好还有网购。作为每月在网购过千元的重度用户，怎能错过各大网店的春夏促销?周末晚上，当她打开浏览器，却发现最钟爱的网店却无法访问，页面总是显示“响应超时”，而且怎么刷新也没用。难道下周要穿着去年的衣服去拜访客户和“周末大轰趴”?这个假设让她很抓狂，抓起了电话向网店客服投诉。数分钟后，网店的数据库管理员李易凌接到客服部门的排障需求，他能否在很短的时间里，从海量的Query记录中，找出那条引发故障的Query?
那些年，他们一起追寻的创新
您一定能猜到上面的三个典型场景，就藏着SQL Server 2012研发团队所要解决的三个典型问题，而解决这三个问题的主要团队成员，就是微软亚太研发集团服务器与开发工具事业部的一群年轻工程师们——而解决上述三个问题的功能分别是Distributed Replay、SQL Server集成服务(SSIS)和扩展事件(xEvent)。
正如微软其他应用于关键业务的产品，SQL Server 2012功能设计的来源主要有三类，即面向全球范围内的最终用户与分析师的调研、全球技术支持服务部门的反馈，以及开发团队的前瞻性思考。
故事一：跨越七年的灵感
Distributed Replay、集成服务和扩展事件也不例外，而其中从需求发掘、设计产生到功能实现时间跨度最大的，是Distributed Replay。而这一特性的灵感在2005年左右，几乎同时出现在姚钢和王清越的脑海里。
高级开发主管姚钢现在已申请下Distributed Replay的专利，触动他的是做SQL Server技术支持的六年经历，“客户经常在升级硬件和软件过程中碰到各种问题，尤其是新硬件和操作系统环境中，数据引擎性能的下降让他们很是挠头。是不是能有一个功能，让客户提前知道升级后，可能遇到的各种状况?“
而当时还在微软总部从事SQL Server引擎性能优化的王清越也在想，“如果能开发一个工具，让客户在多线程、高并发度的环境下，模拟实际应用场景，从而实现在变更软、硬件时预知这些变化对数据引擎性能的影响，不就能让他们不再忧心升级后的变数么?“
于是，当他们2008年加入SQL Server中国研发团队后，这个想法很自然地被提到了SQL Server 2012产品规划中。
让姚钢和王清越印象尤为深刻的是，2010年10月功能基本开发完成后，一位远道而来的欧洲电子商务客户提出，用他们的真实数据让Distributed Replay模拟5000-6000次/秒在线交易请求的生产环境?开了几个夜车后，两周内姚钢和同事们顺利实现了客户需求——这让项目组也很是欣慰，因为虽然设计目标就是实现每秒5000-6000次的负载模拟，但此前还未在实验室环境下得到过验证。
随着SQL Server 2012的上市，国内类似吴桐坡这样需求的CTO们，将不用再为软、硬件变更可能带来的性能变化而烦恼了。
故事二：为了一致与可靠
SQL Server集成服务要解决的则是IT经理们不得不面对的问题 —— 如何在有限时间和资源前提下，保证“数据的一致性和可靠性“，不至于当老板要看报告时，却交不出来。在集成服务的项目经理卓伟雄看来，帮助两个重量级本地客户解决类似问题的经历是在产品开发中最值得回味的，”这两个客户，一个来自保险业，一个来自连锁餐饮业。他们处理数据的共同特征是，来自各个分支机构的数据都在晚上运行，而实际上每天晚上运行SSIS包的时间窗口其实很短。在决策层第二天到办公室之前，数据平台要完成的事情有很多——首先是把数据从不同的来源取出，然后导入到数据仓库。从数据仓库到用户能使用的报表，多维数据集等等时间的掌控很重要。而在SQL Server 2012之前，当SSIS包在抓取、导入过程中出了问题，管理员往往需要花费数十分钟乃至几个小时，逐一找出并解决SSIS包抓取失败或延迟等问题。如果问题一多，第二天没法交付报告就成了很自然的事。而现在，管理人只需要通过预先建立的故障排除和性能调优功能，在SSIS包运行过程中，便能自动拿到最可能引发问题的事件记录，而用户可以马上把这些事件交给相关的技术部门去解决。”
让测试开发工程师吴晓晨记忆犹新的则是在最后测试阶段，一个特殊的场景下运行新功能时，往往比平时慢2、3秒，但一位同事硬是坚持三、四周解决了这个问题，因为他们觉得“如果每个客户都节约几秒钟，那么全球来看就是一个了不得的大数字。”
故事三：DBA的黎明
扩展事件的诞生，是为了帮助李易凌这样的数据库管理员们。当碰到这样的问题，他可以首先将当天的SQL Query(像场景三中的网店会有几千种SQL Query)的响应时间分组求平均值，然后按组排序以迅速找到花费时间最长的那一组Query，接着打开这一组Query排序，便能找到花费时间最长、甚至是无法响应的Query，从而迅速找到问题根源并进行排除。更为重要的是，轻量化的扩展事件只需很小的服务器资源开销，就能抓取50GB的Trace包。
SQL Server 2012的发布，对负责扩展事件的开发主管徐进、测试主管陈玉祥来说同样意义非凡——因为尽管从SQL 7.0时代就有了SQL Profiler工具，但直到SQL Server 2012有了扩展事件才高度满足了数据库管理员的大量真实需求。
作者：王玉圆
来源： IT168
原文标题：SQL Server 2012研发团队背后的故事