一條sql語句導致的資料庫宕機問題及分析（42天)

阿新 • • 發佈：2022-05-04

之前分享過一篇博文，是一條sql語句"導致"的資料庫宕機，上次是另有原因，這次真碰到一個案例，而且是在重要的環境上，希望大家引以為戒。資料庫是基於Linux64的版本，版本是11.2.0.2.0,已經打了最新的psu. 資料庫的訪問使用者數大約在1000左右，當時檢視伺服器的cpu已經是100%了，有大約10個程序都是cpu 100%,資料庫邏輯讀也是超高，一秒鐘大約是接近百兆的情況，sga是12G,已用了sga的自動管理(sga_target=0), 檢視記憶體元件時發現buffer_cache已經有shrink的跡象，而且buffer_cache的min_size還是有一點小，就在可用範圍內給buffer cache 增大了幾百兆的樣子，生成了一個ADDM, 報告裡第一條就是希望設定sga_target為一個特定的值，效能可能會有一定的提升，當時想,sga_max_size都已經是12G了，設定sga_target=12G也沒有問題吧就按照它的提示做了， alter system set sga_target=12G;

結果命令提頓了幾秒鐘，然後就崩出來一個end_of_communicaiton的ora錯誤，我感覺出問題了，已檢視程序，資料庫是真down掉了。檢視alert日誌，發現時由於resize_sga的ora-600問題導致的，所有的線上程序都被自動給kill掉了。然後馬上和相應的team來協調，把資料庫先startup了。再檢視具體的資訊。 alert日誌如下： Thread 1 advanced to log sequence 14054 (LGWR switch)

Current log# 2 seq# 14054 mem# 0: /dbtestPR1/oracle/TEST01/redolog_A2/redo/redo02A.log

Current log# 2 seq# 14054 mem# 1: /dbtestPR1/oracle/TEST01/redolog_B2/redo/redo02B.log

Wed Apr 09 20:07:10 2014

Archived Log entry 14090 added for thread 1 sequence 14053 ID 0xb8c6d509 dest 1:

Wed Apr 09 20:40:13 2014

Errors in file /opt/app/oracle/dbtestpr1/diag/rdbms/TEST01/TEST01/trace/TEST01_mman_27182.trc (incident=360075):

ORA-00600: internal error code, arguments: [kmgsb_resize_sga_target_1], [0], [768], [4], [], [], [], [], [], [], [], []

Incident details in: /opt/app/oracle/dbtestpr1/diag/rdbms/TEST01/TEST01/incident/incdir_360075/TEST01_mman_27182_i360075.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 /opt/app/oracle/dbtestpr1/diag/rdbms/TEST01/TEST01/trace/TEST01_mman_27182.trc:

ORA-00600: internal error code, arguments: [kmgsb_resize_sga_target_1], [0], [768], [4], [], [], [], [], [], [], [], []

MMAN (ospid: 27182): terminating the instance due to error 822

Wed Apr 09 20:40:14 2014

opiodr aborting process unknown ospid (25518) as a result of ORA-1092

Wed Apr 09 20:40:14 2014