問(wèn)題：

????????用戶的數(shù)據(jù)庫(kù)在某個(gè)時(shí)間段出現(xiàn)連接數(shù)異常上漲問(wèn)題，時(shí)間持續(xù)5分鐘左右，并且問(wèn)題期間應(yīng)用無(wú)法正常連接請(qǐng)求數(shù)據(jù)庫(kù)

????????從連接數(shù)的監(jiān)控上可以看到數(shù)據(jù)庫(kù)平常峰值不到100個(gè)連接，在問(wèn)題時(shí)間段突然上漲到400以上

問(wèn)題分析：

????????首先查詢數(shù)據(jù)庫(kù)當(dāng)前節(jié)點(diǎn)的歷史使用最大連接數(shù)以及process參數(shù)的配置，推算問(wèn)題時(shí)間段數(shù)據(jù)庫(kù)的連接數(shù)是否已經(jīng)達(dá)到上限，從而導(dǎo)致應(yīng)用無(wú)法正常連接請(qǐng)求數(shù)據(jù)庫(kù)

---手動(dòng)創(chuàng)建快照，確保負(fù)載數(shù)據(jù)寫入歷史ash
exec dbms_workload_repository.create_snapshot();
---查詢process參數(shù)歷史最大值
select b.instance_number,b.begin_interval_time,b.end_interval_time,a.RESOURCE_NAME,a.CURRENT_UTILIZATION,a.MAX_UTILIZATION,a.LIMIT_VALUE 
    from DBA_HIST_RESOURCE_LIMIT a,dba_hist_snapshot b 
    where a.snap_id=b.snap_id and a.dbid=b.dbid and a.resource_name in('processes','sessions') and a.instance_number=b.instance_number
    and b.begin_interval_time>to_date('2023/11/27 12:00:00','yyyy/mm/dd hh24:mi:ss') and b.begin_interval_time<to_date('2023/11/27 15:30:00','yyyy/mm/dd hh24:mi:ss')
  order by b.instance_number,b.begin_interval_time
     ;

????????可以看到數(shù)據(jù)庫(kù)的歷史最大連接數(shù)為669，數(shù)據(jù)庫(kù)參數(shù)process配置為1500，alert日志頁(yè)沒(méi)看到ORA-00020:maximum number of processes (xxx) exceeded的報(bào)錯(cuò)，也就是說(shuō)問(wèn)題時(shí)間段數(shù)據(jù)庫(kù)的連接數(shù)并沒(méi)有達(dá)到上限，詢問(wèn)用戶應(yīng)用的連接池配置，得到回復(fù)是連接池最大連接為500，低于數(shù)據(jù)庫(kù)的歷史最大連接數(shù)為669，因此，連接數(shù)異常上漲期間應(yīng)用無(wú)法正常請(qǐng)求連接數(shù)據(jù)庫(kù)的原因應(yīng)該為數(shù)據(jù)庫(kù)出現(xiàn)連接堆積，導(dǎo)致應(yīng)用連接池連接耗盡無(wú)法正常請(qǐng)求連接數(shù)據(jù)庫(kù)

????????接下來(lái)，分析數(shù)據(jù)庫(kù)連接出現(xiàn)堆積上漲的原因，查看問(wèn)題時(shí)間段ASH里面的等等事件情況，通過(guò)等待事件評(píng)估可能的原因以及下一步的分析方向

---查看某個(gè)時(shí)間段的等待事件數(shù)量
select event,count(*)
from v$active_session_history a
where sample_time between timestamp '2023-11-27 14:20:00' and timestamp '2023-11-27 14:25:00'
group by event;
;
---查看某個(gè)等待事件的每分鐘數(shù)量
select to_char(sample_time,'yyyy-mm-dd hh24:mi'),event,count(*)
from v$active_session_history a
where sample_time between timestamp '2023-11-27 14:20:00' and timestamp '2023-11-27 14:25:00' and event='library cache pin'
group by to_char(sample_time,'yyyy-mm-dd hh24:mi'),event
order by 1;
?

????????可以看到問(wèn)題時(shí)間段，數(shù)據(jù)庫(kù)等待事件library cache pin在5分鐘內(nèi)出現(xiàn)了54885次等待，短時(shí)間內(nèi)出現(xiàn)這么高的等待肯定是有問(wèn)題的，并且從等待事件的類型以及經(jīng)驗(yàn)來(lái)看，極有可能是由于存儲(chǔ)過(guò)程，函數(shù)這類PL/SQL對(duì)象被某個(gè)會(huì)話獨(dú)占持有所導(dǎo)致

????????注：library cache pin等待一般是指會(huì)話在shared pool共享池里面申請(qǐng)對(duì)library cache庫(kù)緩存對(duì)象(比如函數(shù)，存儲(chǔ)過(guò)程，包)進(jìn)行訪問(wèn)調(diào)用時(shí)(pin)，由于該對(duì)象正在被獨(dú)占訪問(wèn)或是有會(huì)話正在申請(qǐng)獨(dú)占訪問(wèn)，這時(shí)會(huì)話需要等待獨(dú)占會(huì)話的釋放，期間出現(xiàn)的等待事件就是library cache pin等待

