編者按: 筆者單位所使用的Oracle 數(shù)據(jù)庫近期出現(xiàn)連接卡頓的問題,會不定時出現(xiàn)宕機。筆者對此進行排查后發(fā)現(xiàn)是前端應用服務器修改了部分軟件功能所致。
筆者單位生產(chǎ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)已經(jīng)處于關閉狀態(tài)。該問題具有隨機性,不定時出現(xiàn)宕機情況,嚴重影響系統(tǒng)的正常運行。通過追蹤查看數(shù)據(jù)庫系統(tǒng)產(chǎn)生的警告日志文件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ù)庫自身產(chǎn)品BUG 等缺陷造成的系統(tǒng)級隱患。我們暫時只能通過重啟實例來讓系統(tǒng)進行恢復,不至于影響生產(chǎn)現(xiàn)場使用,同時,繼續(xù)對故障進行跟蹤。
隨著數(shù)據(jù)庫實例宕機次數(shù)的累計增加,通過報錯日志以及數(shù)據(jù)庫產(chǎn)生的跟蹤文件,我們進一步查看/haclu/app/oracle/diag/rdbms/orcl/incident/incdir_820678/orcl_ora_50921614_i820678.trc文件內(nèi)容,發(fā)現(xiàn)存在大量的刪除語句,如圖2 所示。
經(jīng)過和Oracle 官方技術工程師通信協(xié)商后發(fā)現(xiàn)該SQL 語句中的綁定變量超過了80 000 個,系統(tǒng)資源耗盡,造成數(shù)據(jù)庫實例2(Instance 2)關閉,并且該系統(tǒng)BUG 在Oracle 11.2.0.4 版本下已經(jīng)無官方補丁支持。
經(jīng)過一段時間的觀察和分析,我們逐步搞清楚了引發(fā)數(shù)據(jù)庫實例2(Instance 2)隨機性宕機的真正原因。
圖2 文件內(nèi)容存在大量的刪除語句
由于應用系統(tǒng)前端應用服務器近期修改了部分軟件功能,該功能會對用戶數(shù)據(jù)庫中的某表進行大量的插入或刪除操作。我們特地找到了軟件功能開發(fā)人員進行了溝通,發(fā)現(xiàn)如下一次性批量逐條數(shù)據(jù)插入代碼:“qjsqDao.insertAttendancePerson(list_dyxx);”。當用戶使用該功能后,系統(tǒng)會產(chǎn)生插入或刪除操作。期間應用開發(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)關閉。
針對這一問題,我們經(jīng)過和開發(fā)人員協(xié)商和測試,將對該表的一次性逐條增刪操作改為批量提交處理方式,避免出現(xiàn)綁定變量數(shù)越界問題。核心代碼如下:
經(jīng)修改上線后,數(shù)據(jù)實例宕機問題徹底解決。
此次生產(chǎn)數(shù)據(jù)庫宕機故障看起來似乎是數(shù)據(jù)庫問題,但其本質(zhì)問題是因為應用程序使用綁定變量越界而導致的資源耗盡。在問題的排查過程中,追蹤和信息收集對問題的處理和排查起到了非常重要的作用,信息系統(tǒng)的問題診斷也需要豐富的經(jīng)驗積累。有時候“腳疼”的問題真不一定出現(xiàn)在腳上,需要系統(tǒng)性對現(xiàn)象進行梳理和分析,才能更好的使問題本質(zhì)浮出水面。