概述

 

数据库对应的业务程序在2021/3/7日凌晨0:02分报无法连接数据库，在0:04分接到故障申告后，代维科技工程师通过远程方式接入数据库环境进行故障排查，在0:08分处理完成。通过对相关日志等信息的深入分析，找出问题点并提出相应的解决建议，根据相关问题日志及分析处理情况整理汇总此文档。

 

无法连接的原因分析

1. 宁帆数据库无法连接分析

 

登陆数据库进行查看，数据库无法连接原因为数据库主机磁盘空间使用率100%，归档日志无法切换，应用程序此时无法连接到数据库。紧急通过人工删除一部分数据库日志，并进行日志切换动作后，程序可以正常连接。

[root@nf-dboracle ~]# df -h

Filesystem                          Size  Used Avail Use% Mounted on

/dev/mapper/vg_nfdboracle-LogVol00  476G  452G   16M 100% /

tmpfs                               7.8G  160K  7.8G   1% /dev/shm

/dev/sda1                          1008M   63M  895M   7% /boot

/dev/sr0                            3.6G  3.6G     0 100% /mnt

[root@nf-dboracle ~]# su – oracle

[oracle@nf-dboracle ~]$ rman target /

 

Recovery Manager: Release 11.2.0.3.0 – Production on Sun Mar 7 00:07:32 2021

 

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

 

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-00554: initialization of internal recovery manager package failed

RMAN-04005: error from target database:

ORA-09945: Unable to initialize the audit trail file

Linux-x86_64 Error: 28: No space left on device

 

 

2. 磁盘空间不足原因的分析

通过对数据库归档日志产生数量的分析，可以发现，从3月4号以来，每天的数据库归档日志产生量是原来的15至20倍左右，当前每天产生120GB的归档日志，按原有的备份策略，归档日志保留2天，因此最终引起了磁盘空间不足。

 

 

 

3. 产生归档日志量多的操作分析

数据库层面看，70%的数据变更都在KLB_MICROHOSP用户的 NFSYS_LOG_THIRD表上，在TOP SQL中也发现了对这个表的频率插入；结合表名看，有可能是新开启了写入日志的功能，具体需要应用软件开发商确认一下。

INSERT INTO NFSYS_LOG_THIRD ( ID, TYPE, METHOD, MSG, DESCRIPTION, NAME, OPENID, THIRD_METHOD ) VALUES ( NFSYS_LOG_THIRD_S.nextval, :type0, :method0, :msg, :description, :name, :openid, :third_method ) RETURNING ID INTO :IDENTITY_PARAMETER

 

 

总结与后续处理建议

通过对数据库相关日志以及相关数据的分析，可以得出如下信息：

1. 数据库无法连接原因的分析：

登陆数据库进行查看，数据库无法连接原因为数据库主机磁盘空间使用率100%，归档日志无法切换，应用程序此时无法连接到数据库。紧急通过人工删除一部分数据库日志，并进行日志切换动作后，程序可以正常连接。(0点4分接到电话，0点8分处理完成，用时4分钟。)

2. 磁盘空间不足分析：

通过对数据库归档日志产生数量的分析，可以发现，从3月4号以来，每天的数据库归档日志产生量是原来的15至20倍左右，当前每天产生120GB的归档日志，按原有的备份策略，归档日志保留2天，因此最终引起了磁盘空间不足。已经临时修改了备份及删除归档日志的策略来解决此问题；

3. 产生日志多的应用程序语句：

从数据库层面看，70%的数据变更都在KLB_MICROHOSP用户的 NFSYS_LOG_THIRD表上，在TOP SQL中也发现了对这个表的频率插入；结合表名看，有可能是新开启了写入日志的功能，具体需要应用软件开发商确认一下。

：

INSERT INTO NFSYS_LOG_THIRD ( ID, TYPE, METHOD, MSG, DESCRIPTION, NAME, OPENID, THIRD_METHOD ) VALUES ( NFSYS_LOG_THIRD_S.nextval, :type0, :method0, :msg, :description, :name, :openid, :third_method ) RETURNING ID INTO :IDENTITY_PARAMETER

 

 

4. 下一步排查及处理方向

因此，接下来需要及时排查的问题为：

1. 应用程序开发商根据对应的SQL语句，排查程序在3/4日做了哪些升级或更新操作。
2. 程序的调整是短期还是长期需要按此模式运行；这决定了后续数据库层面如何制定相应的备份及删除策略。