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

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

17

积分

0

好友

10

主题
1#
发表于 2013-3-18 17:14:35 | 查看: 4356| 回复: 5
本帖最后由 am196 于 2013-3-18 18:10 编辑

我的数据为是11.2.0.1.0
系统 Red Hat Enterprise Linux Server release 5.3
帮我看一下,附件为我的AWR报告和初始化参数
数据库等待事件只要一出现
PX Deq: Execution Msg
PX Deq Credit: send blkd
这个,我的数据库不很忙.
是不是我哪个参数没有设置好,帮忙看一下,谢谢.

最后2个AWR时间短一些.
AWR显示直接路径等待更多一些.
难道v$session_wait看不出直接路径等待.
并行等待.png

awrdcpos20130318.html

666.11 KB, 下载次数: 790

initdcpos.txt

1.09 KB, 下载次数: 1351

awrdcpos20130318v2.html

579.26 KB, 下载次数: 759

awrdcpos20130318v3.html

562.23 KB, 下载次数: 773

2#
发表于 2013-3-18 19:59:34
这三个 快照 PX 并行执行都不是主要等待事件:

Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
DB CPU                 11,940                 65.85         
db file sequential read        2,233,356        3,415        2        18.83        User I/O
direct path read        10,973,301        3,412        0        18.82        User I/O
direct path write temp        19,058        831        44        4.59        User I/O
cursor: pin S wait on X        478        267        559        1.47        Concurrency


Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
DB CPU                 5,014                 85.39         
direct path read        4,623,928        1,041        0        17.73        User I/O
direct path write temp        3,448        328        95        5.59        User I/O
db file sequential read        31,534        125        4        2.14        User I/O
cursor: pin S wait on X        158        87        548        1.48        Concurrency

回复 只看该作者 道具 举报

3#
发表于 2013-3-18 20:03:44
table scans (direct read)        10,152,837        217.05        18,459.70
table scans (long tables)        10,158,273        217.16        18,469.59

有一些大表的 direct path read倒是真的。

11g direct path read介绍:10949 event、_small_table_threshold与_serial_direct_read
http://www.askmaclean.com/archiv ... al_direct_read.html

回复 只看该作者 道具 举报

4#
发表于 2013-4-20 16:40:08
Maclean Liu(刘相兵 发表于 2013-3-18 20:03
table scans (direct read)        10,152,837        217.05        18,459.70
table scans (long tables)        10,158,273        217.16        18 ...

操作系统由原来的redhat5.3升级到了oracle  
6.3数据库由原来的11.2.0.1.0升级到11.2.0.3.0上之后没有这个现像了.

回复 只看该作者 道具 举报

5#
发表于 2013-4-20 16:42:19
怀疑 是db_cache_size加大了吧

回复 只看该作者 道具 举报

6#
发表于 2013-4-20 16:59:39
Maclean Liu(刘相兵 发表于 2013-4-20 16:42
怀疑 是db_cache_size加大了吧

没有加大,都是用memory_target去管理的.200G的memory_target

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-12-27 20:11 , Processed in 0.053176 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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