一次數據庫實例隨機性宕機

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

筆者單位生產系統使用的Oracle 11G RAC數據庫自上線運行有近3年，一直穩定良好，近期在日常監控和用戶反映均發現對該RAC 數據庫的連接某些時候會出現卡頓。

先介紹一下筆者單位的系統，如圖1 所示。軟件環境如下：

單位所使用的操作系統為AIX 7.1，數據庫系統為Oracle 11.2.0.4 RAC。數據庫集群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 數據庫補丁已安裝列表：

圖1 單位系統簡圖

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

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

故障分析及排查

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

ORA-07445 出現異常錯誤：

核心轉儲

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

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

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

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

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

故障解決

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

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

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

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

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

結語

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