MSSQL编程：statspack呈报数据了局注释

Mysql的存储引擎接口定义良好。有兴趣的开发者可以通过阅读文档编写自己的存储引擎。数据
这篇文章来自于oracle中国用户组(www.ckuyun.com.cn)的文章，发明对本人进修功能调优很有匡助:

原文链接:http://www.cnoug.org/viewthread.php?tid=25353

statspack呈报数据了局注释

自己将比来在进修功能调优时，所用条记总结以下，接待品评斧正
本文将不休更新，接待增补。（所列数据仅用于便于申明，没有实
际意义）

1、statspack输入了局中必需检察的十项内容

1、负载间档(Loadprofile)
2、实例效力点击率(Instanceefficiencyhitratios)
3、主要的5个守候事务(Top5waitevents)
4、守候事务(Waitevents)
5、闩锁守候
6、主要的SQL(Topsql)
7、实例举动(Instanceactivity)
8、文件I/O(FileI/O)
9、内存分派(Memoryallocation)
10、缓冲区守候(Bufferwaits)

2、输入了局注释

1、报表头信息
数据库实例相干信息，包含数据库称号、ID、版本号及主机等信息


Quote:STATSPACKreportfor

DBNameDBIdInstanceInstNumReleaseClusterHost
-------------------------------------------------------------------------
PORMALS3874352951pormals19.2.0.4.0NONJLT-SERVER1

SnapIdSnapTimeSessionsCurs/SessComment
-------------------------------------------------------------
BeginSnap:3618-7月-0420:41:022919.2

EndSnap:3719-7月-0408:18:272415.7

Elapsed:697.42(mins)

CacheSizes(end)
~~~~~~~~~~~~~~~~~
BufferCache:240MStdBlockSize:8K
SharedPoolSize:96MLogBuffer:512K

2、负载间档
该部分供应每秒和每一个事物的统计信息，是监控体系吞吐量和负载变更的主要部分


Quote:LoadProfile
~~~~~~~~~~~~PerSecond(秒)PerTransaction事物
------------------------------
Redosize:148.463,702.15
Logicalreads:1,267.9431,619.12
Blockchanges:1.0125.31
Physicalreads:4.04100.66
Physicalwrites:4.04100.71
Usercalls:13.95347.77
Parses:4.98124.15
Hardparses:0.020.54
Sorts:1.3333.25
Logons:0.000.02
Executes:2.4661.37
Transactions:0.04

%BlockschangedperRead:0.08RecursiveCall%:30.38
Rollbackpertransaction%:0.42RowsperSort:698.23

申明:
Redosize:每秒发生的日记巨细(单元字节)，可标记数据库义务的沉重与否
Logicalreads:平决每秒发生的逻辑读，单元是block
blockchanges:每秒block变更数目，数据库事物带来改动的块数目
Physicalreads:均匀每秒数据库从磁盘读取的block数
Physicalwrites:均匀每秒数据库写磁盘的block数
Usercalls:每秒用户call次数
Parses:每秒剖析次数，近似反响每秒语句的实行次数
软剖析每秒凌驾300次意味着你的"使用程序"效
率不高，没有利用softsoftparse，调剂session_cursor_cache
Hardparses:每秒发生的硬剖析次数
Sorts:每秒发生的排次序数
Executes:每秒实行次数
Transactions:每秒发生的事件数，反应数据库义务沉重与否

3、实例射中率
该部分能够提早找出ORACLE潜伏将要产生的功能成绩，很主要


