测试环境下正常
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提交给鲍勃一份非常完整的服务器优化报告，问题正在处理中。比较确定的是，他们需要对系统来个智能扫描，给数据库做一个“全身检查”。
文章来源于领测软件测试网 https://www.ltesting.net/
