SQL Nexus

在前面的SQLdiag系列中有提到SQLNexus，当时我们用SQLNexus查看了Perfmon Summary(性能计数器)、ReadTrace Reports(跟踪文件)两项报表。SQLNexus将SQL跟踪数据、性能监视器日志以及各种T-SQL脚本的输出聚合到单个SQL Server数据库中。
这一篇将以生产环境中收集的数据来分析SQLNexus的各个报表。SQLdiag收集数据导入到SQLNexus后的总界面如下：

报表是否可用是根据对应数据表是否有记录来判断，下图是打开主界面的跟踪脚本运行的结果：

图中蓝底纹的数据表在库下没有创建，因此对应的报表不可用。可用报表数据来源文件如下：
1>Loaded Modules
数据来自*sp_sqldiag_Shutdown.OUT
2>Perfmon Summary
数据来自SQLDIAG.BLG
3>ReadTrace Reports
数据来自*sp_trace.trc
4>Missing Indexes/Indexes and Stats
数据来自*Perf_Stats_Snapshot_Startup.OUT
5>其他可用
数据来自*Perf_Stats_Startup.OUT
按照SQLdiag->PerfMon->Perf_Stats->Perf_Stats_Snapshot逐一导入数据，对比表中数据与收集文件中的数据，分析各文件对应数据表：
注意：Perfmon Summary报表数据展现需从[dbo].[tbl_XPMSVER]表取ProcessorCount，而[dbo].[tbl_XPMSVER]表的数据来自*sp_sqldiag_Shutdown.OUT。对于上述图片中Descript为空的表可以开启跟踪，查看表是如何创建以及如何导入数据。
Perfmon Summary、ReadTrace Reports参考之前的SQLdiag和RML文章，Blocking and Wait Statistics(阻塞和等待)报表界面如下：

Top Wait Categories的数据来自表tbl_OS_WAIT_STATS；Blocking Chains的数据来自表tbl_BLOCKING_CHAINS。
Bottleneck Analysis(瓶颈分析)报表界面如下：

System CPU Utilization的数据来自表tbl_SQL_CPU_HEALTH；Bottleneck Analysis大部分数据来自表tbl_OS_WAIT_STATS(sys.dm_os_wait_stats)，注意底部的Wait Category项目的CPU项，过程描述是Add SOS_SCHEDULER_YIELD wait time (waiting to run on a CPU) to actual used CPU time to synthesize a "CPU" wait category.而Actual_used_CPU_time=[CPU个数(tbl_SYSINFO.cpu_count)*时间间隔(s)*平均CPU使用率(tbl_SQL_CPU_HEALTH.sql_cpu_utilization)*单位换算]
本例中Actual_used_CPU_time=2*11025*4%*1000=882000(ms)，SOS_SCHEDULER_YIELD=235886(ms)
Other项是don't include the categories that we are already identifying in the top 5.SOS_SCHEDULER_YIELD也归结到Other项。Wait_Time(ms)_per_Sec=Total_Wait_Time_ms/Time_Interval_Sec,%Total_Wait_Time_ms=Single Total_Wait_Time_ms/Total Total_Wait_Time_ms.
因此表格中除CPU以外的项Total_Wait_Time_ms相加，对应是这段时间内sys.dm_os_wait_stats的增量。CPU是单独的项，我们移动鼠标到其上是不能跳转到明细数据的，其他项可以跳转到对应的Wait Details：

图中Wait over Time折线图对应中间的View Details，点开加号(+)可以查看详细快照数据：

明细来自表tbl_OS_WAIT_STATS(sys.dm_os_wait_stats)中特定wait_category的数据。Wait Details的下半部分数据来自表tbl_REQUESTS对应wait_category的数据，注意如果点击Bottleneck Analysis->Other，由于它传递的wait_category = 'Other'，导致对应的Wait Details界面没有数据，实际应该传递wait_category not in(top 5)
Spinlock Statistics Report(自旋锁)界面如下：

