一條sql語句導致的資料庫當機問題及分析
之前分享過一篇博文,是一條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)
檢視metalink,確實有這樣的一個bug.
Bug 10173135 - Resize SGA_TARGET crashes instance with ORA-600 [kmgsb_resize_sga_target_1] (Doc ID 10173135.8)
而且影響的版本如下:
真是撞到槍口上了,檢視了下,在11.2.0.3.0中才修復了這個問題。
然後自我總結了下,發現sga的自動管理操作還是需要謹慎,新特性的使用也是如此,一定要有足夠的把握才能使用。
資料庫是基於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
ORA-1092 : opitsk aborting process
Wed Apr 09 20:40:14 2014
Wed Apr 09 20:40:14 2014
opiodr aborting process unknown ospid (27776) as a result of ORA-1092opiodr aborting process unknown ospid (10547) as a result of ORA-1092
Wed Apr 09 20:40:14 2014
opiodr aborting process unknown ospid (7458) as a result of ORA-1092
Wed Apr 09 20:40:14 2014
Wed Apr 09 20:40:14 2014
ORA-1092 : opitsk aborting process
ORA-1092 : opitsk aborting process
Wed Apr 09 20:40:14 2014
ORA-1092 : opitsk aborting process
Wed Apr 09 20:40:14 2014
opiodr aborting process unknown ospid (30719) as a result of ORA-1092
Wed Apr 09 20:40:14 2014
ORA-1092 : opitsk aborting process
.......
ORA-1092 : opitsk aborting process
Wed Apr 09 20:40:14 2014
System state dump requested by (instance=1, osid=27182 (MMAN)), summary=[abnormal instance termination].
System State dumped to trace file /opt/app/oracle/dbtestpr1/diag/rdbms/TEST01/TEST01/trace/TEST01_diag_27176.trc
Instance terminated by MMAN, pid = 27182
檢視metalink,確實有這樣的一個bug.
Bug 10173135 - Resize SGA_TARGET crashes instance with ORA-600 [kmgsb_resize_sga_target_1] (Doc ID 10173135.8)
而且影響的版本如下:
Product (Component) | Oracle Server (Rdbms) |
Range of versions believed to be affected | Versions BELOW 12.1 |
Versions confirmed as being affected | |
Platforms affected | Generic (all / most platforms affected) |
真是撞到槍口上了,檢視了下,在11.2.0.3.0中才修復了這個問題。
然後自我總結了下,發現sga的自動管理操作還是需要謹慎,新特性的使用也是如此,一定要有足夠的把握才能使用。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/25462274/viewspace-1958816/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一條sql語句“導致”的資料庫當機問題及分析SQL資料庫
- 一條insert語句導致的效能問題分析(一)
- 由一條sql語句導致的系統IO問題SQL
- 一條insert語句導致的效能問題分析(二)
- 一條簡單的sql語句導致的系統問題SQL
- 一條執行4秒的sql語句導致的系統問題SQL
- 資料庫突然當機的問題及分析資料庫
- 一次資料庫當機問題的分析資料庫
- 如何透過一條資料庫語句做資料分析資料庫
- 一條簡單SQL語句的構成及語句解析SQL
- 核心引數導致的備庫當機分析
- 使用impdp不當導致的資料丟失問題
- 【資料庫】SQL語句資料庫SQL
- 一條全表掃描sql語句的分析SQL
- 一條sql語句的建議調優分析SQL
- 容災切換中的資料庫當機問題簡單分析(一)資料庫
- 執行SQL語句導致mysqld的crashMySql
- 不當編寫SQL語句導致系統不安全(轉)SQL
- 不當編寫SQL語句導致系統不安全 (轉)SQL
- 資料庫常用的sql語句大全--sql資料庫SQL
- 有問題的mybatis的sql導致對資料庫進行了批量的修改MyBatisSQL資料庫
- Oracle資料庫導致效能問題的可能原因Oracle資料庫
- memlock過低導致的資料庫效能問題資料庫
- 資料庫常用sql 語句資料庫SQL
- 資料庫SQL拼接語句資料庫SQL
- mysql導資料庫用到的語句MySql資料庫
- 如何快速定位當前資料庫消耗 CPU 最高的 sql 語句?資料庫SQL
- 資料庫突然當機無法open的問題及解決資料庫
- 如此大的一條sql語句在30個左右的併發訪問系統當中的效能問題?SQL
- 1.4 資料庫和常用SQL語句(正文)——MySQL資料庫命令和SQL語句資料庫MySql
- memory_target設定不當導致資料庫無法啟動的問題資料庫
- 一條SQL語句的書寫SQL
- 一條很 巧妙的 SQL 語句SQL
- 一條sql語句的優化SQL優化
- 一條SQL語句的旅行之路SQL
- 當機導致slave異常分析
- merge語句導致的效能問題緊急優化優化
- 【MySQL】經典資料庫SQL語句編寫練習題——SQL語句掃盲MySql資料庫