浅谈oracle数据库dbtime

Posted 2020-08-15

                                               浅谈oracle数据库dbtime

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

SQL> select a.value "Total CPU time" from v$sysstat a where a.name=‘CPU used by this session‘;
Total CPU time
--------------
    997592
Elapsed: 00:00:00.01
SQL>

2、会话级
(1)查看统计号 这里为2
select statistic# from v$statname where name=‘CPU used by this session‘；

SQL> select statistic# from v$statname where name=‘CPU used by this session‘；
  2

(2)查v$sesstat
select sid,a.value "Total CPU time " from  v$sesstat a where a.statistic#=2;

查看每一个会话的cpu时间

SQL> select sid,a.value "Total CPU time " from  v$sesstat a where a.statistic#=2;
       SID Total CPU time
---------- ---------------
     1         1
     2         1
    22         1
    23         1
    43         1
    44         1
    46         1
    64         1
    65         1
    66         1
    85         1
    86         1
    88         1
   107         1
   108         1
   109         1
   127         1
   129         1
   148         1
   149         1
   169         1
   172         1
   173         1
   190         1
   191         1
   193         1
   211         1
   213         1
   232         1
   233         1
30 rows selected.

3、Service Time　＝　SQL解析时间　＋　递归调用时间　＋　其它时间
(1)SQL/PLSQL等解析时所花的时间，如果解析时间超过总的CPU服务时间20%，那么需要调优应用程序代码，比如绑定变量、SESSION_CURSOR_CACHE等
怎么样来查看SQL解析时间呢？分实例级和会话级
实例级：
select NAME,statistic# from v$statname where name like ‘%parse%‘;

SQL> select NAME,statistic# from v$statname where name like ‘%parse%‘;
NAME                                 STATISTIC#
---------------------------------------------------------------- ----------
parse time cpu                                547
parse time elapsed                            548
parse count (total)                            549
parse count (hard)                            550
parse count (failures)                            551
parse count (describe)                            552

select a.value "Total parse Cpu time" from v$sysstat a where a.name=‘parse time cpu‘;
统计号是548

SQL> select a.value "Total parse Cpu time" from v$sysstat a where a.name=‘parse time cpu‘;
Total parse Cpu time
--------------------
           64984
Elapsed: 00:00:00.00

会话级：
select sid,a.value "Total parse Cpu time" from v$sesstat a where a.statistic#=548;

SQL> select sid,a.value "Total parse Cpu time" from v$sesstat a where a.statistic#=548;
       SID Total parse Cpu time
---------- --------------------
     1              0
     2              0
    22              0
    23              0
    43              0
    44            785
    46              4
    64              0
    65              2
    66              5
    85              0
    86            225
    88              0
   107              0
   108              2
   109              0
   127              1
   129              3
   148              0
   149              6
   169              0
   172              0
   173              0
   190              0
   191              0
   211              0
   213              0
   232              0
   233            571
29 rows selected.

(2)    递归调用时间是用在：语义分析阶段查找数据字典或者PLSQL内部包造成的解析所花的CPU时间。就是内部字典的一些动作。
select name,statistic# from v$statname where name like ‘%cpu%‘;

SQL> select name,statistic# from v$statname where name like ‘%cpu%‘;
NAME                                 STATISTIC#
---------------------------------------------------------------- ----------
recursive cpu usage                              9
parse time cpu                                547

这里统计号为9
select a.value "Total recursive Cpu time" from v$sysstat a where a.name=‘recursive cpu usage‘;

SQL> select a.value "Total recursive Cpu time" from v$sysstat a where a.name=‘recursive cpu usage‘;
Total recursive Cpu time
------------------------
          509888
Elapsed: 00:00:00.00

通过查找v$sysstat,v$sesstat,我们可以查看到递归调用的时间。
我们知道sga分类为library cache+rowcache
rowcache数据字典(data dictionary cache )
数据字典cache怎么优化？多半是一些不规范的参数导致, _row_cr  11g 隐含参数的问题

