珠海评测中心 发表于 2012-2-27 15:50:51

求数据库性能测试方面的参数.谢谢!

求数据库性能测试方面的参数

菜鸟@大虾 发表于 2012-3-1 17:55:38

SQL Server
注:以下指标取自SQL Server自身提供的性能计数器。
指标名称        指标描述        指标范围        指标单位
1.SQL Server中访问方法(Access Methods)对象包含的性能计数器
全表扫描/秒
(Full Scans/sec)        指每秒全表扫描的数量。全表扫描可以是基本表扫描或全索引扫描。由于全表扫描需要耗费大量时间,因此全表扫描的频率过高的话,会影响性能。        如果该指标的值比1或2高,应该分析设计的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。        次数/秒
2.SQL Server中缓冲器管理器(Buffer Manager)对象包含的性能计数器
缓冲区高速缓存命中率 (Buffer Cache
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设置小了,可能是潜在的全表扫描降低了缓存命中率。        %
内存排序率
(In-memory Sort %)        指排序操作在内存中进行的比率。当查询需要排序的时候,数据库会话首先选择在内存中进行排序,当内存大小不足的时候,将使用临时表空间进行磁盘排序,但磁盘排序效率和内存排序效率相差好几个数量级。        该指标的值应接近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语句的重用性很好。
        该指标的值应尽可能到高,如果过低,可以考虑设置
session_cached_cursors参数。        %
共享池内存使用率
(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))        enqueue 是一种保护共享资源的锁定机制。该锁定机制保护共享资源,如记录中的数据,以避免两个人在同一时间更新同一数据。enqueue 包括一个排队机制,即FIFO(先进先出)排队机制。注意:Oracle 的latch 机制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。        如果enqueue等待事件比较显著,则需要根据enqueue等待类型,采取相应的优化方法。        厘秒
闩释放
(latch free (cs))        该等待事件意味着进程正在等待其他进程已持有的latch。
latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构。latch 就像是一种快速地被获取和释放的内存锁。latch 用于防止共享内存结构被多个用户同时访问。        对于常见的Latch等待通常的解决方法:
1)Share pool latch:在OLTP应用中应该更多的使用绑定变量以减少该latch的等待。
2)Library cache latch:同样的需要通过优化sql语句使用绑定变量减少该latch的等待。        厘秒
日志文件同步
(log file sync (cs))        这个等待事件是指当一个会话完成一个事务(提交或者回滚数据)时,必须等待LGWR进程将会话的redo信息从日志缓冲区写到日志文件后,才能继续执行下去。        这个等待事件的时间过长,可能是因为commit太频繁或者lgwr进程一次写日志的时间太长(可能是因为一次log io size太大),可调整 _log_io_size,结合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer,这样可避免和增大log_buffer引起冲突,或者可以将日志文件存放在高速磁盘上        厘秒

菜鸟@大虾 发表于 2012-3-1 17:56:07

网上很多,可以搜搜哈..
页: [1]
查看完整版本: 求数据库性能测试方面的参数.谢谢!