數據庫異常宕機分析報告

IT那活兒發布于2023-01-11 13:20 / 3601人閱讀

數據庫異常宕機分析報告

問題描述

數據庫自6月29日起連續多天異常宕機。alert日志報Instance Critical Process (pid: 21, ospid: 105559, DBW2) died unexpectedly之類的錯誤。

系統message日志里有Jun 29 06:14:25 HOSTNAME kernel: Out of memory: Kill process 105559 (ora_dbw2_XXXX) score 186 or sacrifice child之類報錯。

問題分析

1. 數據庫alert日志報錯：

--6月29日

2021-06-29T06:14:27.599722+08:00

Instance Critical Process (pid: 21, ospid: 105559, DBW2) died unexpectedly

PMON (ospid: 105510): terminating the instance due to error 471

2021-06-29T06:14:27.929867+08:00

System state dump requested by (instance=1, osid=105510 (PMON)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/********_diag_105538_20210629061427.trc

--6月30日

2021-06-30T07:00:57.368545+08:00

Instance Critical Process (pid: 19, ospid: 66571, DBW0) died unexpectedly

PMON (ospid: 66527): terminating the instance due to error 471

2021-06-30T07:00:57.544376+08:00

System state dump requested by (instance=1, osid=66527 (PMON)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/********_diag_66555_20210630070057.trc

--7月1日

2021-07-01T09:07:04.699459+08:00

Instance Critical Process (pid: 20, ospid: 125148, DBW1) died unexpectedly

PMON (ospid: 125085): terminating the instance due to error 471

2021-07-01T09:07:05.005935+08:00

System state dump requested by (instance=1, osid=125085 (PMON)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/********_diag_125126_20210701090705.trc

--7月2日

2021-07-02T07:36:36.660203+08:00

Instance Critical Process (pid: 19, ospid: 25474, DBW0) died unexpectedly

PMON (ospid: 25437): terminating the instance due to error 471

2021-07-02T07:36:37.001449+08:00

System state dump requested by (instance=1, osid=25437 (PMON)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/********_diag_25457_20210702073637.trc

--7月3日

2021-07-03T07:52:35.531254+08:00

Instance Critical Process (pid: 7, ospid: 91834, MMAN) died unexpectedly

2021-07-03T07:52:55.666657+08:00

PMON (ospid: 91819): terminating the instance due to error 822

2021-07-03T07:52:55.679848+08:00

System state dump requested by (instance=1, osid=91819 (PMON)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/********_diag_91842_20210703075255.trc

2. 系統message日志報錯：

--6月29日

Jun 29 06:14:25 HOSTNAME kernel: Out of memory: Kill process 105559 (ora_dbw2_XXXX) score 186 or sacrifice child

Jun 29 06:14:25 HOSTNAME kernel: Killed process 105559 (ora_dbw2_XXXX) total-vm:13041272kB, anon-rss:17376kB, file-rss:80kB, shmem-rss:9180780kB

--6月30日

Jun 30 07:00:57 HOSTNAME kernel: Out of memory: Kill process 66571 (ora_dbw0_XXXX) score 130 or sacrifice child

Jun 30 07:00:57 HOSTNAME kernel: Killed process 66571 (ora_dbw0_XXXX) total-vm:13041260kB, anon-rss:18256kB, file-rss:0kB, shmem-rss:6426356kB

Jun 30 07:00:57 HOSTNAME kernel: ora_dbw0_XXXX: page allocation failure: order:0, mode:0x2015a

Jun 30 07:00:57 HOSTNAME kernel: CPU: 26 PID: 66571 Comm: ora_dbw0_XXXX Not tainted 3.10.0-693.el7.x86_64 #1

--7月1日

Jul 1 09:07:01 HOSTNAME kernel: Out of memory: Kill process 125152 (ora_dbw3_XXXX) score 140 or sacrifice child

Jul 1 09:07:01 HOSTNAME kernel: Killed process 125152 (ora_dbw3_XXXX) total-vm:13041280kB, anon-rss:17888kB, file-rss:568kB, shmem-rss:6901124kB

--7月2日

Jul 2 07:36:24 HOSTNAME kernel: Out of memory: Kill process 31865 (oracle_31865_ns) score 142 or sacrifice child

Jul 2 07:36:24 HOSTNAME kernel: Killed process 31865 (oracle_31865_ns) total-vm:13034256kB, anon-rss:8496kB, file-rss:512kB, shmem-rss:7017736kB

--7月3日

Jul 3 07:52:28 HOSTNAME kernel: Out of memory: Kill process 91834 (ora_mman_XXXX) score 32 or sacrifice child

Jul 3 07:52:28 HOSTNAME kernel: Killed process 91834 (ora_mman_XXXX) total-vm:13022640kB, anon-rss:2892kB, file-rss:80kB, shmem-rss:1615108kB

3. 系統內存使用情況：

結合數據庫alert和系統message日志可以看到，由于系統內存溢出，數據庫核心進程dbwn被killed導致數據庫宕機。系統內存使用情況可以看到16G的swap分區已被全部使用。

故障處理

1. 關閉asm實例及has（周末時間數據庫沒人用）

——經查看，asm實例相關進程占用了較多的swap分區

——關閉asm實例和has

srvctl stop asm

crsctl stop has

2. 清理swap交換分區

--清理內存cache，確保系統空閑內存大于swap已用內存

sync

echo "3" > /proc/sys/vm/drop_caches

--關閉swap分區

swapoff -a

--殺掉占用較多swap的進程（系統自動釋放速度會很慢）

[root@HOSTNAME ~]# for i in `cd /proc;ls |grep "^[0-9]"|awk $0 >100` ;do awk /Swap:/{a=a+$2}END{print "$i",a/1024"M"} /proc/$i/smaps ;done 2>&1 |sort -k2nr |head -20

66285 101.973M

124601 6.6875M

88435 6.53906M

75924 6.46875M

88033 6.42188M

15747 6.41406M

71480 6.38672M

112856 6.32422M

32315 6.24609M

30195 6.24219M

118924 6.23047M

112052 6.12891M

43413 6.10156M

123682 6.0625M

62669 6.05859M

89471 5.99219M

38687 5.96094M

23452 5.95703M

30953 5.95703M

13602 5.95312M

3. 調整swappiness參數，恢復swap分區

——調整swappiness參數

cat /etc/sysctl.conf

vm.swappiness=0

sysctl -p

swapon -a

——啟動has和asm實例

crsctl start has

srvctl start asm

4. 啟動數據庫，并調整SGA和PGA（客戶要求）

——啟動數據庫

——調整sga和pga

alter system set sga_max_size=8G scope=spfile;
alter system set sga_target=8G scope=spfile;
alter system set pga_aggregate_target=2G scope=spfile;

——重啟數據庫

總結

ASM實例相關進程占用了較多的swap分區，周末關閉asm實例及has后發現有大量的/u01/app/oracle/tfa/HOSTNAME/tfa_home/perl/bin/perl /u01/app/oracle/tfa/HOSTNAME/tfa_home/bin/tfactl.pl rediscover -mode full -auto和sh -c rpm -qa --queryformat "(%{INSTALLTIME:date}):%{NAME}|%{VERSION}|%{RELEASE}|%{ARCH} " > rpms.out 2>&1占用著swap分區，大批量kill進程后swap分區快速釋放（數據庫正常運行時只能kill非關鍵進程，關鍵進程需等系統自動釋放）。

END

更多精彩干貨分享

點擊下方名片關注

IT那活兒

GPU云服務器云服務器異常數據分析異常分析 java異常信息分析數據庫宕機

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/129816.html

云計算節點故障自動化運維服務設計

此文已由作者王盼授權網易云社區發布。歡迎訪問網易云社區，了解更多網易技術產品運營經驗~ 現狀計算節點發生磁盤損壞等數據無法恢復的異常時，節點上的云主機系統盤無法恢復，導致云主機只能被清理重建計算節點宕機但磁盤數據可用時，重啟即可恢復所有云主機的運行計算節點多次宕機（或一段時間內頻繁宕機），則需要遷移所有云主機或者直接清理重建，云硬盤需要遷移到其他cinder-volume存儲服務節點一般來...

seanHai 2019-06-28 10:59 評論0 收藏0
談談為什么需要服務治理（Dubbo）

摘要：服務治理主要針對于當前分布式架構下多服務微服務等。隨著業務的增長，服務不能一味地隨之增長，需要管理治理。服務設計期主要針對于服務的設計評審以及標準的制定。服務治理后期的重點放在消除冗余。服務治理主要針對于當前分布式架構下多服務、微服務等。服務是分布式系統下的一個不大不小的部分，有了服務的組成，整個系統才能活起來。隨著業務的增長，服務不能一味地隨之增長，需要管理、治理。沒有服務治理...

yunhao 2019-08-15 18:08 評論0 收藏0
關于分布式系統的思考（二）

摘要：收到所有參與者回應后，完成事務。不管是還是，都是通過節點間的交換消息去達到一致的狀態，這也是分布式系統的常用做法。從業期間，負責過訂閱系統制作云服務開源平臺分布式任務調度系統等產品的設計研發工作。接著上一篇的內容，詳細介紹一些主流數據庫在分布式場景下用到的算法和思想，主要提及數據一致性相關的一些策略，并分析其利弊和典型應用場景。對于數據庫來說，可能關心的最多的就是數據的一致性了，由...

cuieney 2019-06-28 10:53 評論0 收藏0
關于分布式系統的思考（二）

摘要：收到所有參與者回應后，完成事務。不管是還是，都是通過節點間的交換消息去達到一致的狀態，這也是分布式系統的常用做法。從業期間，負責過訂閱系統制作云服務開源平臺分布式任務調度系統等產品的設計研發工作。接著上一篇的內容，詳細介紹一些主流數據庫在分布式場景下用到的算法和思想，主要提及數據一致性相關的一些策略，并分析其利弊和典型應用場景。對于數據庫來說，可能關心的最多的就是數據的一致性了，由...

fxp 2019-06-24 17:53 評論0 收藏0
玩概念還是真好用？一文讀懂融合CDN

摘要：但是，客戶在選擇的時候，不要只看概念，一定要緊盯智能，看目標平臺是否在網絡監控大數據分析調度管理等方面下大力氣天浩提醒一個小小的秘訣，就是看其有沒有服務等巨頭，被多家巨頭選用，一般不是假融合。大型互聯網企業的一次宕機，會造成多大影響？國外有網友這么回答：（以為）世界末日來了！這是4月15日Facebook、Instagram等平臺的服務器大面積宕機故障之后，部分網民的吐槽，由此可見網絡服務穩...

Kyxy 2019-04-29 15:50 評論0 收藏0