編者按： 筆者單位所使用的Oracle 數(shù)據(jù)庫近期出現(xiàn)連接卡頓的問題，會(huì)不定時(shí)出現(xiàn)宕機(jī)。筆者對(duì)此進(jìn)行排查后發(fā)現(xiàn)是前端應(yīng)用服務(wù)器修改了部分軟件功能所致。

筆者單位生產(chǎn)系統(tǒng)使用的Oracle 11G RAC數(shù)據(jù)庫自上線運(yùn)行有近3年，一直穩(wěn)定良好，近期在日常監(jiān)控和用戶反映均發(fā)現(xiàn)對(duì)該RAC 數(shù)據(jù)庫的連接某些時(shí)候會(huì)出現(xiàn)卡頓。

先介紹一下筆者單位的系統(tǒng)，如圖1 所示。軟件環(huán)境如下：

單位所使用的操作系統(tǒng)為AIX 7.1，數(shù)據(jù)庫系統(tǒng)為Oracle 11.2.0.4 RAC。數(shù)據(jù)庫集群Grid的補(bǔ)丁已安裝列表：

22 502505;ACFS Patch Set Update:11.2.0.4.160419 (22502505)

23 054319;OCW Patch Set Update:11.2.0.4.160719 (23054319)

24 732075;Database Patch Set Update:11.2.0.4.170418 (24732075)

Oracle 數(shù)據(jù)庫補(bǔ)丁已安裝列表：

圖1 單位系統(tǒng)簡(jiǎn)圖

23 054319;OCW Patch Set Update:11.2.0.4.160719 (23054319)

24 732075;Database Patch Set Update:11.2.0.4.170418 (24732075)

故障分析及排查

當(dāng)出現(xiàn)該問題后，數(shù)據(jù)庫管理員登錄數(shù)據(jù)庫看到該RAC 數(shù)據(jù)庫2 號(hào)實(shí)例（Instance 2）已經(jīng)處于關(guān)閉狀態(tài)。該問題具有隨機(jī)性，不定時(shí)出現(xiàn)宕機(jī)情況，嚴(yán)重影響系統(tǒng)的正常運(yùn)行。通過追蹤查看數(shù)據(jù)庫系統(tǒng)產(chǎn)生的警告日志文件Alert.log，筆者發(fā)現(xiàn)數(shù)據(jù)庫在實(shí)例停止報(bào)錯(cuò)中出現(xiàn)了ORA-7445和ORA-600 錯(cuò)誤。

ORA-07445 出現(xiàn)異常錯(cuò)誤：

核心轉(zhuǎn)儲(chǔ)

[opiaba()+772][SIGSEGV] [ADDR:0xF0001078D9B0F1A][PC:0x1093DBDE4][Address not mapped to object] []

Incident details in:/haclu/ app/oracle/diag/rdbms/orcl/incident/incdir_820678/orcl_ora_50921614_i820678.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Mon Mar 09 10:16:11 2020

Sweep [inc][820678]:completed

Sweep [inc2][820678]:completed

Mon Mar 09 10:16:11 2020

Dumping diagnostic data in directory=[c dmp_20200309101611],requested by (instance=2,osid=50921614),summary=[incident=820678].

Mon Mar 09 10:16:18 2020

Errors in file/haclu/app/oracle/diag/rdbms/orcl/trace/orcl_pmon_37225990.trc(incident=819342):

ORA-00600 出現(xiàn)異常錯(cuò)誤：

ORA-00600:internal error code,arguments:[17147],[0x7000107586604 D8],[],[],[],[],[],[],[],[],[],[]

Incident details in:/haclu/app/oracle/diag/rdbms/orcl/incident/incdir_819342/o rcl_pmon_37225990_i819342.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Errors in file/haclu/app/oracle/diag/rdbms/orcl/trace/orcl_pmon_37225990.trc:

ORA-00600:internal error code,arguments:[17147],[0x7000107586604 D8],[],[],[],[], [],[],[],[],[],[]

PMON (ospid :37225990):terminating the instance due to error 472

Mon Mar 09 10:16:21 2020

System state dump requested by (instance=2,osid=37225990 (PMON)),summary=[abnormal instance termination].

System State dumped to trace file/haclu/app/oracle/diag/rdbms/orcl/trace/jwya2_diag_42075868_20200309101621.trc

Instance terminated by PMON,pid=37225990

