需求描述缓存
在生产环境中，不少状况下须要采集数据，用以定位问题或者造成基线。服务器
关于SQL Server中的数据采集有着不少种的解决思路，能够采用Trace、Profile、SQLdiag、扩展事件等诸多方案。网络
几种方案各有利弊，其中从SQL Server2012版本开始，微软的开始各类整合这些采集方案，力推扩展事件。运维
对于上述的数据采集只是一种实现手段，对于采集完数据的存储没有统一的规范，而且对于多服务器的数据采集及汇总没造成统一的规范。工具
本篇实现post
一、经过SQL Server自带的数据采集器实现多服务器的性能采集性能
二、利用SQL Server数据采集数据仓库（DW）造成运维报表url
三、经过灵活性的配置方式，实现不一样服务器不一样采集点的数据收集
<1>基础配置
之前，有个同事说SQL Server的自动化运维太弱了，而且定位问题也比较麻烦，须要记住各类系统的DMV....各类日志查找....你看看人家MySQL强大的图形化界面提示，让你一眼就能发现当前数据库所存在的问题。
的确，来看看MySQL所提供的图形化的运维界面
是他娘的帅气，把总体的平台给划分的很详细：网络、实例状态、存储状态。
并且还有看上去很优雅的图形化展现界面。
上述界面所反映的内容，对于问题的查找是至关便利的，在SQL SERVER中就找不到一样的模块。若是有经验的DBA会经过任务管理器、性能监视器、而后配合系统自带个一些个DMV...进行分析....看上去复杂而且很高深的样子。
其实，在SQL SERVER中，也有相似的功能模块，而且更灵活的实现多台服务器共同采集，下面，咱们来看一下详细的使用和配置流程。
在数据收集上，右键选择“配置管理数据仓库”
SQL SERVER为了可以支撑多台服务器的数据采集任务，鉴于数据量的庞大和用于数据分析的重要性，因此本身建立了一个用于数据分析的数据仓库（DW）
这里选择好实例，建立好数据仓库就能够。
提示：为了不影响生产系统的性能，通常这里建议采用另一台空闲的实例，专门用于数据采集和性能分析。
我这里演示，就采用本地的实例进行配置，而后下一步：
到这一步是管理数据仓库的用户权限，能够配置用户权限，三种权限级别：管理员、可读、可写；
很简单，配置完成直接下一步，而后就完成了该数据采集的数据仓库的搭建。
<2>基础配置
这一步就是设置数据收集了，简单点讲就是要配置收集的数据项有哪些。
一样是，数据采集上右键，而后选择“设置数据采集”
而后，下一步就是链接数据仓库，选择缓存目录
而后，下一步就能够完成，这里SQL SERVER一样的内置了一套数据搜集的模板，会为你收集所有的基本信息，固然，也能够自定义，文章后面介绍。
来看默认的数据采集的收集项
自带的默认模板中，分为了查询统计信息，其实这个就对应的实例状态、磁盘存储、服务器活动，除了这下还赠送了一个实用工具信息，这个是用来灵活配置其它几个收集项的。
能够随时的根据我的喜爱启动、中止数据收集动做，酌情采用。
而且，也能够本身配置收集动做的时间间隔或者状态值。
而且，SQL Server贴心的给内置了一下计划模板，基本涵盖了全部的应用场景。
而后，你就放心的让它本身去采集就能够了。不爽的时候随时中止就能够。
剩下来的事就是查看采集数据了，鉴于MYSQL提供了如此精美的图像化展示方式，SQL SERVER一样也有。
就是它了
看上去是否是也有那么点意思了，包括：CPU、内存、磁盘IO、网络...
而且顺带着SQL server等待、SQL语句执行状况等
而后，针对性能调优的一些语句，也给出了排序包括CPU、运行时间、IO总数、物理读取、逻辑读取等
固然，我本地的机器自己采集量就不多，而且运行的T-SQL语句就很少，因此图表工具显示的很空旷。
来看看磁盘存储的
上述内容大致就这些，本身用的时候再行挖掘吧，本篇提供思路。
若是经验老道的DBA，我估计上述语句经过系统的DMV均可以查看的到，可是那仅限于有经验的，上述方案为小白下降了维护数据库的成本。
而且能够在多台服务器中进行采集，集中处理问题。
结语
在本篇介绍利用SQL Server自带的数据收集工具进行数据库运维。关于自定义的数据收集项设置，后一篇介绍吧。
另外关于数据收集的DW有不少颇有用的内容，若是对于大型的平台性能运维，能够借此扩展，造成本身的运维平台。
关于SQL Server自动化运维和检测的内容很普遍，其中不少都是从平常的经验中出发，一步步的从手动到自动的过程。
若是您看了本篇博客,以为对您有所收获，请不要吝啬您的“推荐”。