Quote:InstanceEfficiencyPercentages(Target100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BufferNowait%:100.00RedoNoWait%:100.00
BufferHit%:99.96In-memorySort%:99.14
LibraryHit%:99.53SoftParse%:99.57
ExecutetoParse%:-102.31LatchHit%:100.00
ParseCPUtoParseElapsd%:81.47%Non-ParseCPU:96.46

申明:
BufferNowait%:在缓冲区中猎取Buffer的未守候比率
RedoNoWait%:在Redo缓冲区猎取Buffer的未守候比率
BufferHit%:数据块在数据缓冲区中得射中率，一般应在90%以上，不然，必要调剂
In-memorySort%:在内存中的排序率
LibraryHit%:次要代表sql在共享区的射中率，一般在95%以上，否，必要要思索加
年夜共享池，绑定变量，修正cursor_sharing等参数。
SoftParse%:近似看做sql在共享区的射中率，小于<95%,必要思索到绑定，假如低于80%，
那末便可能sql基础没有被重用
ExecutetoParse%:sql语句剖析后被反复实行的次数，假如太低，能够思索设置
session_cached_cursors参数
ParseCPUtoParseElapsd%:剖析实践运转事务/(剖析实践运转工夫+剖析中守候资本工夫)
越高越好
%Non-ParseCPU:查询实践运转工夫/(查询实践运转工夫+sql剖析工夫)，太低暗示剖析损耗工夫过量。


Quote:SharedPoolStatisticsBeginEnd
------------
MemoryUsage%:33.7957.02
%SQLwithexecutions>1:62.6273.24
%MemoryforSQLw/exec>1:64.5578.72

SharedPool相干统计数据

MemoryUsage%:共享池内存利用率，应当不乱在75%-90%间，太小华侈内存，太年夜则内存不敷。

%SQLwithexecutions>1:实行次数年夜于1的sql比率，若太小多是没有利用bindvariables。

%MemoryforSQLw/exec>1:也便是memoryforsqlwithexecution>1:实行次数年夜于1的sql
损耗内存/一切sql损耗的内存

4、主要守候事务


罕见守候事务申明:
oracle守候事务是权衡oracle运转情况的主要根据及唆使，次要有余暇守候事务和非余暇守候事务
；余暇守候事务是oracle正守候某种事情，在诊断和优化数据库时分，不必过量注重这部分事务，
非余暇守候事务专门针对oracle的举动，指数据库义务或使用程序运转过程当中产生的守候，这些守候事务是我们在调剂数据库应当存眷的。

对照影响功能罕见守候事务
dbfilescatteredread
该事务一般与全表扫描有关。由于全表扫描是被放进内存中举行的举行的，
一般情形下它不成能被放进一连的缓冲区中，以是就分布在缓冲区的缓存中。该指数的数目过年夜申明
短少索引大概限定利用索引。这类情形也多是一般的，由于实行全表扫描大概比索引扫描效力更高。
当体系存在这些守候时，必要经由过程反省来断定全表扫描是不是必须的来调剂。能够实验将较小的表放进
缓存keep中，制止重复读取它们。
dbfilesequentialread
该事务申明在单个数据块上大批守候，该值太高一般是因为表间毗连按次很糟，大概利用了非选
择性索引。经由过程将这类守候与statspack报表中已知别的成绩接洽起来(如效力不高的sql),经由过程反省确
保索引扫描是必需的，并确保多表毗连的毗连按次来调剂
bufferbusywait
当缓冲区以一种非共享体例大概如正在被读进到缓冲时,就会呈现该守候.该值不该该年夜于1%,确认
是否是因为热门块形成(假如是能够用反转索引,大概用更小块巨细)
latchfree
闩锁是底层的行列机制(加倍正确的称号应当是互斥机制)，用于回护体系全局区(SGA)共享内存布局
。闩锁用于避免对内存布局的并行会见。假如闩锁不成用，就会纪录一次闩锁丧失。尽年夜多半得闩锁成绩
都与利用绑定变量失利(库缓存闩锁)、天生重作成绩(重实行分派闩锁)、缓存的争用成绩(缓存LRU链)以
及缓存的热数据宽块(缓存链)有关。当闩锁丧失率高于0.5%时，必要调剂这个成绩。
logbufferspace
日记缓冲区写的速率快于LGWR写REDOFILE的速率,能够增年夜日记文件巨细，增添日记缓冲区的巨细，或
者利用更快的磁盘来写数据。
logfileswitch
一般是由于回档速率不敷快,必要增年夜重做日记
logfilesync
当一个用户提交或回滚数据时，LGWR将会话得重做操纵从日记缓冲区添补到日记文件中，用户的历程
必需守候这个添补事情完成。为削减这个守候事务，须一次提交更多纪录，大概将重做日记REDOLOG文件
访在分歧的物理磁盘上。

如果WHERE子句的查询条件里使用比较操作符LIKE和REGEXP，MySQL只有在搜索模板的第一个字符不是通配符的情况下才能使用索引。比如说，如果查询条件是LIKEabc%‘，MySQL将使用索引；如果查询条件是LIKE%abc’，MySQL将不使用索引。

代替了原来VB式的错误判断。比Oracle高级不少。

可以动态传入参数，省却了动态SQL的拼写。

比如日志传送、比如集群。。。

Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。

两个月啃那本sqlserver2005技术内部-存储引擎，花了几个月啃四本书

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。