快捷導(dǎo)航

Oracle內(nèi)存分配不足的過(guò)程解析(業(yè)務(wù)干掛數(shù)據(jù)庫(kù))

更新時(shí)間：2025年02月15日 10:25:22 作者：IT邦德

本文介紹了Oracle數(shù)據(jù)庫(kù)內(nèi)存分配不足的問(wèn)題,原因主要是業(yè)務(wù)劇增導(dǎo)致的內(nèi)存不足,通過(guò)分析AAS負(fù)載、等待事件、transactions和阻塞情況,發(fā)現(xiàn)PGA內(nèi)存出現(xiàn)了嚴(yán)重抖動(dòng),感興趣的朋友一起看看吧

1.故障現(xiàn)象

應(yīng)用反饋數(shù)據(jù)庫(kù)已經(jīng)夯住，通過(guò)監(jiān)控平臺(tái)看到很多高警如下，初步判定跟Log file sync有關(guān)系，但是別經(jīng)驗(yàn)主義，詳細(xì)的分析還要看具體報(bào)告！

Warning: log write elapsed time 783ms, size 5KB
*** 2025-01-20T11:56:02.114674+08:00
Warning: log write elapsed time 2215ms, size 4KB
*** 2025-01-20T12:00:30.111624+08:00
Warning: log write elapsed time 657ms, size 146KB
*** 2025-01-20T12:02:39.413947+08:00
Warning: log write elapsed time 534ms, size 109KB
*** 2025-01-20T12:02:40.422849+08:00
Warning: log write elapsed time 578ms, size 86KB
*** 2025-01-20T12:02:40.981447+08:00
Warning: log write elapsed time 558ms, size 41KB

2. 分析過(guò)程

2.1 AAS負(fù)載

一看AAS,嚇一跳啊，AAS>> # of CPUS，這明顯的出現(xiàn)了很嚴(yán)重的性能瓶頸。

2.2 等待事件

等待事件是衡量數(shù)據(jù)庫(kù)優(yōu)化情況的重要指標(biāo)，明顯出現(xiàn)了異常。

acknowledge over PGA limit的解釋為：如果實(shí)例接近PGA_AGGREGATE_LIMIT限制，它將迫使需要更多PGA的進(jìn)程等待一段時(shí)間，同時(shí)發(fā)現(xiàn)了PGA的內(nèi)存在故障期間嚴(yán)重出現(xiàn)了內(nèi)存抖動(dòng)。

再次確認(rèn)數(shù)據(jù)庫(kù)參數(shù)的設(shè)置，PGA_AGGREGATE_LIMIT為20G，sga_target為55G，processes為5120的設(shè)置，按照官方的經(jīng)驗(yàn)其實(shí)這是是合理的。

（1）OLTP系統(tǒng)：
SGA_TARGET = (total_mem * 0.8) * 0.8
PGA_AGGREGATE_TARGET=(total_mem * 0.8) * 0.2
（2）OLAP（DSS）系統(tǒng)：
SGA_TARGET= (total_mem * 0.8) * 0.5
PGA_AGGREGATE_TARGET =(total_mem * 0.8) * 0.5
（3）PGA_AGGREGATE_LIMIT=3MB*processes
RAC環(huán)境為：PGA_AGGREGATE_LIMIT=5MB*processes

那么這次怎么會(huì)導(dǎo)致over PGA limit呢？最大可能為業(yè)務(wù)劇增，那么繼續(xù)排查。

那么如果想盡快恢復(fù)業(yè)務(wù)，可以臨時(shí)設(shè)置PGA_AGGREGATE_LIMIT=0處理，但這不是長(zhǎng)久之計(jì)。

2.3 transactions分析

ADDM的報(bào)告中也給出了這個(gè)結(jié)論，明顯出現(xiàn)了劇增的業(yè)務(wù)。

一般來(lái)說(shuō)transactions不超過(guò)200都是正常的，或者200左右都是正常的，超多1000就是非常繁忙了！

user calls/(user commits+user rollbacks) 本次平均值為4.84= 4.84/(0.33+0.67) ，平均每4.84 次 user calls 就會(huì)有一次 commit，業(yè)務(wù)提交特別的頻繁。

2.4 阻塞分析

比較’log file sync’和’log file parallel write’的平均等待時(shí)間，此時(shí)IO存在嚴(yán)重的阻塞。

大量的SQL出現(xiàn)嚴(yán)重的library cache lock、latch: shared pool。

3.總結(jié)分析

上面的一切初始建議值，都是在上線前的最佳配置建議值，在上線執(zhí)行一段時(shí)間后，系統(tǒng)執(zhí)行特性真面目就慢慢的體現(xiàn)出來(lái)了，這時(shí)，就應(yīng)該依據(jù)執(zhí)行實(shí)際需求及時(shí)的調(diào)整SGA_TARGET與PGA_AGGREGATE_TARGET的值了，但是業(yè)務(wù)也要做好評(píng)估，必須期間提升硬件性能，同時(shí)一些低效率低的SQL也要做好優(yōu)化！