场景一：痛苦的升级
三十六岁的吴桐坡是一个电商网站的首席技术官，最近有点头疼：业务旺季就在眼前，现在的内存、盘阵、操作系统和应用平台已经有点扛不住。老板却已发话，今年要基于用户消费行为的统计与分析，上线更多的新品类。唉，又要和部门里的兄弟们熬夜了。好在之前做了不少准备工作，对这次升级的成本和问题心里大概有底。“但过去几年，哪次硬件变更和软件升级没出过岔子?我怎么敢跟老板拍胸脯，说升级后的系统马上能顺利支持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们，将不用再为软、硬件变更可能带来的性能变化而烦恼了。