ORACLE 11G DB RAC ORA-00257archiver error解决办法

ORA-00257archiver error解决办法

1.之前有处理单机过oracle 11.2.0.4归档日志磁盘空间不足的问题 ，但是没有处理过ORACLE RAC的归档日志磁盘空间不足的问题

所以没有预想到会是出现asm磁盘空间不足的议题

Oracle数据库是目前业界最常用的大型数据库系统，我在单机ORACLE的实际项目中有遇到出现ORA-00257错误（空间不足错误），

通过查找资料，发现绝大部分说这是由于归档日志太多，占用了全部的硬盘剩余空间导致的，可通过简单删除日志或加大存储空间就能够解决。但是我在Oracle11g RAC上两个RAC节点发现，它们的存储空间都还有很大，却也报这个错误，经过大半天的折腾，发现原来是Oracle11g RAC中的ASM磁盘空间不足导致的。

操作系统CentOS 6.5 x86-64Linux

数据库Oracle 11.2.0.4.0

2.问题现象

数据库系统已经运行了一年多，在5月8号开发同事用应用账号连接数据库后，发现无法连接登入，并且出现ORA-00257：archive error.connect internal only,until freed 错误。

提示归档错误，通过查找ORACLE错误代码，解释为硬盘空间不足，需要删除归档日志增加空间，但是服务器两个节点可用空间都还有1.4T，目前只用了10GB左右，这是为什么呢？

且在5月8号用rman形式删除清理系统100天以前的归档日志以后好了，没想到第二天5月9号又出现了。没有理由啊，一天的归档日志大过一百天的归档日志，所以我就质疑数据库报错的准确性，认为这只是表面的归档日志空间已满，实质性的问题却还不知道。

3.诊断过程：

