資訊專欄INFORMATION COLUMN
數據庫版本：11.2.0.4
操作系統內核版本：CentOS Linux release 7.4.1708 (Core)
數據庫架構：11G R2 RAC環境
巡檢發現數據庫最近發生了重啟，通過GV$DATABASE視圖查到具體的時間點，初步定為認為是數據庫負載過大導致的，嘗試打印相應的awr報告和通過對應時間點的alter日志查看是否有報錯。
找到最近一次重啟的時間點，按照時間點打印對應的awr或是ash報告分析數據庫負載。
▼▼▼set feedback off
set linesize 256
set pagesize 50000
set long 999999999
alter session set nls_date_format=yyyy-mm-dd hh24:mi:ss;
alter session set NLS_TIMESTAMP_FORMAT=YYYY-MM-DD HH24:MI:SS.FF;
alter session set NLS_TIMESTAMP_TZ_FORMAT=YYYY-MM-DD HH24:MI:SS.FF TZH:TZM;
select d.inst_id,d.name,i.instance_name,i.startup_time,i.status,d.open_mode from gv$database d,gv$instance i where d.inst_id=i.inst_id;
通過打印AWR報告發現12號當天固定時間點出現斷點，從awr報告的斷點中可以知道12號0點，2點，4點，6點直到當天的14點，固定整點發生節點一重啟問題。
less log.xml
查詢/ORA-07445報錯，核實對應時間點都有ORA-07445報錯，初步猜測數據庫一節點自動重啟和這個報錯相關，時間點剛好吻合。
發現trace日志中有一個存儲過程，采用拼接的方式綁定大量變量，綁定變量的個數查過數據庫上線65535。
按照截圖收縮可以找到對應的mos文章737378.1。核實數據庫觸發了 Bug 12578873
，此bug完全符合此場景。
經核實目前11.2.4版本，此bug提供的修復平臺只有exadata和windows平臺，因此只能采取Workaround給出的建議，協調開發修改存儲過程邏輯，減少變量的綁定，避免觸發此bug，最終開發修改了相關邏輯，數據庫因此導致的宕機問題消除。
Workaround
更多精彩干貨分享
點擊下方名片關注
IT那活兒
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129861.html
摘要：新晉技術專家下面是墨天輪部分新晉的技術專家。大家可以點擊往期閱讀墨天輪技術專家邀請函了解詳情，申請成為我們的技術專家，加入專家團隊，與我們一起創建一個開放互助的數據庫技術社區。新關聯公眾號墨天輪是一個開放互助的數據庫技術社區。 引言 近期我們在DBASK小程序增加了數據庫 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的專題欄目和一些新的技術...
RAC補丁日常更新成功反遇異常處理 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; m...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
