搭建测试环境的示意图
　　
　　鲍勃推动的新订单程序上线后，系统变慢。董事会担心因此影响生意和声誉。鲍勃费尽周折查出原因在后台数据库，然而在测试环境下却没有什么不正常的。鲍勃最终能解决系统变慢的问题吗？
　　在鲍勃的推动下，公司的订单系统经历了一个非常快速的开发流程，很快就集成到在线店面中去了。不久，他发现，销售系统的运行有些异常：查询每条在线订单的时候，前台Web服务器从后台数据库中读取数据的时间徒然上升，而且容易出错，响应客户请求方面也显得缓慢。
　　与此同时，当Mira（鲍勃的新同事）开始为电子商务程序更新模块时，系统终于不堪重负，倒下了。鲍勃和Mira感到了压力：董事会担心，因为系统缓慢，一些用户会散播谣言，使公司的信誉度下降，以至会影响上市的进度。
　　为什么我们把系统放在生产网络中，大家都用得很好的时候，系统却变慢了？鲍勃想改变这个系统越用越慢的情况，他该如何做呢？
　　
　　根源在后台数据库
　　
　　由于鲍勃曾经管理过比较复杂的网络系统，他知道，用户反映系统出现故障时，一步一步去确定系统的各个环节是否有问题非常麻烦，有很多工作要做：检查交换机和路由器，Ping操作系统，检查数据库服务器，检查数据库是否正常（如日志已满），检查IIS及App Pool是否异常，检查自定义的Socket程序是否正常等等……
　　鲍勃订购了System Center Operation Manager 2007 ，这样可以通过自定义分布式应用程序，把所有应用程序整合在一起，系统会自动监控每台服务器的工作环节。如果有问题，系统会及时让整个工作小组的开发和维护人员同时收到通知。但时间紧迫，董事会并不允许他等到这个新产品上线。
　　在确定排除了Web服务器CPU和内存可能存在的瓶颈之后，针对Web服务器上的IIS 6.0 ，鲍勃要求开发小组改写了三个Monitor脚本，其中使用两个Monitor脚本收集系统信息：IIsmDyn.js和IIsmStat.js。以IIsmDyn.js脚本为例，这个脚本可以检索系统性能信息和系统事件信息，这样可以避免维护人员通过手工访问性能监视器或事件查看器。该脚本会检索来自以下源头的事件查看器条目：WAS（Web 管理服务）、W3CTRS（World Wide Web 计数器）、W3SVC（World Wide Web 发布）等。
　　工作小组重新利用压力测试软件对Web服务器上的静态页面进行测试。监控脚本在Web服务器上布控了3天零19个小时，几次测试的结果都表明，每台服务器的处理能力都维持在每秒80.20次请求的级别上，CPU的利用率约为65%左右，这相当于2100～2500名并发访问用户的情况。但是监控脚本中并没有直接提供警告的信息，人们带着怀疑的心理对后台数据库进行性能测试。刚一开始，服务器就缓慢下来，鲍勃和Mira的眼睛都盯在后台数据库服务器上了。
　　
　　测试环境下正常
　　
　　Mira带领开发小组对服务器进行了测试。测试方法是将所有数据从生产服务器复制到测试服务器，并优化测试服务器，然后在生产服务器上重现。模拟测试环境下，测试结果表明，SQL 服务器上的吞吐量需求并未在性能上产生瓶颈。这是因为在非生产环境中完成了自定义工作，并测试过系统。大多数测试环境不能复制生产环境所包含的拓扑结构和硬件配置，所以只能使用备份还原过程或Planning 镜像技术，因而存在了迁移的差异性。
　　虽然此过程可以消除对生产服务器的性能影响，但这不是最佳解决方案。在模拟测试环境下，测试结果令人非常满意，一旦放在生产网络上运行一段时间，系统就开始慢如“牛车”。看来，鲍勃必须对生产网络中的服务器进行性能监控和调优了。
　　非常可惜的是，他们并没有专门的数据库管理员（DBA），这也是很多成长型企业IT部门的通病。如果有一名专职的DBA，他一定知道如何做好数据库的管理工作，并为开发人员提供协助。
　　Mira以前做过一些SQL 2000数据库维护工作，因此由她暂时来负责数据库的优化工作。她已经注意到，SQL Server服务器的性能监视器反映出来的CPU使用率达到峰值、内存消耗过度等问题导致的整体性能下降，但还无法推断出导致性能异常的最终原因。在SQL Server 2005问世以前，Mira必须使用Profiler来跟踪性能异常，然后在Enterprise Manager中查看系统进程，最后查看性能监视器日志。完成上述任务后，还需要手动协调各个工具，以确定性能降低的原因。这就意味着需要费劲地逐个查看每个工具的日志。虽然这个过程很乏味，但Mira觉得，要了解出现性能问题的根本原因，就必须如此操作。
　　
　　索引和碎片的问题
　　
　　她向很多DBA朋友发送了Mail，还向一些经常出入的论坛发出了帮助请求。Mira收到回复的信件中，关于索引问题的建议非常多。因为索引编制可能是决定访问数据所需锁数量的关键因素，编制正确的索引可以减少数据库引擎必须执行的内部查找次数，从而减少查询访问的记录数。碎片可能是一个隐含的问题根源。如果碎片过多，数据库引擎可能需要访问比采用其他方式更多的页面。此外，不正确的统计信息也可能会导致查询优化器选择效率不高的路径。
　　管理员可以使用SQL Server提供的一种简化并自动维护数据库的工具——数据库维护计划向导（Database Maintenance Plan Wizard ，DMPW），它包括了对索引的优化。运行这个向导后，Mira看到数据库中关于索引的统计量，这些统计量作为日志并定时更新，这样就减轻了手工重建索引所带来的工作量。这里提示一下读者，如果你不想自动定期刷新索引统计量，你还可以在DMPW中选择重新组织数据和数据页，这将停止旧有索引并按特定的填充因子重建索引。
　　
　　针对查询效率的优化
　　
　　有效的优化、不优化或错误优化三者之间的差别，可能会让程序执行速度差别几十倍甚至几百倍。前面已经提到，用户提交查询之后，才明显感到系统缓慢，因此我们就数据库的查询优化给鲍勃提一些建议。查询优化在提高性能方面起着举足轻重的作用，查询优化的方法有：缩短事务、对事务进行排序、使用锁定提示。
　　这家公司订单系统的数据列的属性实在太多了。SQL 将每个语句都作为隐式事务，如果该语句影响到大段的程序，则单一语句仍可构成一个大型事务，尤其是当涉及许多列时或列中包含大量数据时更是如此。
　　最终，Mira提交给鲍勃一份非常完整的服务器优化报告，问题正在处理中。比较确定的是，他们需要对系统来个智能扫描，给数据库做一个“全身检查”。