ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一次ORA-00257错误的处理过程

一次ORA-00257错误的处理过程

原创 Linux操作系统 作者:湖湘文化 时间:2013-11-19 17:52:50 0 删除 编辑
 

一次ORA-00257错误的处理过程

基本情况描述:

  今天在客户那边的一个实际项目中遇到出现ORA-00257错误(空间不足错误),通过查找,发现是由于归档日志太多,占用了全部的硬盘剩余空间导致的,通过简单删除日志或加大存储空间就能够解决。

1、软硬件环境:

操作系统:Sun Microsystems Inc. SunOS 5.10 Generic January 2005Solaris 10

数据库:Oracle 10.2.0.4.0 - 64bit Production RAC + ASM

2、问题现象:

应用访问不了,数据库报错ORA-00257

SystemErr.log部分报错信息如下所示:

[8/2/10 11:51:32:503 CST] 4128c665 SystemErr R   at java.lang.reflect.Method.invoke(Method.java:386)

[8/2/10 11:51:32:503 CST] 4128c665 SystemErr R   at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)

[8/2/10 11:51:32:563 CST] 4128c665 SystemErr R java.sql.SQLException: ORA-00257: archiver error. Connect internal only, until freed.

alert文件以及相应的trc文件部分报错信息如下所示:

*** 2010-08-02 11:48:54.115 62692 kcrr.c

ARC0: Error 19504 Creating archive log file to '+DG1'

*** 2010-08-02 11:48:54.115 60970 kcrr.c

kcrrfail: dest:1 err:19504 force:0 blast:1

ARCH: Connecting to console port...

ARCH: Connecting to console port...

*** 2010-08-02 11:48:54.130 21373 kcrr.c

ORA-16038: log 1 sequence# 4177 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: online log 1 thread 1: '+DG1/db/onlinelog/group_1.258.690640367'

ORA-00312: online log 1 thread 1: '+DG1/db/onlinelog/group_1.259.690640369'

*** 2010-08-02 11:54:54.337

Failed to create file '+DG1' (file not accessible?)

*** 2010-08-02 11:54:54.337 62692 kcrr.c

ARC0: Error 19504 Creating archive log file to '+DG1'

*** 2010-08-02 11:54:54.337 60970 kcrr.c

kcrrfail: dest:1 err:19504 force:0 blast:1

ARCH: Connecting to console port...

ARCH: Connecting to console port...

*** 2010-08-02 11:54:54.351 21373 kcrr.c

ORA-16038: log 1 sequence# 4177 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: online log 1 thread 1: '+DG1/db/onlinelog/group_1.258.690640367'

ORA-00312: online log 1 thread 1: '+DG1/db/onlinelog/group_1.259.690640369'

*** 2010-08-02 12:00:54.462

Failed to create file '+DG1' (file not accessible?)

*** 2010-08-02 12:00:54.462 62692 kcrr.c

ARC0: Error 19504 Creating archive log file to '+DG1'

3、诊断和解决过程:

1)登陆到第一个节点,切换到oracle用户:su - oracle

2)更改并输出环境变量ORACLE_SIDORACLE_SID=+ASM1;export ORACLE_SID

(如果登录的是集群第二个节点,相应地:ORACLE_SID=+ASM2;export ORACLE_SID

3)进入ASM命令行操作界面:asmcmd

ASMCMD>

ASMCMD> lsdg

State Type Rebal Unbal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Name

MOUNTED EXTERN N N 512 4096 1048576 102140 33 0 33 0 DG1/

(查看Usable_file_MB一列的ASM磁盘组可用空间数)

如果为0或者接近于0,应该考虑及时清空RAC 数据库上的归档日志。

cd 到归档日志所在目录

BBS数据库在ASM磁盘组上归档日志位置:+DG1/BBSDB/ARCHIVELOG

归档日志会在该目录下以天为单位进行目录结构组织,例:

ASMCMD> ls

              2009_06_22/

              2009_06_23/

              2009_06_24/

        

根据需要使用rm命令清空某天或者某几天的归档日志:

例,清空2009622日的归档日志:

ASMCMD>rm –rf 2009_06_22

清空完毕后通过lsdg进行验证无误后,exitASM命令行管理界面。

(注:手动清空归档日志,需要在RMAN下进行check工作,以便及时更新归档日志信息,具体方式如下:

              ORACLE_SID=db1;export ORACLE_SID ;

恢复ORACLE_SID环境变量

              oracle@db1 $ rman

              RMAN> connect target;

                            connected to target database: DB (DBID=XXXX)

              RMAN> crosscheck archivelog all;

              ……

              RMAN>exit

       之后,应该立即进行一次数据库全备。

              )

4)按照上面的操作,手工删除掉了6月的归档日志,归档可用空间增大到7G多,应用也早已能正常访问。

4、总结:

造成本次故障的原因:

由于备份软件没有正常运行,还有备份脚本也有问题,造成归档日志没有及时删除。

  从本次故障解决处理中,我们可以得出经验教训:

  对备份脚本和备份软件要进行充分的测试;

对数据库系统管理员要对Oracle数据库归档日志、备份软件运行状况定期检查,提前发现、处理可能发生的故障。

1crosscheck archivelog all

crosscheck archivelog all

RMAN的备份中(Veritas等备份软件由于归档日志的异常导致归档日志备份失败)是经常碰到的,解决方法也是非常解单,就是执行2RMAN的命令:

1. 进入rman

2. connect target /

3. crosscheck archivelog all;

4. delete expired archivelog all;

===========================

下面说明一下:

controlfile中记录着每一个archivelog的相关信息,当我们在OS下把这些物理文件delete掉或异常变动后,在controlfile中仍然记录着这些archivelog的信息,当我们手工清除archive目录下的文件后,这些记录并没有被我们从controlfile中清除掉,也就是oracle并不知道这些文件已经不存在了!这时候我们要做手工的清除。

crosscheck archivelog all;的作用就是检查控制文件和实际物理文件的差别。

delete expired archivelog all;就是同步控制文件的信息和实际物理文件的信息。

如果单独执行crosscheck而没有执行delete那么备份还是失败的,原因是那些控制文件的信息和实际的信息还是不同。

crosscheck backupset

crosscheck backupset 是检查备份集和实际的文件

1 备份集有两种状态A(Available,RMAN认为该项存在于备份介质上)X(Expired,备份存在于控制文件或恢复目录中,但

是并没有物理存在于备份介质上)

2 crosscheck 的目的是检查RMAN 的目录以及物理文件,如果物理文件不存在于介质上,将标记为Expired。如果物理文件

存在,将维持Available。如果原先标记为Expired的备份集再次存在于备份介质上(如恢复了损坏的磁盘驱动器后),

crosscheck将把状态重新从Expired标记回Available

3 crosscheck 输出分两部分。第一部分列出确定存在于备份介质上的所有备份集片,第二部分列出不存在于备份介质上的

备份集片,并将其标记为Expired。当设置备份保存策略后,一个备份过期,crosscheck之后标记为丢弃的备份状态依旧为

availabel,要删除丢弃备份delete obsolete

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

上一篇: 学习perl(6)
请登录后发表评论 登录
全部评论

注册时间:2009-05-31

  • 博文量
    108
  • 访问量
    1521614