浅谈ORACLE AWR single instance 一

关注

原创最新推荐文章于 2026-03-16 18:50:16 发布 1k 阅读 AI 写同款· GEO 优化 ›

深入解析NPN与PNP传感器驱动电路的设计逻辑与实战应用本文深入解析NPN与PNP传感器驱动电路的设计逻辑与实战应用，详细对比两者的电流路径差异和电平变化特性。通过实际案例分享电路设计要点，包括上拉电阻选择、保护二极管配置等，并提供工业应用中的选型策略和常见故障排查指南，帮助工程师优化传感器系统集成。阅读详情

Oracle中的AWR，全称为Automatic Workload Repository，自动负载信息库。
AWR是DBA了解其运行状态的重要工具之一，根据AWR报告可以对oracle数据库性能整体了解并针对性优化，此文章主要是介绍AWR相关部分的内容。
这里写图片描述

Sessions
采集性能信息时，oracle 实例链接的会话数，有助于判断DB的类
Cursors/Session
单个会话平均打开的游标数
Elapsed
DB实际使用时间
DB Time
数据库操作花费的时间，包括CPU和Wait Event time，DB Time越高数据库，数据库负载越高。

通过DB Time/Elapsed 比值判断数据库的繁忙程度，比值越高，数据库越繁忙。
DB Time = CPU time + Wait time（不包括后台进程及空闲等待）
对应V$SESSION 中的elapsed_time

Load Profile
这里写图片描述

DB Time DB CPU
DB Time 3.3s DB CPU 1.4s Wait Event 3.3-1.4=1.9s, DB CPU占DB Time的比重为1.4/3.3=42%
可以看出此DB系统的非CPU等待占比比较大

redo size 日志的产生量

Logical reads 逻辑读，单位是块
良好的OLTP logical reads/ Executes 在50左右

Block Changes
每秒、事务改变的数据块

Physical reads
物理读

User Calls
每秒(每个事务)用户调用次数。User calls/Executes基本上代表了每个语句的请求次数，Executes越接近User calls越好

Pasre
解析次数，不包括快速软解析（MOS上说执行3次的SQL语句会把游标缓存到PGA，这个游标一直开着，当再有相同的SQL执行时，则跳过解析的所有过程直接去取执行计划）
软解析过多说明应用程序的效率不高
Hard Parse
硬解析的次数，此指标过高说明绑定变量没有做好
Sorts
排序次数
W/A MB processed
单位MB W/A workarea workarea中处理的数据数量结合 In-memory Sort%， sorts (disk) PGA Aggr一起看
Logon
登入数据库的次数
Executes
执行次数
Rollbacks
回滚次数
Transactions
事务数

TOP 5 event
这里写图片描述

DB CPU占比42.55%

db file sequential read/db file scattered read//libary cache:mutex X/latch:shared pool为CPU等待的TOP 4 wait event
（DB Time > DB CPU + FG Wait event DB Time 会计算在CPU繁忙时的等待CPU的队列时间）

Instance Efficiency Percentage（Target 100%）
这里写图片描述

此模块记录oracle instance memory的使用信息，目标为100%，针对OLTP系统，此模块信息比较重要，对于OLAP系统，意义不大。

Buffer Nowait%
非等待方式获取数据块的百分比
这个值偏小，说明发生SQL访问数据块时数据块正在被别的会话读入内存，需要等待这个操作完成。发生这样的事情通常就是某些数据块变成了热块。

Redo Nowait
非等待获取redo数据
Buffer Hit%
数据缓存命中率
In-memory Sort%
数据排除操作在内存中的百分比
Library Hit%
共享池中SQL解析的命中率
（相关参数SHARED_POOL_SIZE\BINGD VALUE\CURSOR_SHARING）
Soft Parse %
软解析占解析的比率 value偏低表示DB中多数SQL没有被重用 <95%考虑绑定变量
Execute to Parse%
执行次数对解析次数的百分比
如果该值偏小，说明解析(硬解析和软解析)的比例过大，快速软解析比例小。根据实际情况，可以适当调整参数session_cursor_cache，以提高会话中sql执行的命中率。

Latch Hit%
Latch的命中率
其值低是因为shared_pool_size过大或没有使用绑定变量导致硬解析过多。要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数。

Parse CPU to Parse Elapsd%
解析总时间中消耗CPU的时间百分比。即:100*(parse time cpu / parse time elapsed)
解析实际运行事件/(解析实际运行时间+解析中等待资源时间)，越高越好。

%Non-Parse CPU
CPU非分析时间在整个CPU时间的百分比。
100*(parse time cpu / parse time elapsed)= Parse CPU to Parse Elapsd %
查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过多。

shared pool statistics
这里写图片描述