简介数据库监测指标文档面向数据库管理员、运维及性能优化人员系统梳理主流数据库的核心监控项。文档覆盖Oracle、SQL Server、Sybase、Informix、DB2等数据库从连接与会话管理、事务处理效率、锁与死锁检测、缓存与内存利用、I/O读写性能到表空间和日志空间使用情况均有分项说明并解释了缓冲池命中率、Largest Chunk、Page Read/Write Rate等关键指标的实际含义。资源为单个doc文件压缩包共1个文件大小286KB内容以表格和分类列表形式呈现便于快速查阅、打印或嵌入内部运维手册。已有83人学习适合作为数据库日常巡检、监控脚本配置和性能问题定位的速查参考尤其对多类型数据库混合环境下的运维人员较为实用。文档不仅罗列指标还提示了指标异常可能反映出的问题例如游标数过多可能表示资源浪费、死锁数上升提示并发控制需优化可辅助管理员快速建立监控优先级。1. 一份数据库监测指标清单从指标名到巡检动作之间缺什么数据库监测指标这个词很多DBA手里都有一份但真到了定位问题的时候大多数人的第一反应不是翻指标清单而是去看会话、看等待事件、看慢SQL。原因很简单指标清单只给了你“叫什么”没给你“怎么读、读到什么程度该动”。这份《数据库监测指标数据库监测指标.doc》恰恰是把Oracle、SQL Server、Sybase、Informix、DB2、MySQL六类数据库的常用监测项完整列了一遍从游标数、Session数、每秒事务数到缓冲池命中率、表空间使用率、死锁数再到连接数、日志空间、排序溢出率粒度非常细。适合两类人一类是刚接手多数据库环境的运维新人需要一份能直接当巡检目录的指标字典另一类是要搭统一监控平台的同学拿这份清单去比对自家采集项是否漏了关键指标。它解决的不是“怎么监控”的代码问题而是“该监控什么、这些指标之间怎么关联”的选型问题。2. Oracle 指标组游标、Session、命中率、表空间四层怎么配阈值2.1 会话与事务层游标数、Session 数、每秒事务数配合看Oracle 这部分指标里最容易被单独误读的就是游标数。很多人一看到v$open_cursor里当前游标数量高就急着调OPEN_CURSORS参数。其实游标数真正要配合 Session 数一起看如果当前 Session 数也在高位游标多可能是正常的应用并发如果 Session 数不高但游标数持续走高那多半是应用层连接池没做游标释放。一般我会先按单个 Session 的游标占用排序定位到具体 SQL 或具体模块再去判断。每秒事务数在 Oracle 里对应的是v$sysstat中user commits与user rollbacks之和这个数字适合做趋势基线而不是设绝对值阈值。它更像一个“业务活跃度”信号如果某天同一时段每秒事务数骤降先看是不是数据库连接出问题再看是不是应用侧流量断了。锁数量与死锁数量要分开处理锁数量高不代表有问题要看锁等待时间死锁数量则要做到非零必查。一个适用的巡检 SQL 是SELECT NVL(ss.name, total) AS stat_name, ss.value FROM v$sysstat ss WHERE ss.name IN (user commits, user rollbacks, opened cursors current) UNION ALL SELECT current sessions, COUNT(*) FROM v$session WHERE type USER;这条语句把 Oracle 事务与游标、会话数拉在一张结果集里方便放在同一张巡检图里观察。user commits与user rollbacks累加就是每秒事务数的基础分母opened cursors current是当前打开的游标总量v$session中type USER会过滤掉后台进程得到的是真实用户会话数。如果巡检结果是游标数高且用户会话数也在涨基本可以判断是并发上升而不是游标泄漏。参数调整要慢先看应用侧。2.2 内存命中率层缓冲池命中率、Largest Chunk、Library Cache Miss Ratio缓冲池命中率Buffer Cache Hit Ratio是 Oracle 指标组里认知度最高的一个但也是最容易被错误应用于告警的一个。从v$sysstat取consistent gets、db block gets与physical reads按公式(consistent_gets db_block_gets - physical_reads) / (consistent_gets db_block_gets)计算。这个值低于 90% 时很多人会立刻加DB_CACHE_SIZE但在实际案例里物理读高有时是因为全表扫描类 SQL 在批量跑命中率低是结果不是原因。Largest Chunk 这个指标相对冷门它表示共享池中最大的空闲连续内存块来源是v$sgastat中free memory池里的最大连续块。若这个值持续小于某个阈值比如小于 8MB且伴随ORA-04031错误日志说明共享池碎片化严重。这时单纯调大SHARED_POOL_SIZE只能缓解根本解法是审视字面量 SQL推动应用使用绑定变量。Library Cache Miss Ratio 要单独看它衡量 SQL 与 PL/SQL 对象在库缓存中的复用情况。计算方式是(sum(pins) - sum(reloads)) / sum(pins)。SELECT namespace, gethitratio, pinhitratio, reloads, invalidations FROM v$librarycache WHERE namespace IN (SQL AREA, TABLE/PROCEDURE, BODY);这条 SQL 取的是库缓存中 SQL 与存储过程的命中率、重载次数和失效次数。pinhitratio表示 pin 操作的命中率正常应在 90% 以上如果reloads和invalidations很高说明有对象在频繁失效——常见原因是 DDL 操作过度比如半夜批量 job 反复DROP TABLE再CREATE导致依赖对象失效进而引发大量硬解析。这时候要优化的是应用代码策略而不是 SGA 参数。2.3 表空间与连接池状态、使用率、剩余率的阈值设计表空间指标是 Oracle 巡检里最需要量化的一部分。v$tablespace、dba_data_files、dbfree_space三者联合算出来的使用率、已用空间、剩余率、剩余空间、总容量每一项都有不同的告警含义。使用率适合做趋势看剩余率适合做比例告警剩余空间则要结合数据文件是否自动扩展来判断。SELECT df.tablespace_name, ROUND(df.total_mb, 2) AS total_mb, ROUND((df.total_mb - fs.free_mb), 2) AS used_mb, ROUND(fs.free_mb, 2) AS free_mb, ROUND((df.total_mb - fs.free_mb) / df.total_mb * 100, 2) AS used_pct FROM ( SELECT tablespace_name, SUM(bytes) / 1024 / 1024 AS total_mb FROM dba_data_files GROUP BY tablespace_name ) df LEFT JOIN ( SELECT tablespace_name, SUM(bytes) / 1024 / 1024 AS free_mb FROM dba_free_space GROUP BY tablespace_name ) fs ON df.tablespace_name fs.tablespace_name ORDER BY used_pct DESC;这是每个巡检周期必跑一遍的容量基线语句。used_pct为使用率一般我的习惯是使用率超过 80% 开始关注增长速度超过 90% 进入需要扩容的队列如果剩余空间绝对值小于 10GB 且非自动扩展那就要提前处理。这里有个值得注意的口径问题dba_free_space统计的是已经格式化但未被占用的空间如果表空间开了自动扩展实际可写容量还要加上autoextensible的剩余扩展上限所以单独看剩余率会低估容量风险。连接数这块文档里的Connections Utilization、Current Connections、Reserved Connections三个指标要一起看。v$resource_limit中的sessions与processes就是天然的上下限对照Current Connections接近上限时配合User Call Rate和User Calls Per Parse Ratio来看是解析开销大还是业务调用量大。User Calls Per Parse Ratio低说明每次用户调用都带着解析这时候要查session_cached_cursors设置和应用是否大量使用动态 SQL。3. SQL Server 指标组Buffer、Memory、Cache、Static 四套管理器分开盯3.1 BufferManager 与 Page 读写命中率、Lazy_writes、页停留秒数的联动SQL Server 的监控体系比 Oracle 更依赖性能计数器文档里的SQL BufferManager和SQL Server CacheManager就是典型的 PerfMon 计数器分类。Buffer Cache 击中率是第一个要看的但只看它不够。每秒 Lazy_writes 数是内存压力的信号每秒发出的物理数据库页读取数与所发出的物理数据库页写入的数目是 I/O 压力的信号它们三者必须联动分析。Lazy_writes 高意味着内存压力迫使 SQL Server 在缓存页还没被引用完之前就把它们写回磁盘这种情况下 Buffer Cache 击中率可能依然不低但物理写入会明显抬头。页若不被引用将在缓冲区中停留的秒数是 Page Life Expectancy默认建议值是 300 秒以上。这个值掉得厉害通常是内存被大查询或大索引操作吃掉PLAN_CACHE被强制清理是一个常见诱因。SELECT counter_name, cntr_value, CASE WHEN counter_name Page life expectancy THEN 单位秒低于300需关注内存压力 ELSE 单位每秒次数 END AS remark FROM sys.dm_os_performance_counters WHERE object_name LIKE %Buffer Manager% AND counter_name IN ( Buffer cache hit ratio, Lazy writes/sec, Page reads/sec, Page writes/sec, Page life expectancy );这条 SQL 直接查dm_os_performance_counters把 Buffer Manager 的几个核心计数器一次性拉出来。实际取数时要注意cntr_value的单位在不同计数器上不一样Buffer cache hit ratio是百分比Page life expectancy是秒其余大多是每秒累加次数。采集侧建议做成每 30 秒取一次快照再算差值而不是直接用计数器累积值否则看不出瞬时速率变化。3.2 MemoryManager 与 CacheManager工作空间授权、8KB 页数、动态内存SQL Server 的内存管理指标要按“总量、授权、缓存”三条线分开看。文档里的SQL MemoryManager中SQL Server 使用的内存总量是Total Server Memory (KB)它负责告诉你实例整体内存占用每秒成功获得一个工作空间内存授权的进程总数是Memory Grants Outstanding / Memory Grants Pending的变体后者才是真正的内存等待信号查询优化的内存总数对应Optimizer Memory (KB)动态 SQL 高速缓存的动态内存总数对应SQL Cache Memory (KB)。Granted Workspace Memory 高说明排序与哈希操作大量占用内存如果Memory Grants Pending持续大于 0说明有查询在等内存授权这时加max server memory不一定有效先找出是哪些查询申请了超大内存授权通常是排序溢出或嵌套循环哈希操作导致。SELECT counter_name, cntr_value FROM sys.dm_os_performance_counters WHERE object_name LIKE %Memory Manager% AND counter_name IN ( Total Server Memory (KB), Granted Workspace Memory (KB), Memory Grants Pending, Optimizer Memory (KB), SQL Cache Memory (KB) );这里Memory Grants Pending是关键的队列指标它大于 0 代表有内存请求在排队。SQL Cache Memory (KB)是缓存动态 SQL 计划占用的内存如果这个值异常膨胀配合SQL Compilations/sec高说明存在大量无法参数化的 SQL需要去推动应用改造为存储过程或参数化查询。注意 KB 数值默认以千字节为单位换算成 MB 要除以 1024不要被数值大小吓到。3.3 StaticManager 与 UserManager编译、重编译、登录注销、当前连接文档里SQL Server StaticManager的指标包括每秒收到的 Transact-SQL 命令批数Batch Requests/sec、每秒的自动参数化尝试数Auto-Param Attempts/sec、每秒 SQL 编译数SQL Compilations/sec、每秒 SQL 重新编译数SQL Re-Compilations/sec。这四个计数器是判断 SQL Server CPU 开销去向的核心。Batch Requests/sec 高说明请求量大SQL Compilations/sec 与 Re-Compilations/sec 占比高说明大量精力花在编译上而非执行上典型表现是 CPU 高但吞吐上不去。SQL User Manager中的用户连接数是当前连接数每秒启动的登录数与每秒开始的注销操作总数要用差值去看峰值速率。连接数不等于活跃请求数大量连接处于休眠状态时数据库压力不一定大所以要和Process Blocking Locks Ratio配合如果连接数高且有阻塞锁比例上升多半是连接池耗尽或应用层事务未及时提交。SELECT counter_name, cntr_value FROM sys.dm_os_performance_counters WHERE object_name LIKE %SQL Statistics% OR object_name LIKE %General Statistics% OR object_name LIKE %SQL Errors%;这段 SQL 把三个类别的计数器合在一起看适合放在一台实例上做整体健康检查。通用统计里的User Connections与Processes blocked组合使用如果Processes blocked持续大于 5基本可以判定存在阻塞链需要到sys.dm_exec_requests里找blocking_session_id。SQL 错误计数器里的Errors/sec也可以顺带拉出来但那个更偏连接中断类问题日常巡检先不看。4. Sybase、Informix、DB2同一种指标在不同引擎里的口径差异4.1 SybaseI/O 错误、数据包、死锁信息是排查重点Sybase 这套指标和 SQL Server 同源但口径上要格外小心。文档里的每分钟 Sybase 在读取和写入时遇到的错误数是累计计数器每分钟在输入和输出上花费的时间也是累计值两者要看增长速率而不是绝对值。每分钟 Sybase 读取的输入数据包数与每分钟 Sybase 写入的输出数据包数反映客户端通信负载正常应呈平滑波动如果出现大量尖峰多半是某个应用在跑批量导入。Sybase 死锁部分给出了死锁时间最长的进程 ID、最长死锁时间、死锁数、前十个死锁信息这是四条由粗到细的线索链。最长的死锁时间比死锁次数更有价值死锁次数高但单次持续时间短说明是并发冲突频繁但解决快单次死锁时间长说明存在长事务持有锁不释放。sp_who与sp_lock是定位这类问题的标准工具。表空间侧则复用 Oracle 的口径逻辑使用率、剩余率、剩余空间、总容量四件套但 Sybase 的段管理比 Oracle 简单看syssegments即可。4.2 Informix逻辑日志、Chunk 空间、虚拟处理器Informix 的指标条目不按计数器命名而是直接以监控对象命名最直观的一个是逻辑日志文件总数与逻辑文件所占空间。这两个指标反映逻辑日志是否够用配合Logical Log Records Write Rate和Logical Log Pages Write Rate来看写压力。如果逻辑日志空间持续逼近总量上限且Backup Level长期为 0说明没有做日志备份归档这是log full故障的头号诱因。Chunk相关指标是 Informix 特有的监控对象块总数、块空间总数、块剩余空间要按 chunk 维度去巡检而不是只看表空间汇总。一个 chunk 如果剩余空间为 0即使表空间整体使用率不高写操作也会被卡住。Server Mode、Check-point in progress、Recovery Status、Backup Status、Misc Status这些状态类指标要作为“硬状态”处理——任何一个不是正常值都要直接进入人工介入流程。我一般会在巡检脚本里单独拉一条检查onstat -d onstat -g recconv onstat -g gloonstat -d看 dbspace 与 chunk 的状态输出的每一行都有addr与chunk信息onstat -g recconv看恢复状态onstat -g glo看全局目标与虚拟处理器。注意onstat需要以 informix 用户身份执行。虚拟处理器数量要与 CPU 核数匹配不是越多越好拉onstat -g glo看每个 VPI 的busy时间如果某个处理器长期繁忙而其他空闲多半是配置方式不对。4.3 DB2代理、缓存池、表空间的 Buffer Pool ID 匹配DB2 的指标组织和前三种库差异最大它把连接状态、代理状态、缓存池状态、cache缓存状态分成四个独立块。连接总数、当前连接数、本地连接数三者的关系要做减法如果当前连接数远小于连接总数说明存在大量残留连接或连接池回收不及时。Active Agents、Idle Agents、Number of Agents、Agents Waiting是一组Agents Waiting持续大于 0 说明代理进程池不够用需要调NUM_POOLAGENTS或在应用侧控制并发连接数。DB2 的缓存池命中率分Buffer Pool Hit Ratio、Index Page Hit Ratio、Data Page Hit Ratio三个维度Direct Reads与Direct Writes是绕过缓冲池的 I/O 路径。表空间侧文档列出了Extent size、Prefetch size、Page size、Cur Buffer Pool ID、Next Buffer Pool ID这几个参数要一起对照看——建表空间时若Cur Buffer Pool ID和Next Buffer Pool ID不一致意味着后续 ALTER 操作可能把表迁到另一个缓冲池容易造成性能跳变。以下是一条适用于 DB2 的缓冲池命中率查询SELECT bp_name, pool_id, pool_data_lbp_ratio AS data_lbp_ratio, pool_index_lbp_ratio AS index_lbp_ratio, pool_data_hit_ratio AS data_hit_ratio, pool_index_hit_ratio AS index_hit_ratio FROM TABLE (MON_GET_BUFFERPOOL(NULL, -2)) AS T ORDER BY bp_name;MON_GET_BUFFERPOOL是 DB2 的监控表函数-2表示当前实例维度NULL表示所有缓冲池。pool_data_lbp_ratio是数据页在缓冲池中被命中的比例pool_index_hit_ratio对索引页同样适用。注意 DB2 的命中率统计口径和 Oracle 不同它是按申请次数而非按块次数计算阈值参考 90% 可以但低于 85% 才需要考虑调大缓冲池。Direct Reads对应的是并行扫描这类访问不会走缓冲池所以命中率低不代表缓冲池配置有问题。5. 避坑与排查指标全、阈值空五个常踩的坑5.1 现象Buffer Cache Hit Ratio 低于 90%加了 DB_CACHE_SIZE 后问题依旧原因命中率低是全表扫描或并行查询的结果不是内存不足的原因。加了内存后 SQL 执行计划没变物理读依然存在。解决先看v$sql_plan里有没有大规模TABLE ACCESS FULL或PX并行操作再决定是优化 SQL 还是调内存参数。命中率指标适合做趋势基线不适合单独设硬阈值告警。5.2 现象SQL Server 死锁数监控为零但业务侧频繁报错原因只采集了当前瞬时值死锁事件是瞬时的监控周期 5 分钟时根本拍不到。解决用系统健康报告或扩展事件采集死锁图sys.dm_os_performance_counters里加SQL Errors: User DB的Deadlocks/sec按差值计算每 30 秒内的累加值。从那以后我每次做 SQL Server 巡检都会先确认计数器采集的是累计差值而不是瞬时快照。5.3 现象Oracle 表空间剩余率还有 40%但报表写入报错原因剩余率算的是剩余空间占总容量的比例而报错通常来自单个数据文件已用尽且未开自动扩展。解决按数据文件维度检查dba_data_files的maxbytes与autoextensible字段。剩余率指标只能做宏观预警扩容决策必须落到文件级。我曾经遇到过剩余率 35% 但SYSTEM表空间单个文件已满的故障从那以后凡是涉及空间告警都是文件级与表空间级双重核对。5.4 现象Informix 的 chunk 剩余空间充足但数据库拒绝写入原因chunk 剩余空间看的是空闲块但写入需要连续空闲块。空闲空间碎片化严重时即使总量够也分配不出连续页。解决用onstat -d查看每个 chunk 的free与size再结合onstat -g frmem看内存与块的碎片状态。碎片化问题没法靠扩容解决只能做表重建或调整extent size。5.5 现象DB2 连接数报警频发每次都很快恢复原因连接数采集值取的是瞬时快照而应用连接池每几分钟做一次扩容回收导致瞬时峰值反复触发告警。解决连接数按 1 分钟均值做告警评估同时配置 2 次连续触发才真正告警的冷却策略。所有“连接数”“会话数”类指标都应做一个滚动平均缓冲区不能只看单点值这是最常被忽略的采集层问题。6. 把指标清单变成巡检脚本基线化、告警分级与一次手工验证拿到这份指标清单后第一步不是建一堆告警规则而是先做两周的基线采集。把这套文档里的指标分成四层第一层是硬状态指标比如 Oracle 的 Listener 状态、Informix 的Server Mode、DB2 的Database Status这些只取枚举值非正常即告警第二层是容量类指标比如表空间使用率、剩余率、Log 占用这类要有绝对值阈值使用率 80% 起关注、90% 起告警第三层是性能类指标比如命中率、Page 读写速率、每秒事务数这类不能设死阈值要用百分位基线比如取两周 P95 值加浮动系数作为动态上限第四层是诊断类指标比如死锁数、锁等待率、Lazy_writes这类非零即查或按差值小时均值对比。在告警策略上我习惯做三级严重级别对应数据库不可用或即将不可用比如连接数达到上限、表空间剩余为 0警告级别对应容量增长趋势异常比如剩余空间从 50% 一周内降到 20%信息级别是基线的偏离比如 Buffer Cache Hit Ratio 比 P95 基线低了 5%。最后一条很容易被忽略但它往往是最早暴露问题的信号。写巡检脚本时优先复用系统自带的性能视图不要每个指标都做全量查询。Oracle 一次v$sysstat快照差值足够覆盖大部分性能类指标SQL Server 一次dm_os_performance_counters查询就能覆盖整套计数器DB2 用MON_GET_*表函数批量拉取。脚本里每取一个指标都要带上采集时间戳存成带时区的时间序列别用本地时间跨时区排查时会省很多事。验证方法也简单挑一个业务高峰期手工执行一次数据库上报错的典型 SQL观察指标清单里对应的两到三个指标有没有同步变化。比如在 Oracle 上跑一次全表扫描确认物理读上涨、Buffer Cache Hit Ratio 下降、会话 CPU 时间增加在 SQL Server 上跑一次大排序确认Granted Workspace Memory和Sort Overflow同时上升。只有这种联动关系能被复现说明你的监控指标落位是有效的。这套文档最实用的地方在于它是按数据库类型组织的你在搭统一监控平台时可以按章取数、按表建采集项。我把其中 Sybase 的通信错误计数和 Informix 的 chunk 剩余空间做成两条定时巡检任务后提前拦下了三次隐患。从那以后我每次新建一套监控体系都强制走一遍“基线采集两周、百分位定阈值、高峰手工验证”这三步不跳过任何一步。这份清单解决了我监控项漏配的问题希望也能帮到你。本文还有配套的精品资源点击获取