数据库异常宕机分析报告

IT那活儿发布于2023-01-11 13:20 / 3525人阅读

数据库异常宕机分析报告

问题描述

数据库自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异常信息分析数据库宕机

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/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