OracleAwr报告_awr报告解读_基础简要信息

OracleAwr报告_awr报告解读_基础简要信息
导出
关于awr报告的导出，上⼀篇博客已经进⾏过讲述了。

博客链接地址：这⾥就不再赘述。

各个字段的含义
awr报告的HTML报告，可以在⽹页上直接打开。

这⾥，按照每⼀部分介绍下awr报告的各个字段。

1.报告基本信息
这⼀部分，是报告的⼀些基本信息。

分别包括：
上⾯部分，数据库物理环境相关信息。

第⼀⾏，DB Name 数据库名（数据库名是存储在控制⽂件中，代表数据库所有物理⽂件的总称）。

DB Id 数据库id（数据库的dbid可能在数据库⽂件恢复中需要⽤到，查询数据库DB Id的sql语句为：select dbId from v$database;）。

Instance 实例名（实例名（sid），写数据库地址的时候，192.168.*.*:1521/orcl 这⾥的orcl就是实例名）初始实例编号（暂时不知道⼲什么⽤的，欢迎指导）。

Startup Time 数据库启动时间（本次导出awr报告对应时段的数据库启动时间）。

Release 数据库版本（不同的版本awr报告不全⼀样，这⾥是11.2版本的数据库）。

RAC real application cluster 数据库⾃⼰的集群系统（分布式数据库，安装设置好集群后，从集群的任何⼀个节点数据库都可以同步到其他节点，这⾥没有开启）
第⼆⾏，HostName 服务器名（oracle所在服务器的名称，链接的时候需要验证的⼀个信息）。

Platform 操作系统（orale的安装环境，什么系统，多少位）。

CPUs（服务器多少颗cpu）。

Cores（服务器⼏核）。

Sockets （主板上CPU插槽个数）Memory (GB) 内存⼤⼩。

下⾯部分，快照信息。

snap id 快照id snap time
快照时间
session
会话
Cursors/Session
游标/ 会话
begin Snap(起始快照)
end snap （终⽌快照）
elapsed: (跨度)
DB TIme（请求时间）
其中，快照起始/终⽌时间和起始/终⽌Id是创建awr报告的时候⾃⼰选的。

会话数量表⽰在这次快照采集的时间内，oracle总共有多少次会话链接。

Cursors/Session 每个会话平均使⽤多少个游标（游标，⼀个内存⼯作区，临时存储从数据库中提取的数据块）。

DB Time：是记录的服务器花在数据库运算 ( ⾮后台进程 ) 和等待( ⾮空闲等待 ) 上的时间。

不包括 Oracle 后台进程消耗的时间。

db time= cpu time + wait time（不包含空闲等待）（⾮后台进程）这⾥是这样算的：⾸先，有四个cpu总共耗时3.4mins 。

平均每隔cpu耗时不到⼀分钟。

cpu利⽤率只有 1/360（快照采集总间隔时间）百分之0.3不到，说明系统处于空闲状态。

这也是为什么我们要尽可能使⽤需要分析的时间段的快照来进⾏分析的原因，因为快照跨度太长，有可能会导致dbtime的指标受到影响。

2.报告简要信息
①.cache size 缓存⼤⼩
这⾥粗略的展⽰下系统的内存使⽤情况。

其中包括：Buffer Cache 数据⾼速缓冲区，存放着oracle访问的数据块，存满后，⾃动去除最不常⽤的数据。

通俗讲，就是将⾼频率使⽤的sql查询结果进⾏缓存，提⾼查询效率。

Std Block Size 数据块⼤⼩。

Shared Pool Size 共享池，⽤来缓存被执⾏的sql和被使⽤的数据定义。

包括 Library cache和Data dictionary cache ，Library cache ⽤来存放sql语句的⽂本，分析后代码及执⾏计划。

Data dictionary cache 缓存数据字典，存放有关表、列和其他字段及相对应的权限。

Log Buffer 全名redo log
buffer 缓存被执⾏的SQL语句和被使⽤的数据定义。

②.Load Profile 数据库负载属性信息
DB Times 请求时间等待cpu的时间与数据库消耗CPU时间的总和。

DB CPU 数据库消耗cpu时间（所有⽤户的累加值）
Redo size 产⽣⽇志的⼤⼩，标识数据库的变更语句执⾏频率，数据库任务的繁忙程度。

