标签：引擎 性能 profile 物理 监控 而不是 数据 策略 重复
本文将根据“数据库引擎优化顾问”（DTA）来发现无用或缺失的索引。
要使用“数据库引擎优化顾问”，首先需要对数据库负载进行监控，为数据库负载分析准备数据。从SSMS的工具中，打开SQL Server Profile，输入安全连接方式。在常规的标签下，模板选择“Standard（默认值）”，事件选择标签下，选择事件Stored Procedures→RPC：Completed；TSQL→SQL：BatchCompleted，SQL：BatchStarting，点击运行。如下图所示：
监控一段时间后，停止运行，将跟踪文件保存为trace.trc
在SSMS的工具下，打开“数据库引擎优化顾问”，建立安全连接，如下图。在“工作负荷”下选择跟踪文件所在的路径，选择“工作负荷分析的数据库”，这里我选择的tempdb；最后选择需要优化的数据库和表。
在优化选项中，“限定优化时间”可以不选，或者自己设定结束时间；“在数据库中使用的物理设计结构（PDS）”，选择“索引和索引视图(D）”；“使用的分区策略”选择“对齐分区（A）”；在数据库中保留的物理设计结构（PDS），我选择了“保留对齐分区（R）”，设定如下：
点击开始运行后，获得如下建议
通过测试可以了解到，最终的索引或分区建议，与Profile追踪的时间长短、时间段有关。如果工作负载不代表该数据库的典型工作负载，并且缺少重要的查询，那么索引建议也将是不完整的、不准确的或完全错误的。使用该方法的要求是：
在不影响生产环境的性能的情况下，尽可能的延长跟踪时间，搜集较多的事件；
将需要优化的数据库备份，还原到非生产环境服务器，进行分析（因为保证1的情况下，数据量会非常大，在原生产环境进行分析，会消耗大量的生产环境的资源CPU、IO，降低生产环境的性能，影响业务）
比较动态视图和数据库引擎优化顾问，两者的共同缺点都是可能因搜集的信息不全，导致建议不准确， 所以无论使用动态视图，还是使用数据库引擎优化顾问，其建议都需要审慎使用。
最后再重申一遍，虽然这些特性在确定可能对数据库有益的索引时非常有用，但它们也可能是一把双刃剑，在错误使用时弊大于利。盲目地实现这些特性的建议几乎总是会导致数据库中的索引重复或重叠，以及索引太多而不是太少。
标签：引擎 性能 profile 物理 监控 而不是 数据 策略 重复
原文地址：https://www.cnblogs.com/footleg/p/12053819.html
