数据库故障排除小记 ORA-00470 ORA-00471

最新推荐文章于 2021-12-16 11:35:06 发布

cnd3733

最新推荐文章于 2021-12-16 11:35:06 发布

阅读量317

点赞数

文章标签：数据库操作系统

问题描述
系统数据服务器发生过几次崩溃，导致业务无法正常使用，虽然可以重启数据库暂时恢复业务，但是这种不定期的当机无论对于系统维护还是市场都造成了很大的压力和不好的影响。好，既然有问题存在，那肯定是要解决的。以下就是根据这次问题解决过程给各位描述一下遇到类似问题的处理办法。希望对各位有所帮助。

确认问题
从别人口中获取的消息或者故障详情都要抱着怀疑论证的态度，所以第一步还是去确认一下问题是不是如他人所述。查看系统日志，通过分析系统日志中的信息，我们可以确认近期数据库确实因为某些原因意外崩溃，通过对崩溃的时间进行分析，我们可以得出结论数据库崩溃完全是随机的，没有固定周期。这说明并不是因为某一个定期的大型作业导致系统崩溃。我们抓取了系统每次崩溃时反应出的错误信息，主要有以下两类：

  Errors in file /oracle/oraInventory/admin/barcode/bdump/linkaged_pmon_4014.trc:
  ORA-00471: DBWR process terminated with error

  Errors in file /oracle/oraInventory/admin/barcode/bdump/linkaged_pmon_532.trc:
  ORA-00470: LGWR process terminated with error

分析问题
从字面上来分析，这几次意外崩溃都是因为ORACLE的重要进程被终止而造成的。
DBWR 数据库写入程序
LGWR 日志写入程序
我们都知道，这两个进程都是ORACLE最重要的进程，如果他们被意外关闭了，势必会造成数据库当机。根据自己对系统的理解，大致可以把问题缩小在以下一个范围：
1、这两个进程被人误kill掉了 --这个通过问题发生的频率和时间基本上可以排除。
2、这个台机器被黑了，有居心叵测的人在搞我们的系统。 --查看系统近期登陆日志，排除此类问题。
3、LGWR被终止，会不会是因为系统日志组分配和日志读写策略配置不恰当，在系统忙时导致日志组切换频繁，导致该进程崩溃，进而导致系统崩溃。 --通过对日志的切换分析不排除这种情况。
4、DBWR被终止，有可能是某些人在建立数据文件时，设置不正确，导致该进程在写数据时发生错误，导致系统崩溃。 --通过分析日志，不排除这种原因，有以下错误为证

   ORA-604 signalled during: create tablespace WORK DATAFILE 'D:\ORACLE\ORADATA...
  Fri May 23 16:53:56 2008
  create tablespace WORK DATAFILE 'D:\ORACLE\ORADATA\WYC\WORK.DBF' SIZE 500M AUTOEXTEND
  ON NEXT 100M

5、最次的情况，物理磁盘有问题。 -- 同样有可能，因为DBWR、LGWR都在读写时发生过错误。

暂且从这几个方面去分析问题。

解决问题
查看一下ORACLE官方对这两种错误有什么解决方案，或者其他人有没有遇到过类似问题，并已经解决。站在前人的肩膀上永远都是最明智的选择。国人的最强大的能力要好好发扬。遍历了网上数十个帖子。

官方文档：
Cause: The log writer process died

Action: Warm start instance

大意是进程死掉了，建议你重新启动。基本上没有什么有价值的信息。

网上其他人的经验的核心思想：
A、日志组配置不正确，导致日志切换频繁。
B、日志写入频繁，在一个时间周期内，生成文件数量超过系统配置限度。

解决过程
1、调整日志组策略，调整系统打开最大文件数的参数，进行观察。第二天又发生之前的症状。继续调整
2、到现场确认磁盘阵列，确认磁盘阵列情况正常。
3、切换服务器HA后，系统正常。
4、对比两台服务器差异，发现发生错误的那台服务器的系统内核配置文件中

#vi /etc/sysctl.conf

#发现曾经有人修改了这个参数，将进程使用内存最大数量限制在32M，当系统进程超过限度，进程将被强制关闭。
kernel.shmmax = 33554432

#将参数调整到2G
kernel.shmmax = 2147483648

PS：该操作系统为32位，安装LINUX后系统配置文件中不会存在此参数，同时32位操作系统本身就存在着2G的进程使用内存限度，所以调整此参数毫无意义。故开头未想到这个方面。另外该参数单位为比特，不方便第一眼发现问题，因此建议以后还有仁兄修改此参数后在一旁加上注释。便于后人发现问题。

小记
解决问题，一定要分析全面，步步为营，一个一个排除，切忌想到哪就是哪，这个可能会瞎猫碰到死耗子被你撞上，但是效率和成效是不能保证的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7813229/viewspace-623999/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7813229/viewspace-623999/