问题描述：本来还在愉快的工作中，突然同时通知客户主数据库无法登陆了，心中莫名的一紧，赶紧登陆数据库查看，发现只有sys账号可以正常登录，其他账号登录均提示ora00257错误。
赶紧百度一下，看大致的意思为归档日志写满了、闪回日志写满了。根据网上提供的方法进行查看：
select * from v$recovery_file_dest; select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage; select * from v$flash_recovery_area_usage; select * from v$version;
发现根本没有信息返回，应该是未开启闪回日志，正好想起前一阶段数据库才开启了归档日志，因此怀疑是归档日志写满的问题。归档日志信息可以在v$archived_log表中查询到。
解决方法：
因为时间比较紧急，没空给我进行慢慢的排查解决了（主要是我太菜），直接求助公司大神吧。具体解决步骤如下：
1、远程登录数据库任意节点（现场为rac集群），切换到oracle账号通过lsnrctl status命令查看监听到的服务。
在执行lsnrctl status命令时候，如果提示命令未找到，很可能是环境变量的问题，通过source ~/.bash_profile命令使之生效即可。
2、到grid用户下，分别执行以下命令，进入asmcmd命令行。
su – grid
export oracle_sid=+asm1
asmcmd
这里需要注意一下，su – grid 而不是su grid之前执行的时候就想当然的弄错了，结果执行命令的时候一直报错。
其简单区别如下：
su – grid 要给grid 重新配置环境变量
su grid 使用切换到grid 用户之前的那个用户的环境变量。
执行lsdg命令查看磁盘组使用情况：
可以查看磁盘组总量，以及可使用量（我这里是删除部分日志后的截图），查看其可用空间是否满足。
3、如果需要删除归档日志，需要定位到归档日志目录，查看归档日志情况。
cd +datadg/orcl/archivelog
ls
4、根据自己需要，删除执行的归档日志即可。例如，删除2020年2月份的归档日志可以使用rm -rf 2020_02*命令。
优化建议：
对于出现这种情况，归根结底是磁盘无法放下过多的归档日志，可以考虑：
1、挂接单独的磁盘组存储归档日志，并同步进行备份（推荐）。
2、对当前磁盘组进行扩容。
3、定期进行人工检查，删除部分归档日志以保证磁盘空间保持有剩余状态，或者设置自动删除较早的归档日志。
后续补充：通过下面语句可以查看磁盘归档日志的大小占用情况。
select trunc(first_time) "日期", trunc(sum(blocks*block_size)/1024/1024/1024,2) "大小（gb/day）" from v$archived_log group by trunc(first_time) order by 1 desc