sql性能监控
‘壹’ 如何监视和查看sql server的性能
1、用SQL语句：select count(*) from master.dbo.sysprocesses 或者 sp_who 2、用管理界面： SQL2000：进入企业管理器，管理——当前活动——进程信息 SQL2005：进入manager studio ，展开对象管理器，管理——右键“活动监视器”——查看进程 SQL2008：进放manager studio 在菜单栏下面有一行图标，点击最后一个图标“活动监视器”，进入活动监视器的界面后，点击“进程”.
‘贰’ sql server性能监控指令~~
1. 监控事例的等待
select event，sum(decode(wait_Time，0，0，1)) "Prev"，
sum(decode(wait_Time，0，1，0)) "Curr"，count(*) "Tot"
from v$session_Wait
group by event order by 4;
2. 回滚段的争用情况
select name， waits， gets， waits/gets "Ratio"
from v$rollstat a， v$rollname b
where a.usn = b.usn;
3. 监控表空间的 I/O 比例
select df.tablespace_name name，df.file_name "file"，f.phyrds pyr，
f.phyblkrd pbr，f.phywrts pyw， f.phyblkwrt pbw
from v$filestat f， dba_data_files df
where f.file# = df.file_id
order by df.tablespace_name;
4. 监控文件系统的 I/O 比例
select substr(a.file#，1，2) "#"， substr(a.name，1，30) "Name"，
a.status， a.bytes， b.phyrds， b.phywrts
from v$datafile a， v$filestat b
where a.file# = b.file#;
5.在某个用户下找所有的索引
select user_indexes.table_name， user_indexes.index_name，uniqueness， column_name
from user_ind_columns， user_indexes
where user_ind_columns.index_name = user_indexes.index_name
and user_ind_columns.table_name = user_indexes.table_name
order by user_indexes.table_type， user_indexes.table_name，
user_indexes.index_name， column_position;
6. 监控 SGA 的命中率
select a.value + b.value "logical_reads"， c.value "phys_reads"，
round(100 * ((a.value+b.value)-c.value) / (a.value+b.value)) "BUFFER HIT RATIO"
from v$sysstat a， v$sysstat b， v$sysstat c
where a.statistic# = 38 and b.statistic# = 39
and c.statistic# = 40;
7. 监控 SGA 中字典缓冲区的命中率
select parameter， gets，Getmisses ， getmisses/(gets+getmisses)*100 "miss ratio"，
(1-(sum(getmisses)/ (sum(gets)+sum(getmisses))))*100 "Hit ratio"
from v$rowcache
where gets+getmisses <>0
group by parameter， gets， getmisses;
8. 监控 SGA 中共享缓存区的命中率，应该小于1%
select sum(pins) "Total Pins"， sum(reloads) "Total Reloads"，
sum(reloads)/sum(pins) *100 libcache
from v$librarycache;
select sum(pinhits-reloads)/sum(pins) "hit radio"，sum(reloads)/sum(pins) "reload percent"
from v$librarycache;
9. 显示所有数据库对象的类别和大小
select count(name) num_instances ，type ，sum(source_size) source_size ，
sum(parsed_size) parsed_size ，sum(code_size) code_size ，sum(error_size) error_size，
sum(source_size) +sum(parsed_size) +sum(code_size) +sum(error_size) size_required
from dba_object_size
group by type order by 2;
10. 监控 SGA 中重做日志缓存区的命中率，应该小于1%
SELECT name， gets， misses， immediate_gets， immediate_misses，
Decode(gets，0，0，misses/gets*100) ratio1，
Decode(immediate_gets+immediate_misses，0，0，
immediate_misses/(immediate_gets+immediate_misses)*100) ratio2
FROM v$latch WHERE name IN ('redo allocation'， 'redo ');
11.监控内存和硬盘的排序比率，最好使它小于 .10，增加 sort_area_size
SELECT name， value FROM v$sysstat WHERE name IN ('sorts (memory)'， 'sorts (disk)');
12. 监控当前数据库谁在运行什么SQL语句
SELECT osuser， username， sql_text from v$session a， v$sqltext b
where a.sql_address =b.address order by address， piece;
13. 监控字典缓冲区
SELECT (SUM(PINS - RELOADS)) / SUM(PINS) "LIB CACHE" FROM V$LIBRARYCACHE;
SELECT (SUM(GETS - GETMISSES - USAGE - FIXED)) / SUM(GETS) "ROW CACHE" FROM V$ROWCACHE;
SELECT SUM(PINS) "EXECUTIONS"， SUM(RELOADS) "CACHE MISSES WHILE EXECUTING" FROM V$LIBRARYCACHE;
后者除以前者，此比率小于1%，接近0%为好。
SELECT SUM(GETS) "DICTIONARY GETS"，SUM(GETMISSES) "DICTIONARY CACHE GET MISSES"
FROM V$ROWCACHE
14. 找ORACLE字符集
select * from sys.props$ where name='NLS_CHARACTERSET';
15. 监控 MTS
select busy/(busy+idle) "shared servers busy" from v$dispatcher;
此值大于0.5时，参数需加大
select sum(wait)/sum(totalq) "dispatcher waits" from v$queue where type='dispatcher';
select count(*) from v$dispatcher;
select servers_highwater from v$mts;
servers_highwater接近mts_max_servers时，参数需加大
‘叁’ 如何监控sqlserver 性能 死锁
具体步骤如下：
1.首先使用下面的命令，将有关的跟踪标志启用。
SQL codeDBCC TRACEON (3605,1204,1222,-1)
说明：
3605
将DBCC的结果输出到错误日志。
1204 返回参与死锁的锁的资源和类型，以及受影响的当前命令。
1222
返回参与死锁的锁的资源和类型，以及使用了不符合任何 XSD 架构的 XML 格式的受影响的当前命令(比1204更进一步,SQL
2005及以上可用)。
-1 以全局方式打开指定的跟踪标记。
以上跟踪标志作用域都是全局，即在SQL
Server运行过程中，会一直发挥作用，直到SQL Server重启。
如 果要确保SQL Server在重启后自动开启这些标志，可以在SQL
Server服务启动选项中，使用 /T 启动选项指定跟踪标志在启动期
间设置为开。(位于SQL Server配置管理器->SQL
Server服务->SQL Server->属性->高级->启动参数)
在运行上面的语句后，当SQL
Server中发生死锁时，已经可以在错误日志中看到了，但还不够直观(和其它信息混在一起)。（SSMS
-> SQL Server实例 ->
管理 -> SQL Server日志）
2.建表，存放死锁记录
SQL codeUSE [Cole] --Cole是我的示例数据库，你可以根据实际情况修改。 GO
CREATE TABLE DeadLockLog ( id int IDENTITY (1, 1) NOT NULL, LogDate DATETIME, ProcessInfo VARCHAR(10), ErrorText VARCHAR(MAX) )
GO
3.建立JOB
新建一个JOB（假设名称为DeadLockJob）,在"步骤"中新建一步骤，随便写一个步骤名称，数据库为"Cole",在"命令"栏中输入以下语句：
SQL code--新建临时表 IF OBJECT_ID('tempdb.dbo.#ErrorLog') IS Not Null
DROP TABLE #ErrorLog
CREATE TABLE #ErrorLog (Id int IDENTITY (1, 1) NOT NULL, a DATETIME, b VARCHAR(10), c VARCHAR(MAX)) --将当前日志记录插入临时表
INSERT INTO #ErrorLog EXEC master.dbo.sp_readerrorlog --将死锁信息插入用户表
insert DeadLockLog
select a, b, c from #ErrorLog where id >= (select MAX(id) from #ErrorLog WHERE c Like '%Deadlock encountered%')
DROP TABLE #ErrorLog
4.新建警报
在"新建警报"窗体的"常规"选项卡中,进行以下设置：
名称：可根据实际自行命名，这里我用DeadLockAlert
类型：选择"SQL
Server性能条件警报"
对象：SQLServer:Locks
计数器：Number of
Deadlocks/sec
实例：_Total
计数器满足以下条件时触发警报：高于
值：0
在"响应"选项卡中，选中"执行作业"，并选择步骤3中我们新建的作业(即DeadlockJob)
到这里为止，我们已经完成了全部步骤，以后，你就可以随时查询DeadLockLog表，来显示死锁信息了。
‘肆’ 100ms的SQL把服务器搞崩溃了
一个项目上线了两个月，除了一些反馈的优化和小Bug之外，项目一切顺利；前期是属于推广阶段，可能使用人员没那么多，当然对于项目部署肯定提前想到并发量了，所以早就把集群安排上，而且还在测试环境搞了一下压测，绝对是没得问题的；但是，就在两个月后的一天，系统突然跑的比乌龟还慢，投诉开始就陆续反馈过来了。
经过排查，原来是频繁执行一条耗时100ms的SQL导致，100ms感觉不长，但就是把系统搞崩了，具体细节如下。
项目采用ABP进行开发，集成统一的认证中心(IDS4)，部分数据对接第三方系统，拆分后的这个项目架构相对简单。
考虑并发量不高，就算是高峰期也不会超过1000，于是就搞了个单台的数据库服务器(MySQL)，测试环境中经过压测，完全能抗住。
上线时，由于线上资源的关系，DB服务器的配置没有按测试环境的标准来分配，相关人员想着后续看情况进行补配。上线推的比较紧，简单评估了配置风险，初步判断没啥大问题，于是就推上线了。
相关技术栈：ABP、IdentityServer4、Autofac、AutoMapper、Quartz.NET、EF Core、Redis、MySQL等，这都不重要，重要的是100ms的SQL把系统搞崩了。
由于系统相对不大，并没有把分布式日志、调度监控，性能监控集成上去。
上线期间，前期处于使用推广阶段，一切正常。两个月后的一天，系统处于使用高峰时段，突然陆续收到反馈：系统有点卡！！！于是赶紧进行排查。
由于系统已经是集群部署的，慢这个问题首先怀疑是数据库服务器，于是让DBA的同事排查了一下，没有锁，只是有大量事务等待提交(waiting for handler commit)，通过如下命令可查的：
看到都是插入审计日志记录导致，一看日志记录频率，差不多一秒500条记录。DBA同事说可能是记录插入频繁导致，此时CPU已经爆到100%了，为了快速解决问题，于是就赶紧关掉了一些不必要的日志记录。
这么一改，稍微降了一点，没有事务提交的记录，系统勉强可以撑着用，但是CPU还是在85%~97%波动；
看到这种情况，当然还是不放心，继续排查。 中间有对服务器的配置产生过怀疑，但非常肯定的是这不是主要原因，于是和DBA的同事继续排查。
系统虽然可以正常使用，但时不时的也看看监控屏，CPU一直处于高水位状态，还是有点慌的，因为一有问题，信息和电话都要爆。
突然DBA同事发现有一个单表查询的SQL执行比较频繁，于是单独拿出来试了一下，查询时间150ms左右，这个表的数据量不大，8万左右，但没有加任何索引，因为想着数据量不大，查询时长还可接受，所以当时就没有加相关索引。
定位到这条SQL后，想到的第一步就是增加索引，在测试环境上试了一把，执行效率直接飞速提高到1ms；效果如下：
所以和DBA同事达成一致意见，在生成环境上增加复合索引( 创建索引一定要注意字段顺序 )，在中午时候，系统使用频率不太高，于是就在生成上快速加了索引，我去，CPU一下降到了20%以内，意不意外；就算在使用高峰期，也没超过20%，通过zabbix工具监控看到CPU的效果：
问题算是解决了，总算松了一口气。
这里有个问题： CPU都爆了为什么没有报警提醒，这块DBA同事正在排查相关配置。这里发现CPU爆了，还是无意的远程到服务器，发现很卡，一看CPU才知道爆了。
系统虽小，问题不大，但其实暴露的问题还是挺多。
这次线上小事故暂时分享到这，因为项目不大，所以没有做那么多监控，但以下建议，小伙伴可以参考一下：
文章来自https://www.cnblogs.com/zoe-zyq/p/16207287.html
‘伍’ sql server数据库性能监控指令，请大虾帮忙~~
连接到数据库的会话数量，数据文件/日志文件大小这两个是可以直接从界面上设置，别的就不知道了，没用过希望高手进来，顶上哈哈。