LR测试BS系统性能测试之数据库性能指标(转载)
上一篇 / 下一篇 2011-11-25 15:44:38 / 个人分类:性能测试
注:以下指标取自SQL Server自身提供的性能计数器。
指标名称 | 指标描述 | 指标范围 | 指标单位 |
1.SQL Server中访问方法(Access Methods)对象包含的性能计数器 | |||
全表扫描/秒 (Full Scans/sec) | 指每秒全表扫描的数量。全表扫描可以是基本表扫描或全索引扫描。由于全表扫描需要耗费大量时间,因此全表扫描的频率过高的话,会影响性能。 | 如果该指标的值比1或2高,应该分析设计的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。 | 次数/秒 |
2.SQL Server中缓冲器管理器(Buffer Manager)对象包含的性能计数器 | |||
缓冲区高速缓存命中率(BufferCache Hit Ratio%) | 指在缓冲区高速缓存中找到而不需要从磁盘中读取的页的百分比。该比率是缓存命中总次数与缓存查找总次数之比。经过很长时间后,该比率的变化很小。由于从缓存中读取数据比从磁盘中读取数据的开销小得多,一般希望该比率高一些。 | 该指标的值最好为90%或更高。通常可以通过增加SQL Server可用的内存数量来提高该指标的值。增加内存直到这指标的值持续高于90%,表示90%以上的数据请求可以从数据缓冲区中获得所需数据。 | % |
读的页/秒 (Page Reads/sec) | 指每秒发出的物理数据库页读取数。该指标主要考察数据库从磁盘读取数据的频率。因为物理I/O会耗费大量时间,所以应尽可能地减少物理I/O以提高性能。 | 该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,以降低该指标的值。 | 个数/秒 |
写的页/秒 (Page Writes/sec) | 指每秒执行的物理数据库写的页数。该指标主要考察数据库向磁盘写入数据的频率。因为物理I/O会耗费大量时间,所以应尽可能地减少物理I/O以提高性能。 | 该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,以降低该指标的值。 | 个数/秒 |
惰性写/秒 (Lazy Writes/sec) | 指每秒被缓冲区管理器的惰性编写器写入的缓冲区数。惰性编写器是一个系统进程,用于成批刷新脏的老化的缓冲区(包含更改的缓冲区,必须将这些更改写回磁盘,才能将缓冲区重用于其他页),并使它们可用于用户进程。 | 该指标的值最好为0。 | 个数/秒 |
3.SQL Server中高速缓存管理器(Cache Manager)对象包含的性能计数器 | |||
高速缓存命中率(Cache Hit Ratio%) | 指高速缓存命中次数和查找次数的比率。在SQL Server中,Cache包括Log Cache,Buffer Cache以及Procedure Cache,该指标是指所有Cache的命中率,是一个总体的比率。 | 该指标的值越高越好。如果该指标的值持续低于80%,就需要增加更多的内存。 | % |
4.SQL Server中闩(Latches)对象包含的性能计数器 | |||
平均闩等待 时间(毫秒) (Average Latch Wait Time(ms)) | 指一个SQL Server线程必须等待一个闩的平均时间。 | 如果该指标的值很高,则系统可能正经历严重的资源竞争问题。 | 毫秒 |
闩等待/秒 (Latch Waits/sec) | 指在一个闩上每秒的平均等待数量。 | 如果该指标的值很高,则系统可能正经历严重的资源竞争问题。 | 个数/秒 |
5.SQL Server中锁(Locks)对象包含的性能计数器 | |||
死锁的数量/秒 (Number of Deadlocks/sec) | 指每秒导致死锁的锁请求数。 | 锁加在SQL Server资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。应尽可能少使用锁以提高事务的并发性,从而改善性能。 | 个数/秒 |
平均等待时间(毫秒) (Average Wait Time(ms)) | 指线程等待某种类型的锁的平均等待时间。 | 同上 | 毫秒 |
锁请求/秒 (Lock Requests/sec) | 指每秒钟某种类型的锁请求的数量。 | 同上 | 个数/秒 |
Oracle
注:以下指标取自Oracle的性能分析工具Statspack所提供的性能分析指标。
指标名称 | 指标描述 | 指标范围 | 指标单位 | ||||||||||||||||||||||||||||||||||||||||||||||||||
1.关于实例效率(Instance Efficiency Percentages)的性能指标 | |||||||||||||||||||||||||||||||||||||||||||||||||||||
缓冲区未等待率 (Buffer Nowait %) | 指在缓冲区中获取Buffer的未等待比率。 | 该指标的值应接近100%,如果该值较低,则可能要增大buffer cache。 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
Redo缓冲区未等待率 (Redo NoWait %) | 指在Redo缓冲区获取Buffer的未等待比率。 | 该指标的值应接近100%,如果该值较低,则有2种可能的情况: 1)online redo log没有足够的空间; 2)log切换速度较慢。 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
缓冲区命中率 (Buffer Hit %) | 指数据块在数据缓冲区中的命中率。 | 该指标的值通常应在90%以上,否则,需要调整。如果持续小于90%,可能要加大db_cache_size。但有时,缓存命中率低并不意味着cache设置小了,可能是潜在的全表扫描降低了缓存命中率。 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
内存排序率 | 指排序操作在内存中进行的比率。当查询需要排序的时候,数据库会话首先选择在内存中进行排序,当内存大小不足的时候,将使用临时表空间进行磁盘排序,但磁盘排序效率和内存排序效率相差好几个数量级。 | 该指标的值应接近100%,如果指标的值较低,则表示出现了大量排序时的磁盘I/O操作,可考虑加大sort_area_size参数的值。 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
共享区命中率 (Library Hit%) | 该指标主要代表sql在共享区的命中率。 | 该指标的值通常应在95%以上,否则需要考虑加大共享池(修改shared_pool_size参数值),绑定变量,修改cursor_sharing等参数。 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
软解析的百分比 (Soft Parse %) | 该指标是指Oracle对sql的解析过程中,软解析所占的百分比。软解析(soft parse)是指当Oracle接到Client提交的Sql后会首先在共享池(Shared Pool)里面去查找是否有之前已经解析好的与刚接到的这一个Sql完全相同的Sql。当发现有相同的Sql就直接用之前解析好的结果,这就节约了解析时间以及解析时候消耗的CPU资源。 | 该指标的值通常应在95%以上,如果低于80%,那么就可能sql基本没被重用,sql没有绑定变量,需要考虑绑定变量。 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
闩命中率 (Latch Hit%) | 指获得Latch的次数与请求Latch的次数的比率。
| 该指标的值应接近100%,如果低于99%,可以考虑采取一定的方法来降低对Latch的争用。 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
SQL语句执行与 解析的比率 (Execute to Parse %) | 指SQL语句执行与解析的比率。SQL语句一次解析后执行的次数越多,该比率越高,说明SQL语句的重用性很好。
| 该指标的值应尽可能到高,如果过低,可以考虑设置 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
共享池内存使用率 (Memory Usage %) | 该指标是指在采集点时刻,共享池(share pool)内存被使用的比例。 | 这指标的值应保持在75%~90%,如果这个值太低,就浪费内存,如果太高,会使共享池外部的组件老化,如果SQL语句被再次执行,则就会发生硬分析。 | % | ||||||||||||||||||||||||||||||||||||||||||||||||||
2.关于等待事件(Wait events)的性能指标 | |||||||||||||||||||||||||||||||||||||||||||||||||||||
文件分散读取 (db file scattered read(cs)) | 该等待事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的,通常情况下它不可能被放入连续的缓冲区中,所以就散布在缓冲区的缓存中。 | 如果这个等待事件比较显著,可能说明对于某些全表扫描的表,没有创建索引或没有创建合适的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效,但如果出现这种等待时,最好检查一下这些全表扫描是否必要。 | 厘秒 | ||||||||||||||||||||||||||||||||||||||||||||||||||
文件顺序读取 (db file sequential read(cs)) | 该等待事件通常与单个数据块相关的读取操作有关。 | 如果这个等待事件比较显著,可能表示在多表连接中,表的连接顺序存在问题,或者可能不合适地使用了索引。对于大量事务处理、调整良好的系统,这一数值大多是很正常的,但在某些情况下,它可能暗示着系统中存在问题。应检查索引扫描,以保证每个扫描都是必要的,并检查多表连接的连接顺序。另外DB_CACHE_SIZE也是这些等待出现频率的决定因素。 | 厘秒 | ||||||||||||||||||||||||||||||||||||||||||||||||||
缓冲区忙 (buffer busy(cs)) | 当一个会话想要访问缓存中的某个块,而这个块正在被其它会话使用时,将会产生该等待事件。这时候,其它会话可能正在从数据文件向缓存中的这个块写入信息,或正在对这个块进行修改。 | 出现这个等待事件的频度不应大于1%。如果这个等待事件比较显著,则需要根据等待事件发生在缓存中的哪一块(如字段头部、回退段头部块、回退段非头部块、数据块、索引块等),采取相应的优化方法。
| 厘秒 | ||||||||||||||||||||||||||||||||||||||||||||||||||
(enqueue(cs)) |
|
|||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
1 | 2 | 3 | 4 | ||||||
5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
26 | 27 | 28 | 29 | 30 | 31 |
我的存档
数据统计
- 访问量: 1075218
- 日志数: 555
- 文件数: 10
- 建立时间: 2011-06-21
- 更新时间: 2021-06-24
清空Cookie - 联系我们 - 51Testing软件测试网 - 交流论坛 - 空间列表 - 站点存档 - 升级自己的空间
Powered by 51Testing
© 2003-2021
沪ICP备05003035号