因?yàn)閱栴}發(fā)生具有隨機(jī)性，加之該故障原因是ORA-7445 和ORA-600 錯(cuò)誤，這兩種類型錯(cuò)誤多為數(shù)據(jù)庫自身產(chǎn)品BUG 等缺陷造成的系統(tǒng)級(jí)隱患。我們暫時(shí)只能通過重啟實(shí)例來讓系統(tǒng)進(jìn)行恢復(fù)，不至于影響生產(chǎn)現(xiàn)場(chǎng)使用，同時(shí)，繼續(xù)對(duì)故障進(jìn)行跟蹤。

隨著數(shù)據(jù)庫實(shí)例宕機(jī)次數(shù)的累計(jì)增加，通過報(bào)錯(cuò)日志以及數(shù)據(jù)庫產(chǎn)生的跟蹤文件，我們進(jìn)一步查看/haclu/app/oracle/diag/rdbms/orcl/incident/incdir_820678/orcl_ora_50921614_i820678.trc文件內(nèi)容，發(fā)現(xiàn)存在大量的刪除語句，如圖2 所示。

經(jīng)過和Oracle 官方技術(shù)工程師通信協(xié)商后發(fā)現(xiàn)該SQL 語句中的綁定變量超過了80 000 個(gè)，系統(tǒng)資源耗盡，造成數(shù)據(jù)庫實(shí)例2（Instance 2）關(guān)閉,并且該系統(tǒng)BUG 在Oracle 11.2.0.4 版本下已經(jīng)無官方補(bǔ)丁支持。

故障解決

經(jīng)過一段時(shí)間的觀察和分析，我們逐步搞清楚了引發(fā)數(shù)據(jù)庫實(shí)例2（Instance 2）隨機(jī)性宕機(jī)的真正原因。

圖2 文件內(nèi)容存在大量的刪除語句

由于應(yīng)用系統(tǒng)前端應(yīng)用服務(wù)器近期修改了部分軟件功能，該功能會(huì)對(duì)用戶數(shù)據(jù)庫中的某表進(jìn)行大量的插入或刪除操作。我們特地找到了軟件功能開發(fā)人員進(jìn)行了溝通，發(fā)現(xiàn)如下一次性批量逐條數(shù)據(jù)插入代碼：“qjsqDao.insertAttendancePerson(list_dyxx);”。當(dāng)用戶使用該功能后，系統(tǒng)會(huì)產(chǎn)生插入或刪除操作。期間應(yīng)用開發(fā)人員使用了數(shù)據(jù)庫的綁定變量機(jī)制，該表需要插入的記錄數(shù)實(shí)際為9 萬多條，而數(shù)據(jù)庫綁定變量要求最大不能超過65 535，當(dāng)數(shù)據(jù)一次性批量逐條插入或刪除時(shí)，生成的綁定變量數(shù)大于65 535上限。又因?yàn)樵搼?yīng)用服務(wù)器連接數(shù)據(jù)庫監(jiān)聽使用的是實(shí)例2（Instance 2）本地監(jiān)聽，而非RAC的SCAN 監(jiān)聽，導(dǎo)致數(shù)據(jù)庫實(shí)例2（Instance 2）的數(shù)據(jù)監(jiān)控和管理進(jìn)程（PMON）錯(cuò)誤，因此引起數(shù)據(jù)庫實(shí)例2（Instance 2）關(guān)閉。

針對(duì)這一問題，我們經(jīng)過和開發(fā)人員協(xié)商和測(cè)試，將對(duì)該表的一次性逐條增刪操作改為批量提交處理方式，避免出現(xiàn)綁定變量數(shù)越界問題。核心代碼如下：

經(jīng)修改上線后，數(shù)據(jù)實(shí)例宕機(jī)問題徹底解決。

結(jié)語

此次生產(chǎn)數(shù)據(jù)庫宕機(jī)故障看起來似乎是數(shù)據(jù)庫問題，但其本質(zhì)問題是因?yàn)閼?yīng)用程序使用綁定變量越界而導(dǎo)致的資源耗盡。在問題的排查過程中，追蹤和信息收集對(duì)問題的處理和排查起到了非常重要的作用，信息系統(tǒng)的問題診斷也需要豐富的經(jīng)驗(yàn)積累。有時(shí)候“腳疼”的問題真不一定出現(xiàn)在腳上，需要系統(tǒng)性對(duì)現(xiàn)象進(jìn)行梳理和分析，才能更好的使問題本質(zhì)浮出水面。