广告
返回顶部
首页 > 资讯 > 数据库 >浅谈ORACLE AWR single instance 一
  • 394
分享到

浅谈ORACLE AWR single instance 一

2024-04-02 19:04:59 394人浏览 独家记忆
摘要

oracle中的AWR,全称为Automatic Workload Repository,自动负载信息库。 AWR是DBA了解其运行状态的重要工具之一,根据AWR报告可以对oracle数据库性能整

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


您可能感兴趣的文档:

--结束END--

本文标题: 浅谈ORACLE AWR single instance 一

本文链接: https://www.lsjlt.com/news/38196.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

本篇文章演示代码以及资料文档资料下载

下载Word文档到电脑,方便收藏和打印~

下载Word文档
猜你喜欢
  • 浅谈ORACLE AWR single instance 一
    Oracle中的AWR,全称为Automatic Workload Repository,自动负载信息库。 AWR是DBA了解其运行状态的重要工具之一,根据AWR报告可以对oracle数据库性能整...
    99+
    2022-10-18
  • 如何高效学习oracle数据库浅谈之一
    文章具体内容请移步如下链接:http://mp.weixin.qq.com/s__biz=MzIwMjU2MjI1OQ==&tempkey=sXhfnzfIdrymRA7B8csLCRQWvqPIs...
    99+
    2022-10-18
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作