????????查看是否有直接的堵塞會(huì)話指向sid,可以看到大部份的會(huì)話的堵塞會(huì)話blocking_session都是空的，沒(méi)有看到直接的堵塞源，只有出現(xiàn)少量的堵塞會(huì)話sid:2133,1516

?select blocking_session,blocking_session_serial#,count(*)
from v$active_session_history a
where sample_time between timestamp '2023-11-27 14:20:00' and timestamp '2023-11-27 14:25:00' and event='library cache pin'
group by blocking_session,blocking_session_serial#
order by 3

????????查看被堵塞的會(huì)話執(zhí)行的語(yǔ)句，分析TOP 3的語(yǔ)句調(diào)用情況

select sql_id,count(*)
from v$active_session_history a
where sample_time between timestamp '2023-11-27 14:20:00' and timestamp '2023-11-27 14:25:00' and event='library cache pin'
group by sql_id
order by 2;

????????可以看到TOP前3個(gè)語(yǔ)句都同時(shí)調(diào)用了包app_interface_pkg，這說(shuō)明library cache pin的爭(zhēng)用發(fā)生在包app_interface_pkg

????????接下來(lái)，繼續(xù)分析包是否發(fā)生了修改、編譯或者重建這種需要獲取獨(dú)占模式的操作以及執(zhí)行的會(huì)話

????????查看包app_interface_pkg最近一次的ddl時(shí)間以及創(chuàng)建時(shí)間，并沒(méi)有發(fā)現(xiàn)在問(wèn)題時(shí)間段以及近期有發(fā)生過(guò)修改、編譯或者重建的操作，OS：難道分析錯(cuò)方向？先不管，繼續(xù)往下

alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
select object_id,object_name,created,last_ddl_time
from dba_objects
where object_name='APP_INTERFACE_PKG';

????????查看問(wèn)題時(shí)間段所有會(huì)話的操作類型，有一個(gè)重大的發(fā)現(xiàn)里面出現(xiàn)了CREATE PACKAGE創(chuàng)建包的獨(dú)占模式操作

alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
col machine for a20
select SQL_OPNAME,count(*)
from v$active_session_history a
where sample_time between timestamp '2023-11-27 13:20:00' and timestamp '2023-11-27 14:22:00'
group by SQL_OPNAME;

????????查看這個(gè)執(zhí)行CREATE PACKAGE的會(huì)話，可以看到這個(gè)會(huì)話一執(zhí)行，就開(kāi)始出現(xiàn)大面積的library cache pin等待，這個(gè)會(huì)話一消失，library cache pin等待也跟著消失，并且執(zhí)行的操作應(yīng)該是沒(méi)有成功的，因?yàn)楫?dāng)時(shí)正在業(yè)務(wù)高峰期，包一直被其他會(huì)話所調(diào)用，這導(dǎo)致從開(kāi)始到結(jié)束會(huì)話一直是在等待library cache pin去獲取獨(dú)占模式，而等待的會(huì)話分別是我們之前查到的sid:2133,1516，這也剛好解釋了為什么之前看到包最近一次的ddl時(shí)間以及創(chuàng)建時(shí)間都沒(méi)有發(fā)生過(guò)修改

alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
col machine for a20
select sample_time,a.SESSION_ID, sql_id,blocking_session,blocking_session_serial#,event,SQL_OPNAME
from v$active_session_history a
where sample_time between timestamp '2023-11-27 14:27:04' and timestamp '2023-11-27 14:27:06'
order by sample_time;

????????到這里，問(wèn)題已經(jīng)變得清晰，在問(wèn)題時(shí)間段有會(huì)話執(zhí)行了對(duì)包app_interface_pkg的CREATE PACKAGE操作，對(duì)該包的library cache申請(qǐng)了獨(dú)占模式，導(dǎo)致后續(xù)調(diào)用該包的會(huì)話都出現(xiàn)了library cache pin等待，最終引發(fā)了數(shù)據(jù)庫(kù)會(huì)話連接堆積，應(yīng)用連接池連接耗盡無(wú)法正常請(qǐng)求連接數(shù)據(jù)庫(kù)

問(wèn)題解決：

????????雖然通過(guò)sql_id沒(méi)有查到具體的執(zhí)行語(yǔ)句文本，但從會(huì)話的執(zhí)行程序pl/sql developer可以基本確認(rèn)是人為執(zhí)行的語(yǔ)句，將會(huì)話查到的機(jī)器名交給用戶進(jìn)行進(jìn)一步的查找，后續(xù)得到確認(rèn)在問(wèn)題時(shí)間段應(yīng)用運(yùn)維人員確實(shí)是對(duì)包app_interface_pkg執(zhí)行了編譯的操作所導(dǎo)致

????????所以，切記！生產(chǎn)無(wú)小事，三思而后行。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-754860.html

到了這里，關(guān)于Oracle-數(shù)據(jù)庫(kù)連接數(shù)異常上漲問(wèn)題分析的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！