Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

14

积分

0

好友

1

主题
1#
发表于 2013-4-9 10:27:04 | 查看: 4296| 回复: 4
version: 10.2.0.4.0
single instance

在数据库负载高的时候做了个ash
发现如下
  1. Top Event P1/P2/P3 Values

  2. Event        % Event        P1 Value, P2 Value, P3 Value        % Activity        Parameter 1        Parameter 2        Parameter 3
  3. db file sequential read         57.70         "1","182","1"         0.03         file#         block#         blocks
  4. read by other session         30.23         "9","372385","1"         0.18         file#         block#         class#
复制代码
从ASH观察来看产生db file sequential read
file# 为1的是system tablespace

以下是
  1. SELECT SID, EVENT, P1, P2 , P3 FROM v$session_wait where event='db file sequential read'
  2. 319        db file sequential read        19        658840        1
  3. 320        db file sequential read        9        721688        1
  4. 356        db file sequential read        11        492428        1
  5. 397        db file sequential read        13        2505        1
  6. 426        db file sequential read        9        733009        1
  7. 452        db file sequential read        13        274647        1
  8. 463        db file sequential read        13        279263        1
  9. 505        db file sequential read        12        550428        1
复制代码
在这里并没有看到ASH里的那种情况
请各位高手给解释下原因
是ASH 错了吗?
5#
发表于 2013-4-9 13:11:50
Stone 发表于 2013-4-9 12:24
我的理解是: ASH是对过去一段时间top sesssions消耗各种资源的一个快速定位。比如说你的ASH里面对于过去5分 ...

对不起 我没有说清楚... 我是先 用SQL语句查出来了有
db file sequential read
然后再做的 ASH
而且我主要的疑惑不是ASH和SQL查出来的不同而是
ASH里显示的system tablespace 有 很多db file sequential read
我从下面的SQL没有发现有对system tablespace 有大量读的操作

回复 只看该作者 道具 举报

4#
发表于 2013-4-9 12:24:17
我的理解是: ASH是对过去一段时间top sesssions消耗各种资源的一个快速定位。比如说你的ASH里面对于过去5分钟里的一个ASH report TOP消耗,这个是过去式。但是v$session_wait展示的是正在等待的资源,是进行式。

比如下面我们的一个Prod环境的v$session_wait显示,就是在时刻的变化。
  1. SQL> set time on
  2. 05:16:29 SQL> /

  3.        SID EVENT                          P1         P2         P3
  4. ---------- -------------------------- ------ ---------- ----------
  5.        776 db file sequential read       164    1335452          1
  6.        807 db file sequential read       505    1407484          1
  7.        829 db file sequential read       164    1337785          1
  8.        871 db file sequential read        16    1597843          1

  9. 05:16:30 SQL> /

  10.        SID EVENT                          P1         P2         P3
  11. ---------- -------------------------- ------ ---------- ----------
  12.        776 db file sequential read       164    1256649          1
  13.        807 db file sequential read       252    1794647          1
  14.        829 db file sequential read       164    1225162          1
  15.        871 db file sequential read       167       8718          1

  16. 05:16:32 SQL> /

  17.        SID EVENT                          P1         P2         P3
  18. ---------- -------------------------- ------ ---------- ----------
  19.        776 db file sequential read       164    1433413          1
  20.        807 db file sequential read       380    1667079          1
  21.        829 db file sequential read       164    1382206          1

  22. 05:16:39 SQL> /

  23.        SID EVENT                          P1         P2         P3
  24. ---------- -------------------------- ------ ---------- ----------
  25.        776 db file sequential read       164    1289904          1
  26.        807 db file sequential read       167     333228          1
  27.        829 db file sequential read       494    1890465          1
  28.        871 db file sequential read       167      48867          1

  29. 05:16:42 SQL> /

  30.        SID EVENT                          P1         P2         P3
  31. ---------- -------------------------- ------ ---------- ----------
  32.        776 db file sequential read       144    2068195          1
  33.        807 db file sequential read       167     128663          1
  34.        829 db file sequential read       164    1387365          1

  35. 05:16:44 SQL> /

  36.        SID EVENT                          P1         P2         P3
  37. ---------- -------------------------- ------ ---------- ----------
  38.        776 db file sequential read       164    1484652          1
  39.        807 db file sequential read       380    1613710          1
  40.        829 db file sequential read       164    1377823          1
  41.        871 db file sequential read         9     464006          1

  42. 05:16:46 SQL> /

  43.        SID EVENT                          P1         P2         P3
  44. ---------- -------------------------- ------ ---------- ----------
  45.        776 db file sequential read       164    1448586          1
  46.        807 db file sequential read       380    1510804          1
  47.        829 db file sequential read       163    1268733          1
  48.        871 db file sequential read       398     167186          1
复制代码

回复 只看该作者 道具 举报

3#
发表于 2013-4-9 11:23:51
Maclean Liu(刘相兵 发表于 2013-4-9 10:51
不对比下时间就说ASH错了?请勿搞笑

因为都是在负载高的时候做

的ASH是最近5分钟的
导致没有仔细对比时间
抱歉
ashrpt_1_0409_0957.html (34.92 KB, 下载次数: 715)

其实我更多的疑问是为何system tablespace
有很多db file sequential read

回复 只看该作者 道具 举报

2#
发表于 2013-4-9 10:51:01
不对比下时间就说ASH错了?请勿搞笑

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-16 13:56 , Processed in 0.071123 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569