自旋锁：类似闩锁(当数据页从磁盘读取前，数据库引擎会先在内存中预留适当的内存页，给这些内存加闩锁，数据才能顺利地读到内存。如果一个线程没法立即获得闩锁，线程则等待，让CPU给其他线程使用)，不同闩锁的是：如果一个线程没法立即获得自旋锁，线程则开始轮询，重复检查资源是否可用以继续使用。当然也不会长时间轮询，不久就会让出CPU给其他线程使用。SQLSERVER选择让线程在CPU上稍微等一会(所谓自旋)，而不是将CPU资源让出来。由于资源很快能够得到，这样处理能够减少CPU上线程的切换，更有效率(Windows也是这样做的减少线程切换的开销，经常切换线程上下文是很耗费CPU资源的)
对自旋锁故障排除的主要DMV是sys.dm_os_spinlock_stats。这个DMV里返回的每一行都代表SQL Server里的一个自旋锁。

select * from sys.dm_os_spinlock_stats
dbcc sqlperf(spinlockstats)
--name：自旋锁名称
--collision：当尝试访问保护的数据结构时，被自旋锁阻塞的线程次数
--spins：在循环里尝试获得自旋锁的自旋锁线程次数
--spins_per_collision：旋转和碰撞之间的比率
--sleep_time：因为退避线程休眠时间
--backoffs：为了其他线程在CPU上继续，线程退避次数

上述报表就是利用表tbl_SPINLOCKSTATS(sys.dm_os_spinlock_stats)最晚记录与最早记录的差值，计算指定时间内自旋锁申请和阻塞情况。
其他报表(Loaded Modules、Missing Indexes、Virtual File Stats 、Indexes and Stats、Memory Brokers)都是以表格形式返回数据，在此就不详细描述。附上部分SQL Nexus Reports调用过程/表：

----SQL Nexus Reports调用过程/表情况
/****Loaded Modules****/
if object_id('dbo.tbl_loaded_modules') is not null
begin
    select * from tbl_loaded_modules
    order by case when Company like 'Microsoft%' then 1 else 0 end, name
end

/****Blocking and Wait Statistics****/
--Top Wait Categories
EXEC DataSet_WaitStatsMain_WaitStatsChart '2016-01-13T13:14:06.000', '2016-01-13T16:17:51.000'
EXEC DataSet_WaitStats_WaitStatsTop5Categories '2016-01-13T13:14:06.000', '2016-01-13T16:17:51.000'
--Blocking Chains
EXEC DataSet_WaitStats_BlockingChains '2016-01-13T13:14:06.000', '2016-01-13T16:17:51.000'

/****Bottleneck Analysis****/
--System CPU Utilization
SELECT EventTime,record_id, system_idle_cpu, sql_cpu_utilization, 100 - sql_cpu_utilization - system_idle_cpu AS nonsql_cpu_utilization 
  FROM tbl_SQL_CPU_HEALTH  
 WHERE EventTime >= '2016-01-13T13:14:06.000'
 ORDER BY EventTime
--Bottleneck Analysis
EXEC DataSet_WaitStats_WaitStatsTop5Categories '2016-01-13T13:14:06.000', '2016-01-13T16:17:51.000'

/****Missing Indexes****/
if object_id('tbl_missingindexes') is not null
select top 20 Create_index_statement, improvement_measure, user_seeks, user_scans
from tbl_missingindexes
order by improvement_measure DESC

/****Virtual File Stats****/
if object_id('dbo.DataSet_GetSnapshot') is not null
begin
    exec DataSet_GetSnapshot 'tbl_FileStats', 178
end

/****Indexes and Stats****/
--Index and Statistics Summary
select dbid, MAX(row_mods) 'MaxRowMods', MIN(stats_updated) 'EarliestStatsUpdated', MAX(stats_updated) 'LatestStatsUpdated', COUNT (case when norecompute<>'no' then 1 else null end) 'NumberOfNoRecmpute'
from tbl_SysIndexes
group by dbid
order by CAST(dbid as int)
--Index and Statistics Details
select dbid, objname, type, idxname, stats_updated, [norecompute]  from tbl_SysIndexes 
order by CAST(dbid as int), cast (stats_updated as datetime)

代码仅仅大致提取跟踪脚本，详细逻辑请自行参考实例跟踪。