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设置小了，可能是潜在的全表扫描降低了缓存命中率。 |
% |
|
内存排序率 |
指排序操作在内存中进行的比率。当查询需要排序的时候，数据库会话首先选择在内存中进行排序，当内存大小不足的时候，将使用临时表空间进行磁盘排序，但磁盘排序效率和内存排序效率相差好几个数量级。 |
该指标的值应接近100%，如果指标的值较低，则表示出现了大量排序时的磁盘I/O操作，可考虑加大sort_area_size参数的值。 |
% |
|
共享区命中率 |
该指标主要代表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)) |
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引起冲突，或者可以将日志文件存放在高速磁盘上 |
厘秒 |
DB2
注：以下指标取自DB2的运行状况指示器所包含的各项指标。
|
指标名称 |
指标描述 |
指标范围 |
指标单位 |
|
1．表空间存储器运行状况指示器 |
|||
|
自动调整大小 表空间利用率 (ts.ts_util_auto_ Resize %) |
该指标用来跟踪每个DMS表空间的存储器消耗情况，这些DMS表空间已经定义了最大大小，并且可以自动调整大小，达到最大大小时，则认为DMS表空间已满。 |
该指标是用消耗的最大表空间存储器所占的百分比度量的。高百分比指示表空间接近已满程度。该指标的附加信息中包括的短期增长率和长期增长率可用来确定，当前增长率是短期畸变还是与长期增长一致。附加信息中对离空间已满所余时间的计算可以预测达到最大大小所余的时间。 |
% |
|
表空间利用率 (ts.ts_util %) |
如果在表空间上没有启用自动调整大小，则可用该指标来跟踪每个DMS表空间的存储器消耗情况；反之，DB2不会评估该指标。 |
该指标以消耗空间的百分比来度量。高百分比指示未达到该指标的最优运行状况。该指标的附加信息中包括的短期增长率和长期增长率可用来确定，当前增长率是短期畸变还是与长期增长一致。附加信息中对离空间已满所余时间的计算可以预测达到最大大小所余的时间。 |
% |
|
表空间容器利用率 (ts.ts_op_status %) |
该指标用来跟踪未使用自动存储器的每个SMS表空间的存储器消耗情况。如果对其定义容器的任何文件系统上都没有更多空间，则认为SMS表空间已满。如果文件系统上没有可用空间可供扩展SMS容器，则表示关联表空间已满。 |
该指标以消耗空间的百分比来度量。高百分比指示未达到该指标的最优运行状况。该指标的附加信息中包括的短期增长率和长期增长率可用来确定，当前增长率是短期畸变还是与长期增长一致。附加信息中对离空间已满所余时间的计算可以预测达到最大大小所余的时间。 |
% |
|
2．排序运行状况指示器 |
|||
|
专用排序内存利用率 (db2.sort_privmem_ Util %) |
该指标用来跟踪专用排序内存的利用率。 |
如果该指标的值等于或超过100%，则说明已达到了排序堆阀值，没有足够的堆空间可用于执行排序。“阀值后排序数”快照监视元素可在调整该指标值时作为参考。该监视元素记录了超过排序堆阀值后请求堆的排序数。 |
% |
|
共享排序内存利用率 (db2.sort_shrmem_ Util %) |
该指标用来跟踪共享排序内存的利用率。 |
如果该指标的值等于或超过100%，则说明已达到了排序堆阀值，没有足够的堆空间可用于执行排序。 建议使用自调整内存功能，以根据当前工作负载的需要自动分配排序内存资源。 |
% |
|
溢出排序百分比 (db.spilled_sorts %) |
该指标值是指用完排序堆后可能需要磁盘空间以供临时存储器使用的总排序数占已执行的排序总数的利率。 |
该指标值应为0，因为溢出至磁盘的排序可能导致严重的性能下降。 建议使用自调整内存功能，以根据当前工作负载的需要自动分配排序内存资源。 |
% |
|
3．日志记录运行状况指示器 |
|||
|
日志利用率 (db.log_util %) |
该指标用来跟踪在数据库中使用的总活动日志空间量。 |
该指标以消耗空间的百分比来度量。高百分比指示空间消耗接近已满程度。这时可调整一些与日志有关的数据库配置参数的值。这些参数的值显示在附加信息中。 |
% |
|
日志文件系统利用率 (db.log_fs_util %) |
该指标用来跟踪事务日志所在的文件系统的充满程度。如果文件系统上没有空间，则DB2可能无法创建新的日志文件。 |
该指标以消耗空间的百分比来度量。高百分比指示文件系统中的可用空间量已接近于0。这时可调整一些与日志有关的数据库配置参数的值。这些参数的值显示在附加信息中。 |
|
|
4．应用程序并发性运行状况指示器 |
|||
|
死锁率 (db.deadlock_rate%) |
该指标用来跟踪死锁出现在数据库上的比率以及应用程序遇到争用问题的等级。 |
该指标值应为0，该值越高，则争用等级就越高。 |
% |
|
锁定列表利用率 (db.locklist_util %) |
该指标用来跟踪要使用的锁定列表内存量。每个数据库有一个锁定列表，锁定列表包含由同时连接至数据库的所有应用程序挂起的锁定。这是对锁定列表内存设置的限制。一旦达到该限制，就会因为下列情况而使得性能下降： 1） 锁定升级将行锁定转换为表锁定，从而降低了数据库中的共享对象的并行性； 2） 因为应用程序等待有限数目的表锁定，所以应用程序间会出现更多死锁。因此将回滚事务。 |
该指标以消耗内存的百分比来度量，出现高百分比表示状况不佳。 建议使用自调整内存功能，以根据当前工作负载的需要自动分配排序内存资源。 |
% |
|
等待锁定的应用程序的百分比 (db.apps_waiting _locks %) |
该指标度量所有当前执行的等待锁定的应用程序所占的百分比。 |
高百分比可能指示应用程序遇到并行性问题，这对性能有负面影响。 |
% |
|
5．程序包和目录高速缓存，以及工作空间运行状况指示器 |
|||
|
目录高速缓存命中率 (db.catcache _hitratio %) |
该指标用于指示目录高速缓存对避免对磁盘上的目录的实际访问所起到的帮助作用。 |
高命中率指示在避免实际磁盘I/O访问方面很成功。 |
% |
|
程序包高速缓存 命中率 (db.pkgcache _hitratio %) |
该指标用于指示程序包高速缓存对避免从系统目录重新装入静态SQL的程序包和段以及避免重新编译动态SQL语句所起到的帮助作用。 |
高命中率指示在避免从系统目录重新装入静态SQL的程序包和段以及避免重新编译动态SQL语句方面很成功。 |
% |
|
共享工作空间 命中率 (db.shrworkspace _hitratio %) |
该指标用于指示共享SQL工作空间对避免初始化要执行的SQL语句的各段所起到的帮助作用。 |
高命中率指示在避免初始化要执行的SQL语句的各段方面很成功。 |
% |
|
6．内存运行状况指示器 |
|||
|
数据库堆利用率 (db.db_heap_util %) |
该指标用来跟踪基于带有标识SQLM_HEAP_DATABASE的内存池的监视器堆内存的消耗。 |
一旦此百分比达到最大值100%，查询和操作可能会因为没有堆可用而失败。 |
% |
常用的数据库例如ＭySQL指标主要包括SQL、吞吐量、缓存命中率、连接数等，具体如下：
标准
- SQL耗时越小越好，一般情况下微秒级别。
- 命中率越高越好，一般情况下不能低于95%。
- 锁等待次数越低越好，等待时间越短越好。