浅谈ORACLE AWR single instance 一
AWR是DBA了解其运行状态的重要工具之一,根据AWR报告可以对oracle数据库性能整体了解并针对性优化,此文章主要是介绍AWR相关部分的内容。
DB Name DB Id Instance Inst Num Startup Time Release RAC
------------ ----------- ------------ -------- --------------- ----------- ---
1 16-Jan-17 09:27 11.2.0.4.0 NO
Host Name Platform CPUs Cores Sockets Memory(GB)
---------------- -------------------------------- ---- ----- ------- ----------
Linux x86 64-bit 8 8 2 7.81
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 10848 14-Mar-17 09:00:51 66 1.4
End Snap: 10849 14-Mar-17 10:00:55 66 1.5
Elapsed: 60.07 (mins)
DB Time: 0.93 (mins)
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 Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~~~~ --------------- --------------- --------- ---------
DB Time(s): 0.0 0.0 0.00 0.00
DB CPU(s): 0.0 0.0 0.00 0.00
Redo size (bytes): 1,343.6 3,388.8
Logical read (blocks): 394.1 993.9
Block changes: 5.4 13.6
Physical read (blocks): 0.4 1.1
Physical write (blocks): 0.6 1.4
Read IO requests: 0.4 1.1
Write IO requests: 0.4 1.1
Read IO (MB): 0.0 0.0
Write IO (MB): 0.0 0.0
User calls: 64.8 163.4
Parses (SQL): 21.0 52.9
Hard parses (SQL): 0.0 0.1
SQL Work Area (MB): 0.2 0.5
Logons: 0.1 0.2
Executes (SQL): 22.2 55.9
Rollbacks: 0.0 0.0
Transactions: 0.4
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等待占比比较大
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的队列时间)
继续分析
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
事务数
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 100.00 In-memory Sort %: 100.00
Library Hit %: 99.30 Soft Parse %: 99.79
Execute to Parse %: 5.27 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 78.31 % Non-Parse CPU: 94.25
此模块记录oracle instance memory的使用信息,目标为100%,针对OLTP系统,此模块信息比较重要,对于OLAP系统,意义不大。
Buffer Nowait%
非等待方式获取数据块的百分比
这个值偏小,说明发生SQL访问数据块时数据块正在被别的会话读入内存,需要等待这个操作完成。发生这样的事情通常就是某些数据块变成了热块。
Buffer Nowait<95%说明,有可能是有热块(查找x$bh的 tch和v$latch_children的cache buffers chains)。
Redo Nowait
非等待获取redo数据
Buffer Hit%
数据缓存命中率
In-memory Sort%
数据排除操作在内存中的百分比
Library Hit%
共享池中SQL解析的命中率
(相关参数SHARED_POOL_SIZE\BINGD VALUE\CURSOR_SHARING)
Soft Parse %
软解析占解析的比率 value偏低表示DB中多数SQL没有被重用 <95%考虑绑定变量
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时间的百分比。
Shared Pool Statistics Begin End
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------ ------
Memory Usage %: 87.44 87.82
% SQL with executions>1: 98.06 97.25
% Memory for SQL w/exec>1: 92.56 92.46
Memory Usage %
共享池内存使用率。
应该稳定在70%-90%间,太小浪费内存,太大则内存不足。
% SQL with executions>1
执行次数大于1的SQL比率。
若太小可能是没有使用绑定变量。
% Memory for SQL w/exec>1
执行次数大于1的SQL消耗内存/所有SQL消耗的内存(即memory for sql with execution > 1)。
转载于:https://blog.51cto.com/kevinora/1906368
浅谈ORACLE AWR single instance 一相关推荐
- oracle hash join outer,CSS_浅谈Oracle中的三种Join方法,基本概念
Nested loop join:
Outer - phpStudy...
浅谈Oracle中的三种Join方法 基本概念 Nested loop join: Outer table中的每一行与inner table中的相应记录join,类似一个嵌套的循环. Sort mer ...
- 浅谈Oracle RAC --集群管理软件GI
浅谈Oracle RAC --集群管理软件GI基本架构 今天周五,想想可以过周末,心情大好.一周中最喜欢过的就是周五晚上,最不喜欢过的是周日晚上和周一,看来我不是个热爱劳动的人啊.趁着现在心情愉悦,赶 ...
- 浅谈oracle树状结构层级查询
oracle树状结构查询即层次递归查询,是sql语句经常用到的,在实际开发中组织结构实现及其层次化实现功能也是经常遇到的,虽然我是一个java程序开发者,我一直觉得只要精通数据库那么对于java开发你 ...
- 浅谈oracle树状结构层级查询测试数据
浅谈oracle树状结构层级查询 oracle树状结构查询即层次递归查询,是sql语句经常用到的,在实际开发中组织结构实现及其层次化实现功能也是经常遇到的,虽然我是一个java程序开发者,我一直觉得只 ...
- 单引号oracle如何转义_浅谈oracle中单引号转义
ORACLE 单引号转义: 在ORACLE中,单引号有两个作用: 1:字符串是由单引号引用 2:转义. 单引号的使用是就近配对,即就近原则.而在单引号充当转义角色时相对不好理解 1.从第二个单引号开始 ...
- 浅谈Oracle RAC -- OHAS组件
浅谈Oracle RAC – OHAS组件 懒惰了一周没有更新博客.这两天天气不好,索性利用今天下午的时间继续写一篇关于OHAS组件的介绍. 之前我们多次提到了OHAS组件是GI的根守护进程.这个组件 ...
- 浅谈Oracle 数据库之间数据同步方案
随着信息技术的飞速发展,企业信息化建设的不断深入,使得企业业务系统数量不断增加.这时,各业务系统之间数据交互,各子业务系统与核心业务系统之间数据交互,诸如此类场景的应用需求不断出现.因此,IT部门应对 ...
- 浅谈Oracle服务器归档日志,oracle服务器运行时管理归档日志文件不管理联机重做日志文件...
<Oracle数据库管理与维护实战>--2.4 Oracle后台进程结构 本节书摘来自异步社区出版社<Oracle数据库管理与维护实战>一书中的第2章,第2.4节,作者: 何伟 ...
- 浅谈Oracle Online redo log
Oracle online redo log是Oracle数据库中核心文件之一.在数据库操作中,只要有任何的数据块变化,都会生成相应的redo entry.redo entry首先保存在log buf ...
最新文章
- matlab中fill函数的使用方法
- NET面试题:C#中的lock关键字有何作用
- 最明的int和Integer的区别
- 【H2 Database】shell
- HTTPS连接的前几毫秒发生了什么
- Notepad++ 插件之 TextFX (安装及作用)
- 机器人离线编程画圆误差解决方案_工业机器人离线编程-误差分析和解决方案...
- 数据挖掘应用实战-一文教你如何全面分析股市数据特征
- 创业产品经理需要懂技术吗?
- app登录界面背景 css_Google flutter这么火?撸一个APP登录界面(上)
- Caused by: java.lang.UnsatisfiedLinkError: libjawt.so: 无法打开共享对象文件: 没有那个文件或目录
- 快速入门Sass:Sass中的体系结构
- Unity--Configurable Joint——实战带你了解可配置关节
- 基于Docker部署OpenLDAP,同时集成第三方系统(GitLab、JIRA、Nexus、Harbor)
- 三步实现自动注册工厂替代switch语句(c++)
- 水果店开业如何做开店活动,新水果店开业需要做哪些促销活动
- 教你用python制作证件照片啦学会再也不用跑去照相馆拍照了~
- 【2020 ACM Fellow 华人学者】 陶宇飞 香港中文大学
- linux 创建子进程,Linux中使用fork创建子进程详解及示例程序
- Class文件结构介绍[常量池],埃森哲java技术面试题