浅谈ORACLE AWR single instance 一

Oracle中的AWR,全称为Automatic Workload Repository,自动负载信息库。

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)。

时间: 2024-10-25 12:26:05

浅谈ORACLE AWR single instance 一的相关文章

浅谈oracle中rowid和rownum

[ 概要 ] 刚刚接触oracle的同学可能常常会被rowid和rownum这两个词弄混, 弄清楚这两个家伙对于我们写sql会有很大的帮助, 下面偶就抛砖引玉, 简单地谈谈他们之间的区别吧. [ 比较 ] rowid和rownum都是oracle中的伪列, 但他们还是存在本质区别: rowid: 是物理地址, 用于定位数据表中数据的位置, 它是唯一的且不会改变. rownum: 是根据查询的结果集给每行分配的一个逻辑编号, 查询结果不同, rownum自然不同. 对于同一条记录, 查询条件不同,

浅谈oracle数据库dbtime

1.如果等待时间比服务时间长很多,那我们就要优化等待时间,如果服务时间比等待时间长很多,就要先优化服务时间 这就是owi思想 那我们就需要判断整个数据库系统平均响应时间中服务时间(Service time)和等待时间(Wait time)各占的百分比.服务时间代表的是" CPU used by this session",是CPU服务会话所花费的所有时间.Response Time = Service Time + Wait TIme(即响应时间=cpu服务时间+等待时间) selec

浅谈oracle 12C的新特性-CDB和PDB

最近看到好多人都在尝试oracle中的12C新特性-容器数据库,今年3月orcle退出了Release2版本,可以算是一个稳定版本了.下午着手尝试了一下,还是蛮不错得 1.前言 CDB与PDB是Oracle 12C引入的新特性,在ORACLE 12C数据库引入的多租用户环境(Multitenant Environment)中,允许一个数据库容器(CDB)承载多个可插拔数据库(PDB).CDB全称为ContainerDatabase,中文翻译为数据库容器,PDB全称为Pluggable Datab

浅谈Oracle事务【转载竹沥半夏】

所谓事务,他是一个操作序列,这些操作要么都执行,要么都不执行,是一个不可分割的工作单元.通俗解释就是事务是把很多事情当成一件事情来完成,也就是大家都在一条船上,要死一起死,要活一起活. 为什么要引入事务?事务处理可以确保除非事务性单元内的所有操作都成功完成,否则不会永久更新面向数据的资源.通过将一组相关操作组合为一个要么全部成功要么全部失败的单元,可以简化错误恢复并使应用程序更加可靠.事务结束后,能保证数据库数据的一致性.例如银行转账,一个账号扣钱,一个账号增款,要么都执行,要么都不执行,不能只

浅谈Oracle表之间各种连接

Oracle表之间的连接分为三种: 1.内连接(自然连接) 2.外连接 2.1.左外连接(左边的表不加限制,查询出全部满足条件的结果) 2.2.右外连接(右边的表不加限制,查询出全部满足条件的结果) 2.3.全外连接(左右两边表均不加限制) 3.自连接(同一张表内的连接) SQL的标准写法: select table1.column,table2.column from table1 [inner|left|right|full] join table2 on table1.column1 =

浅谈Oracle函数返回Table集合

在调用Oracle函数时为了让PL/SQL 函数返回数据的多个行,必须通过返回一个 REF CURSOR 或一个数据集合来完成.REF CURSOR 的这种情况局限于可以从查询中选择的数据,而整个集合在可以返回前,必须进行具体化. 9i 通过引入Oracle函数中的管道化表函数纠正了后一种情况.表函数是返回整个行的集(通常作为一个集合)的函数,可以直接从 SQL 语句中进行查询,就好像它是一个真正的数据库表一样.管道化表函数与之相似,但是它像在构建时一样返回数据,而不是一次全部返回.管道化表函数

浅谈oracle逻辑备份、数据泵备份及冷备份

逻辑备份(数据迁移):以逻辑结构为为单位进行的备份跨用户移动数据跨数据库移动数据库为测试保存原始的数据状态对数据库进行版本升级 逻辑导出的注意事项:exp程序在目录中发现同名文件时会直接覆盖,不提示!!exp无法备份无段的空表执行逻辑导出时一定要注意字符集!最好使用包含中文的小表做测试!!导入时的数据和导出时的数据一模一样,导出之后数据库中表的数据变化全都丢失!! 逻辑导出:所有版本都可用,服务器端和客户端都可用 mkdir -p /home/oracle/expbk SQL> create t

浅谈oracle事务

所谓事务,他是一个操作序列,这些操作要么都执行,要么都不执行,是一个不可分割的工作单元.通俗解释就是事务是把很多事情当成一件事情来完成,也就是大家都在一条船上,要死一起死,要活一起活. 为什么要引入事务?事务处理可以确保除非事务性单元内的所有操作都成功完成,否则不会永久更新面向数据的资源.通过将一组相关操作组合为一个要么全部成功要么全部失败的单元,可以简化错误恢复并使应用程序更加可靠.事务结束后,能保证数据库数据的一致性.例如银行转账,一个账号扣钱,一个账号增款,要么都执行,要么都不执行,不能只

浅谈ORACLE SQL语句优化经验

(1) 选择最有效率的表名顺序(只在基于规则的seo/' target='_blank'>优化器中有效): ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. (2) WHERE子句中的连接顺序.