一次數(shù)據(jù)庫實例隨機性宕機

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

筆者單位生產系統(tǒng)使用的Oracle 11G RAC數(shù)據(jù)庫自上線運行有近3年，一直穩(wěn)定良好，近期在日常監(jiān)控和用戶反映均發(fā)現(xiàn)對該RAC 數(shù)據(jù)庫的連接某些時候會出現(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的補丁已安裝列表：

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ù)庫補丁已安裝列表：

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

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

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

故障分析及排查

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

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

核心轉儲

[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)異常錯誤：

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

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

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

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

故障解決

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

圖2 文件內容存在大量的刪除語句

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

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

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

結語

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