linux oracle ora-00257,一次ORA-00257错误的处理过程

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

基本情况描述：

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

1、软硬件环境：

操作系统：Sun Microsystems Inc. SunOS 5.10 Generic January 2005(Solaris 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_SID：ORACLE_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命令清空某天或者某几天的归档日志：

例，清空2009年6月22日的归档日志：

ASMCMD>rm –rf 2009_06_22

清空完毕后通过lsdg进行验证无误后，exit出ASM命令行管理界面。

(注：手动清空归档日志，需要在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数据库归档日志、备份软件运行状况定期检查，提前发现、处理可能发生的故障。

附：

附1)crosscheck archivelog all

crosscheck archivelog all

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

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