因为数据库不是我架设的，对oracle也不太熟，所以不知道归档日志放置的路径，通过语句查找也得到的是个+ARC/back/archivelog/**之类的，但是我就是想破脑袋，用find的方式也找不到具体存放路径。

a.查看数据库REDOLOG情况

[root@~]$ sqlplus / as sysdba

SQL> connect / as sysdba

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE#FIRST_TIME

---------- ---------- ---------- ---------- ---------- ------------------------------------------ --------------

1 1 101 52428800 1 NO CURRENT 3621973 9-5月 -17

2 1 99 52428800 1 NO INACTIVE 3600145 9-5月 -17

3 1 100 52428800 1 NO INACTIVE 3611932 9-5月 -17

发现ARC状态为NO，表示系统没法自动做归档。

b.查看Oracle数据库后台归档服务进程

[oracle@~ ]ps -ef | grep oracle

发现grid 3081 1 0 10:14 ? 00:00:00 oracle+ASM1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

一个节点如上述服务正常，但另外一个节点却LOCAL=NO的类似情况，反正服务不正常

c.查看FLASH_RECOVERY_AREA空间中各部分使用情况

SQL> select * from v$recovery_file_dest;

NAME

--------------------------------------------------------------------------------

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

----------- ---------- ----------------- ---------------

+BACKUP

1.2885E+11 484442112 0 5

##注：空间大把的有

SQL> select * from v$flash_recovery_area_usage;

FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

-------------------- ------------------ -------------------------

NUMBER_OF_FILES

---------------

CONTROL FILE .04 0 1

REDO LOG .33 0 4

ARCHIVED LOG 0 0 0

FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

-------------------- ------------------ -------------------------

NUMBER_OF_FILES

---------------

BACKUP PIECE 0 0 0

IMAGE COPY 0 0 0

FLASHBACK LOG 0 0 0

FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

-------------------- ------------------ -------------------------

NUMBER_OF_FILES

---------------

FOREIGN ARCHIVED LOG 0 0 0

7 rows selected.

发现ARCHIVELOG、BACKUPPIRCR都不大，就是0，没什么占用率，这样FLASH_RECOVERY_AREA空间的空间还大把的有。

因为之前报错时，不知道如何处理问题，就像直接shutdown immediate一个节点看看，没想到半天没任何反应，就直接使用shutdown abort强行关闭,该节点出现下列节点挂载实例报问题

d.故障节点挂载实例报错：

SQL> startup

ORACLE instance started.

Total System Global Area 413372416 bytes

Fixed Size 2253784 bytes

Variable Size 327158824 bytes

Database Buffers 79691776 bytes

Redo Buffers 4268032 bytes

Database mounted.

ORA-03113: end-of-file on communication channel

Process ID: 2420

Session ID: 1 Serial number: 5

e.查找资料发现，下面做法可行：

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup nomount

ORACLE instance started.

Total System Global Area 413372416 bytes

Fixed Size 2253784 bytes

Variable Size 327158824 bytes

Database Buffers 79691776 bytes

Redo Buffers 4268032 bytes

SQL> alter database mount;

Database altered.

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01034: ORACLE not available

Process ID: 0

Session ID: 0 Serial number: 0

发现在打开数据文件报错

SQL> recover database until time '2017-05-09'

ORA-00283: recovery session canceled due to errors

ORA-01124: cannot recover data file 1 - file is in use or recovery

ORA-01110: data file 1: '+DATADG/fmall/datafile/system.259.907327891'

用覆盖形式恢复也报错

f.后面有资料提出可使用RMAN操作系统删掉归档来解决问题

rman下crosscheck然后delete。

[oracle@~ ]rman target sys/pass

RMAN > crosscheck archivelog all;

validation succeeded for archived log

archived log file name=+ARCH/fmall/archivelog/2017_03_08/thread_2_seq_6362.21528.938070989 RECID=43022 STAMP=938070990

validation succeeded for archived log

RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row

RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows

ORACLE error from target database:

ORA-01089: immediate shutdown in progress - no operations are permitted

Process ID: 14578

Session ID: 235 Serial number: 2647

校验日志的可用性，报错或者等待很久没有结果出来

RMAN > delete archivelog all completed before 'sysdate-30';

RMAN-08137: WARNING: archived log not deleted,needed for standby or upstream capture process

如果你删除三十天前的归档日志，等待很久却没有结果，甚至像上面一样报错可以参考我下面的做法

RMAN > delete force noprompt archivelog until time 'sysdate-30';

强制性删除三十天前的归档日志

网站异常告警解除，说明归档日志腾出空间，致使数据库可正常提供应用连接。

g.实例证明，归档日志空间已满导致应用无法连接数据库

有经验的DBA告诉我说，RAC会有一个ASM的磁盘空间议题，我经过查询ASM磁盘空间发现，我的妈呀，ARCH的空间就才腾出282M。

SQL> select name,total_mb,free_mb from v$asm_disk;

NAME TOTAL_MB FREE_MB

------------------------------ ---------- ----------

GRIDDG_0001 4768 4585

ARCH_0000 944137 282

DATADG_0000 1238390 1202771

GRIDDG_0000 4768 4553

BACKUP_0000 953675 949001

再次进入RMAN，使用delete archivelog的方式再删除15天后，查看ASM磁盘空间大小：

SQL> select name,free_mb from v$asm_disk;

NAME TOTAL_MB FREE_MB

------------------------------ ---------- ----------

GRIDDG_0001 4768 4585

ARCH_0000 944137 716045

DATADG_0000 1238390 1202771

GRIDDG_0000 4768 4553

BACKUP_0000 953675 949001

空出了将近700多G的空间，太可怕了，短短十五天就能够用掉将近七百多G的归档日志空间，我的数据库大小才1.1G，归档日志就一天以十几二十G的速度疯长。一定是哪里出了问题，必须彻查。

当然首先要做的估计就是把清理归档日志命令写成脚本纳入crontab里，按一定时间进行处理。初步怀疑是应用程式sql语句中存在类似于死循环的东西，导致归档日志如此庞大，后续有什么发现，我将再次记录下来。

致此，归档日志空间已满议题是暂时解决了。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!