Logical Read 逻辑读，从（或试图从）Buffer Cache中读取数据块。

逻辑读包括当前数据读取和⼀致性读取：Logical Reads= Consistent Gets + DB Block Gets 。

逻辑读受制于CPU性能，可以反映CPU使⽤情况。

Block changes 修改的数据块数量，标识数据的变化频率。

Physical Read 物理读数据块数量，物理读消耗io资源。

Physical writes 物理写数据块数量，包括写⼊数据库+写⼊缓存
User Calls ⽤户调⽤次数
Parses 解析次数，包括 fast parse ，软解析和硬解析。

其中fast parse 是最快的，直接在PGA中命中（需要设置
session_cached_cursors=n）；其次是软解析，在shared pool中命中；都不命中，则触发hard parse 。

parses 超过300 意味着SQL解析复⽤效率不⾼。

Hard Parses 硬解析，硬解析标识SQL不命中的次数，每秒应⼩于20次。

超过⼀百次，需要检查是不是共享池（shared pool）设置的不合理。

W/A MB processed ⼯作区处理的任务数量。

Logons ⽤户登录次数。

并发session越⾼，数值越⼤。

Executes 标识 SQL执⾏次数，反映执⾏效率。

Rollback 回滚次数。

Transactions 事物数。

每秒的事物数可以反映任务的繁重情况。

SQL解析过程：
软解析和硬解析，Oracle对SQL的处理过程：
1.语法检查（syntax check） 检查SQL语法是否符合规范。

2.语义检查（semantic check）检查SQL中对应的对象（表，视图等）是否存在及该⽤户是否具备相应的权限。

3.解析SQL语句（prase）对SQL进⾏解析，⽣成解析树（parse tree）及执⾏计划（execution plan）。

4.执⾏SQL 返回结果集。

⾸先，fast prase :在设置session_cursor_cache 这个参数后，Cursor被直接Cache在当前Session的PGA中，在解析的时候对SQL进⾏语法分析、权限对象分析之后。

先转到PGA中查找，如果发现完全相同的SQL，直接获取结果返回。

其次，软解析（soft parse）在第3步执⾏前，先在共享池（Shared Pool ）中找是否有相同的SQL，如果找到，直接使⽤该SQL解析好的解析树和执⾏计划。

最后，硬解析（Hard Parse）没有任何缓存，直接解析SQL并运⾏，得到相应返回结果。

逻辑读，物理读
逻辑读：指从Buffer Cache中读取数据块
1、及时读：即时读即读取数据块当前的最新数据。

任何时候在Buffer Cache中都只有⼀份当前数据块。

即时读通常发⽣在对数据进⾏修改、删除操作时。

这时，进程会给数据加上⾏级锁，并且标识数据为“脏”数据。

2、数据⼀致性读：Oracle是⼀个多⽤户系统。

当⼀个会话开始读取数据还未结束读取之前，可能会有其他会话修改它将要读取的数据。

如果会话读取到修改后的数据，就会造成数据的不⼀致。

⼀致性读就是为了保证数据的⼀致性。

在Buffer Cache中的数据块上都会有最后⼀次修改数据块时的SCN。

如果⼀个事务需要修改数据块中数据，会先在回滚段中保存⼀份修改前数据和SCN的数据块，然后再更新Buffer Cache中的数据块的数据及其SCN，并标识其为“脏”数据。

当其他进程读取数据块时，会先⽐较数据块上的SCN和⾃⼰的SCN。

如果数据块上的SCN⼩于等于进程本⾝的SCN，则直接读取数据块上的数据；如果数据块上的SCN⼤于进程本⾝的SCN，则会从回滚段中找出修改前的数据块读取数据。

通常，普通查询都是⼀致性读。

物理读：数据块是oracle最基本的读写单位,但⽤户所需要的数据,并不是整个块,⽽是块中的⾏,或列.当⽤户发出SQL语句时,此语句被解析执⾏完毕，就开始了数据的抓取阶段,在此阶段,服务器进程会先将⾏所在的数据块从数据⽂件中读⼊buffer cache,这个过程叫做物理读，每读取⼀个块,就算⼀次物理读。

③. Instance Efficiency Percentages (Target 100%)
上⾯这些所有⽬标都是100%，越⼤越好。

正常情况下，值在0-100之间。

Buffer Nowat: session 在访问⼀个buffer时，⽴即可以访问的⽐率。

