应用服务访问异常，server日志如下：

plsql连接不上，异常如下：

 抛出的明显数据库层错误码：ORA-00257: 归档程序错误。只有在解析完成后才以 AS SYSDBA 方式连接

客户没有DBA，还是rac数据库，头大，服务日志出现连接不上数据库，还有个数据库归档的异常，排查下数据库归档，archive log list

归档开着，但是路径指向了根空间下，一般都不会在操作系统的根空间，归档日志本就有很大几率会满，查一下根空间状态 df -h

果然满了，需要尽快释放掉，现在命令的自动不全都不能用了，数据库服务应该是挂起状态了。

两种清理方法：

①最优化用rman进行清理

rman target /

delete rachivelog all;     ##清理全部，也可以选择性清理

②如果rman无法连接数据库，先删除归档路径下的物理文件，然后做crosscheck

rm -rf

rman target /

crosscheck archivelog all;

delete obsolete archivelog all;

delete expired archivelog all;  #清理过期日志

清理之后，数据库应该会恢复正常，但总归放到操作系统根目录下风险太高，建议转到ASM磁盘空间，以下为切换归档路径到ASM，因为客户提供了ASM路径，所以没多想直接进行了切换，导致后面踩了坑。

ASM磁盘归档路径为：+DATA/orclcdb/archivelog

切换过程：rac1节点

SQL> alter system set log_archive_dest='location=+DATA/orclcdb/archivelog' scope=spfile sid='*' SQL> shutdown immediate SQL> startup mount SQL> alter database archivelog;

ERROR at line 1: ORA-01126: database must be mounted in this instance and not open in any instance

#发现归档模式切换不了，先继续往下走 SQL> alter database open; SQL> archive log list

Database log mode                  Archive Mode Automatic archival                    Enabled Archive destination                   +DATA/orclcdb/archivelog Oldest online log sequence     323 Next log sequence to archive   324 Current log sequence                324

SQL> show parameter log_archive_format

NAME                       TYPE            VALUE ----------------------   ------------  ------------ log_archive_format     string        ARC%S_%R.%T

SQL> alter system set log_archive_format='ARC%S_%R.%T_%D.log' scope=spfile; #%S是日志切换号，也就是上文archive log list中的当前日志序列，%R是场景号，%T是线程号， 可以理解成是节点号，如果不是RAC环境，%T都是1，还可以在log_archive_format参数值中加上%D，%D是16进制标识的DBID

SQL> alter system set log_archive_format='ARC%S_%R.%T_%D.log' scope=spfile; SQL> shutdown immediate SQL> startup SQL> alter system switch logfile;

#看到还是之前的归档路径，切换失败.

期间还碰到not logged on，输入什么命令都不行，问题出现的原因是关闭shutdown immediate 的时候，数据库关闭很慢，这时我一心急，就直接退出了sqlplus，造成oracle文件被lock，当我再次startup时，操作失败，因为文件依然被锁定状态

处理办法：smon核心进程存在(huang死 或者没有正常结束)，需要杀掉smon进程，再重新进sqlplus 启动数据库

ps -ef | grep smon

kill -9 pid

rac2节点也按照上面流程做了，查一下两个节点的alert日志吧

 orclcdb目录不存在？

切换grid查一下ASM磁盘有没有这个路径吧

ASM中路径确实不存在，踩了个坑 ,现在数据库服务还是异常的状态，先创建ASM路径看看

建好了后，重启下两节点的数据库实例startup，然后两节点archive log list看下都正常了

 查看下ASM的归档路径下有没有生成日志

日志正常生成，该路径下所在的磁盘空间够不够大呢，查一下ASM磁盘

select t.GROUP_NUMBER,        t.NAME,        STATE,        TYPE,        trunc(t.TOTAL_MB/1024,3) TOTAL_GB,        trunc(t.FREE_MB/1024,3)  FREE_GB,        trunc(((t.TOTAL_MB - t.FREE_MB) / (t.TOTAL_MB+0.001)) * 100,2) use_precent,        trunc(REQUIRED_MIRROR_FREE_MB/1024,3)  REQUIRED_MIRROR_FREE_GB,        trunc(USABLE_FILE_MB/1024,3)   USABLE_FILE_GB   from v$asm_diskgroup t ; 

空间足够大，恢复数据库和应用的连接，业务恢复正常。 

听君一席话，多踩一个坑，实践出真知

踩个坑也挺好，多学习一些东西