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

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

-10

积分

1

好友

4

主题
1#
发表于 2013-4-8 21:44:32 | 查看: 6603| 回复: 5
各位帮忙看一下这个AWR报告,今天运维人员反应数据库非常慢。报告中发现enq: TT - contention等待时间很高,谢谢!

awrrpt_1_189_192.zip

82.33 KB, 下载次数: 1111

awrrpt_1_189_192

nbdb_ora_378.zip

5.65 KB, 下载次数: 1123

nbdb_ora_378.trc

2#
发表于 2013-4-8 21:48:48
select space, ORIGINAL_NAME,TS_NAME from dba_recyclebin order by 1 asc;

还有alert.log

回复 只看该作者 道具 举报

3#
发表于 2013-4-8 22:03:18
已传,麻烦刘大

alert_nbdb.zip

122.64 KB, 下载次数: 1095

alert log

dba_recyclebin.zip

2.16 KB, 下载次数: 1077

dba_recyclebin

回复 只看该作者 道具 举报

4#
发表于 2013-4-8 22:13:35
enq: tt应当与 回收recyclebin中对象空间 以及segment分配extent有关

TOP SQL是:

insert /*+ append */ into t_indoor_leak_sampling

insert append大量数据是会引起回收recyclebin中对象空间 以及segment分配extent的 。

但为什么enq: TT - contention会这么慢  ,可能与IO有关,至少目前看到的Io并不好

db file sequential read        2,368,962        13,837        6        19.47        User I/O
log file sync        196,804        2,322        12        3.27        Commit
db file scattered read        20,792        302        15        0.43        User I/O


-------------------------------------------------------------------------------
Chain 1:
-------------------------------------------------------------------------------
    Oracle session identified by:
    {
                instance: 1 (nbdb.nbdb)
                   os id: 29735
              process id: 25, oracle@TMC220
              session id: 1202
        session serial #: 40881
    }
    is not in a wait:
    {
               last wait: 0.023747 sec ago
                blocking: 0 sessions
             short stack: ksedsts()+480<-ksdxfstk()+48<-ksdxcb()+3040<-sspuser()+688<-<kernel><-kcbgtcr()+14496<-ktrget2()+1184<-kds
grp()+1344<-qetlbr()+432<-qertbFetchByRowID()+1552<-qergiFetch()+624<-qerjoFetch()+1120<-rwsfcd()+320<-qerhjFetch()+1952<-qerghFetch
()+624<-rwsfcd()+320<-qerltcFetch()+1584<-insexe()+2080<-opiexe()+10800<-kpoal8()+5088<-opiodr()+2368<-ttcpip()+2368<-opitsk()+2848<
-opiino()+1680<-opiodr()+2368<-opidrv()+1264<-sou2o()+256<-opimai_real()+256<-ssthrdmain()+432<-main()+464<-main_opd_entry()+80
            wait history:
              1.       event: 'kfk: async disk IO'
                 time waited: 0.000015 sec
                     wait id: 51510           p1: 'count'=0x1
                                              p2: 'intr'=0x0
                                              p3: 'timeout'=0xffffffff
              * time between wait #1 and #2: 0.067130 sec
              2.       event: 'kfk: async disk IO'
                 time waited: 0.000011 sec
                     wait id: 51509           p1: 'count'=0x1
                                              p2: 'intr'=0x0
                                              p3: 'timeout'=0xffffffff
              * time between wait #2 and #3: 0.064147 sec
              3.       event: 'kfk: async disk IO'
                 time waited: 0.000016 sec
                     wait id: 51508           p1: 'count'=0x1
                                              p2: 'intr'=0x0
                                              p3: 'timeout'=0xffffffff
    }


kfk: async disk IO==》ASM


建议你 关闭recyclebin 或者 定期purge recyclebin;

HPUX平台上用ASM不太好, 还是裸设备稳定

回复 只看该作者 道具 举报

5#
发表于 2013-4-8 22:20:52
谢谢刘大,看还是得做个定期purge recyclebin;
目前ASM磁盘组是有10块磁盘,每块500G,是从3PARdata存储上划分过来的,增加一些磁盘应该能改善一下IO吧

回复 只看该作者 道具 举报

6#
发表于 2013-4-9 00:17:49
TEMP        +DATA_DG/nbdb/tempfile/temp.268.811181287        21,184        2        0.00        5.45        2,371,384        220        1        30.00

看来是写的temp次数多,并且 时间长 。
应该是和大量的sqlldr也有关。

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-12-27 15:21 , Processed in 0.054452 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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