如果低于99%说明存在内存争⽤的情况。

Buffer Hit : 内存命中率。

在⼀般数据库中，如果此值低于80% 应该给数据库分配更多的内存。

如果命中率突然增⼤，可以检查 top buffer get SQL，查看导致⼤量逻辑读的语句和索引，如果命中率突然减⼩，可以检查 top physical reads SQL，检查产⽣⼤量物理读的语句，主要是那些没有使⽤索引或者索引被删除的。

Redo NoWait: 缓冲区获得Buffer未等待⽐例。

不低于90%，不太需要考虑。

In-memory Sort 内存中完成的排序⽐例。

应⼤于 95%，不太需要考虑。

Library Hit : 执⾏计划命中率，当应⽤程序调⽤SQL或存储过程的时候，如果在library Cache 中可以检索到执⾏计划，直接执⾏。

不存在，解析SQL并缓存。

如果该值低于90% 可能需要调⼤共享池的内存⼤⼩。

应保持在95%以上。

Soft Parse: 软解析⽐例。

重要解析指标。

软解析次数和总解析次数的⽐值，应该⼤于95 % 。

Execute to Parse 执⾏解析⽐ 1-（parse/execute）这⾥软解析也是解析次数，软解析依然会消耗DBTime 所以可以通过使⽤静态SQL，动态绑定、session_cached_cursor、open cursors等技术减少软解析。

Latch Hit ：数据块内部⾏锁不需要等待的⽐例。

应⼤于99%。

当前是因为系统中未共享SQL导致的低于该值。

Parse CPU To Parse Elapsd:该指标反映了快照内解析CPU时间和总的解析时间的⽐值(Parse CPU Time/ Parse Elapsed Time)；若该指标⽔平很低，那么说明在整个解析过程中实际在CPU上运算的时间是很短的，⽽主要的解析时间都耗费在各种其他⾮空闲的等待事件上了(如latch:shared pool,row cache lock之类等)
Non-Parse CPU ⾮解析cpu⽐例，公式为 (DB CPU – Parse CPU)/DB CPU，⽐值越⾼，说明执⾏查询⼯作的资源越多，分析查询的资源消耗越少。

④.Shared Pool Statistics
⼀个⼤概的SQL重⽤及共享池内存使⽤。

Memory Usage 共享池内存使⽤率，应稳定在 75%-90%之间。

如果太⼩，说明内存空间有浪费。

如果⾼于90% 说明内存不⾜，有内存争⽤的情况。

SQL with executions >1 复⽤的SQL占总的SQL语句的⽐率,如果值太⼩，需要优化SQL。

Memory for SQL w/exec>1 ：执⾏次数⼤于 1 的 SQL消耗内存的占⽐。

⼤概值会在 75-85% 之间。

⑤。

Top 5 Time Events
系统最严重的5个等待，正常情况下，DBCPU应该排在最前⾯。

Waits : 该等待事件发⽣的次数，对于DB CPU此项不可⽤
Times : 该等待事件消耗的总计时间，单位为秒，对于DB CPU ⽽⾔是前台进程所消耗CPU时间⽚的总和，但不包括Wait on CPU QUEUE
Avg Wait(ms) : 该等待事件平均等待的时间，实际就是 Times/Waits，单位ms，对于DB CPU此项不可⽤
Wait Class: 等待类型：Concurrency,System I/O,User
I/O,Administrative,Other,Configuration,Scheduler,Cluster,Application,Idle,Network,Commit
⑥ CPU
“Load Average” begin/end值代表每个CPU的⼤致运⾏队列⼤⼩。

%User+%System=> 总的CPU使⽤率。

%Total CPU,该实例所使⽤的CPU占总CPU的⽐例
%Busy CPU，该实例所使⽤的Cpu占总的被使⽤CPU的⽐例
`⑦.内存使⽤
host mem 主机内存.
SGA use SGA 使⽤内存。

SystemGlobal Area是OracleInstance的基本组成部分，在实例启动时分配;系统全局域SGA主要由三部分构成：共享池、数据缓冲区、⽇志缓冲区。

PGA use PGA内存。

ProcessGlobal Area是为每个连接到Oracledatabase的⽤户进程保留的内存。

Host Mem used for SGA+PGA: 数据库使⽤内存占总内存⽐例。