(3)一般来说。其他时间 ，在这里是花费最多的时间(多cpu 的 调度也在这里)

总的来说
select a.value "Total CPU",b.value "parse CPU",c.value "recursive CPU",a.value - b.value - c.value "Other"
from v$sysstat a, v$sysstat b, v$sysstat c
where a.name=‘CPU used by this session‘
and b.name=‘parse time cpu‘
and c.name=‘recursive cpu usage‘;

SQL> select a.value "Total CPU",b.value "parse CPU",c.value "recursive CPU",a.value - b.value - c.value "Other"
from v$sysstat a, v$sysstat b, v$sysstat c 
where a.name=‘CPU used by this session‘
and b.name=‘parse time cpu‘
  5  and c.name=‘recursive cpu usage‘;
 Total CPU  parse CPU recursive CPU     Other
---------- ---------- ------------- ----------
    998928    64995         509941    423992
Elapsed: 00:00:00.01

刚刚好： 998928 = 64995 + 509941 + 423992
(4)等待事件分两类: 非空闲 + 空闲等待事件(IDLE)
大部分空闲等待事件   都是客户端相关的消息传输事件
大量idel等待事件造成的性能问题，极有可能是应用服务器本身问题，或者网络问题,因为cpu 都空闲了。

查看下数据库的等待事件数据
select event,time_waited,average_wait from v$system_event
where event not in (
‘pmon time‘,
‘smon timer‘,
‘rdbms ipc message‘,
‘parallel dequeue wait‘,
‘virtual circuit‘,
‘SQL*Net message from client‘,
‘client message‘,
‘NULL event‘
)
order by time_waited desc;

结果如下：
EVENT                                 TIME_WAITED AVERAGE_WAIT
---------------------------------------------------------------- ----------- ------------
DIAG idle wait                               935522655       100.09
jobq slave wait                            497321787        50.08
shared server idle wait                        467876357      3000.92
Streams AQ: qmn coordinator idle wait                   467875026      1400.44
Streams AQ: qmn slave idle wait                    467873982      2737.96
dispatcher timer                           467872026      6000.98
pmon timer                               467819350       264.77
Space Manager: slave idle wait                       467784915        499.1
Streams AQ: waiting for time management or cleanup tasks       464980103   1690836.74
VKRM Idle                               169919651   3146660.21
os thread startup                              290703         1.59
control file parallel write                          126076          .08
log file parallel write                           100734          .03
log file sync                                   61970          .08
db file async I/O submit                           34403          .03
library cache lock                               22077       959.85
PL/SQL lock timer                               12407        98.47
control file sequential read                        6042        0
ADR block file read                            1845          .11
auto-sqltune: wait graph update                     1500       250.02
Disk file operations I/O                        1482        0
direct path sync                             778         1.05
log file switch completion                         537          .81
control file heartbeat                             400          400
reliable message                             392          .05
SQL*Net message to client                         375        0
db file sequential read                          364          .01
resmgr:internal state change                         342        10.06
class slave wait                             327          .01
asynch descriptor resize                         326        0
switch logfile command                             227        56.68
rdbms ipc reply                              209          .06
enq: CR - block range reuse ckpt                     134          .07
LGWR wait for redo copy                          112        0
undo segment extension                             110          .75
ADR block file write                              91          .01
db file scattered read                              85          .01
log file single write                              55          .04
JS coord start wait                              50        50.02
enq: PR - contention                              36         1.17
db file single write                              35          .02
enq: RO - fast object reuse                          27          .01
latch: shared pool                              25          .03
direct path write temp                              24          .01
latch free                                  19          .15
Data file init write                              15          .21

这是oracle性能调优的基础。

本文出自 “梁小明的博客” 博客，请务必保留此出处http://7038006.blog.51cto.com/7028006/1863399