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,total_mb,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语句中存在类似于死循环的东西，导致归档日志如此庞大，后续有什么发现，我将再次记录下来。
致此，归档日志空间已满议题是暂时解决了。
