SQL Server自动化运维系列——关于数据收集(多服务器数据收集和性能监控)
2016-06-02 21:25
267 查看
需求描述
在生产环境中,很多情况下需要采集数据,用以定位问题或者形成基线。
关于SQL Server中的数据采集有着很多种的解决思路,可以采用Trace、Profile、SQLdiag、扩展事件等诸多方案。
几种方案各有利弊,其中从SQL Server2012版本开始,微软的开始各种整合这些采集方案,力推扩展事件。
对于上述的数据采集只是一种实现手段,对于采集完数据的存储没有统一的规范,并且对于多服务器的数据采集及汇总没形成统一的规范。
本篇实现
1、通过SQL Server自带的数据采集器实现多服务器的性能采集
2、利用SQL Server数据采集数据仓库(DW)形成运维报表
3、通过灵活性的配置方式,实现不同服务器不同采集点的数据收集
<1>基础配置
以前,有个同事说SQL Server的自动化运维太弱了,并且定位问题也比较麻烦,需要记住各种系统的DMV....各种日志查找....你看看人家MySQL强大的图形化界面提示,让你一眼就能发现当前数据库所存在的问题。
的确,来看看MySQL所提供的图形化的运维界面
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/9b7530553423c73764fa33237076e59a)
是他娘的帅气,把整体的平台给划分的很详细:网络、实例状态、存储状态。
而且还有看上去很优雅的图形化展示界面。
上述界面所反映的内容,对于问题的查找是相当便利的,在SQL SERVER中就找不到同样的模块。如果有经验的DBA会通过任务管理器、性能监视器、然后配合系统自带个一些个DMV...进行分析....看上去复杂并且很高深的样子。
其实,在SQL SERVER中,也有类似的功能模块,并且更灵活的实现多台服务器共同采集,下面,我们来看一下详细的使用和配置流程。
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/1a972ae9c45f7fb7aaad91dd9ce58b05)
在数据收集上,右键选择“配置管理数据仓库”
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/0c8b016f4c0b0687a382f315d712766a)
SQL SERVER为了能够支撑多台服务器的数据采集任务,鉴于数据量的庞大和用于数据分析的重要性,所以自己创建了一个用于数据分析的数据仓库(DW)
这里选择好实例,创建好数据仓库就可以。
提示:为了避免影响生产系统的性能,一般这里建议采用另外一台空闲的实例,专门用于数据采集和性能分析。
我这里演示,就采用本地的实例进行配置,然后下一步:
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/eab327e2553fc9af4e19adeabd36402b)
到这一步是管理数据仓库的用户权限,可以配置用户权限,三种权限级别:管理员、可读、可写;
很简单,配置完成直接下一步,然后就完成了该数据采集的数据仓库的搭建。
<2>基础配置
这一步就是设置数据收集了,简单点讲就是要配置收集的数据项有哪些。
同样是,数据采集上右键,然后选择“设置数据采集”
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/5a8a58ce2a522b2f3333bfbce6b1189d)
然后,下一步就是连接数据仓库,选择缓存目录
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/34fee14ebc6b2e9365ad57945bad7cbf)
然后,下一步就可以完成,这里SQL SERVER同样的内置了一套数据搜集的模板,会为你收集全部的基本信息,当然,也可以自定义,文章后面介绍。
来看默认的数据采集的收集项
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/2079e2c245157a3cfa2e3e594b52d513)
自带的默认模板中,分为了查询统计信息,其实这个就对应的实例状态、磁盘存储、服务器活动,除了这下还赠送了一个实用工具信息,这个是用来灵活配置其它几个收集项的。
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/5331faba9c688bcb1ead853d8e492761)
可以随时的根据个人喜好启动、停止数据收集动作,酌情采用。
并且,也可以自己配置收集动作的时间间隔或者状态值。
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/558a625879a12101b8b5c23c207d9287)
并且,SQL Server贴心的给内置了一下计划模板,基本涵盖了所有的应用场景。
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/120a8b0cc5a1f8cefe5f4ca84a015a37)
然后,你就放心的让它自己去采集就可以了。不爽的时候随时停止就可以。
剩下来的事就是查看采集数据了,鉴于MYSQL提供了如此精美的图像化展现方式,SQL SERVER同样也有。
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/69ed667cd4ce809fbd759726d382bde0)
就是它了
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/bb9520adce60f4f43b039d3a5b365c04)
看上去是不是也有那么点意思了,包括:CPU、内存、磁盘IO、网络...
并且顺带着SQL server等待、SQL语句执行情况等
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/ebd68bf549b7426649accf6577ed1291)
然后,针对性能调优的一些语句,也给出了排序包括CPU、运行时间、IO总数、物理读取、逻辑读取等
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/8b6154700aa93d27d6269ba11f8c8443)
当然,我本地的机器本身采集量就很少,并且运行的T-SQL语句就不多,所以图表工具显示的很空旷。
来看看磁盘存储的
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/21/7cb2661c944afbee4a7331a616371abe)
上述内容大体就这些,自己用的时候再行挖掘吧,本篇提供思路。
如果经验老道的DBA,我估计上述语句通过系统的DMV都可以查看的到,但是那仅限于有经验的,上述方案为小白降低了维护数据库的成本。
并且可以在多台服务器中进行采集,集中处理问题。
结语
在本篇介绍利用SQL Server自带的数据收集工具进行数据库运维。关于自定义的数据收集项设置,后一篇介绍吧。
另外关于数据收集的DW有很多很有用的内容,如果对于大型的平台性能运维,可以借此扩展,形成自己的运维平台。
关于SQL Server自动化运维和检测的内容很广泛,其中很多都是从日常的经验中出发,一步步的从手动到自动的过程。
在生产环境中,很多情况下需要采集数据,用以定位问题或者形成基线。
关于SQL Server中的数据采集有着很多种的解决思路,可以采用Trace、Profile、SQLdiag、扩展事件等诸多方案。
几种方案各有利弊,其中从SQL Server2012版本开始,微软的开始各种整合这些采集方案,力推扩展事件。
对于上述的数据采集只是一种实现手段,对于采集完数据的存储没有统一的规范,并且对于多服务器的数据采集及汇总没形成统一的规范。
本篇实现
1、通过SQL Server自带的数据采集器实现多服务器的性能采集
2、利用SQL Server数据采集数据仓库(DW)形成运维报表
3、通过灵活性的配置方式,实现不同服务器不同采集点的数据收集
<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自动化运维和检测的内容很广泛,其中很多都是从日常的经验中出发,一步步的从手动到自动的过程。
相关文章推荐
- sql语句中----删除表数据drop、truncate和delete的用法
- _mysql.c(42) : fatal error C1083: Cannot open include file: 'config-win.h':no such file or directory
- SQLite3的使用(用到了dll)good
- sqoop从hbase导出数据到mysql
- Golang MySQL存储过程的使用
- 大话架构师之NOSQL和缓存
- SQL Server 2016新特性:DROP IF EXISTS
- Android SQLite Google 官方用法
- win7 中使用PLSQL Developer的配置方法
- MySQL(Navicat)运行.sql文件时报错:[Err] 2006 - MySQL server has gone away 的解决方法
- mysql 监控 sql执行语句
- MYSQL企业常见架构与调优
- SQL Server 2016新特性: In-Memory OLTP
- 大话架构师之分布式存储--mysql
- zabbix自带监控mysql
- Oracle GoldenGate 异构平台同步(Mysql到Oracle)
- SQL 中GO、EXEC、ON
- 《MySQL性能调优与架构设计》读书笔记(一)
- 配置PL-SQLDeveloper
- PLSQL Developer win7 64位 安装方法