用rman查一下看看，crosscheck archivelog all;

然后再到归档日志目录ssd盘下看一下，具体有多少归档日志，应该是归档日志没有注册到吧

rman下catalog start with重新注册下，然后执行删除呢

可以参考下面的文章，利用rman清理已经归档。

https://blog.huati365.com/dc8ab204ddbddba4

1、 crosscheck archivelog all;--此命令的含义是检查所有归档日志的状态，并把遗失的标记为expired，也就是说，expired 表示已经被操作系统中被删除的归档日志。

 2、delete expired archivelog all; --此命令的含义是删除expired的归档日志

catalog start with 重新注册的结果

清除过期日志

+ssd/EASDB/ARCHIVELOG/目录下有多少文件？截图看下

先确认下你的闪回区里是谁占用的空间，是归档日志不：

select file_type,
          percent_space_used        as used,
          percent_space_reclaimable as reclaimable,
          number_of_files           as "number"
     from v$flash_recovery_area_usage;

+ssd/EASDB/ARCHIVELOG/目录情况

和V$RECOVERY_FILE_DEST的数据不一致

SELECT * FROM V$RECOVERY_FILE_DEST;

说个笨方法，你到grid用户下，然后asmcmd，cd ssd目录下

然后du 每个目录，看看空间到底是被谁给用了

du SSD目录的情况

这个目录文件夹

神奇啊，通过v$recovery_file_dest查询出来的使用空间和在asmcmd中查询出来的完全不一致，归档只占用了12.5G

你在系统执行下这个，看下有没有正在用被删文件的进程，导致空间没释放

lsof | grep deleted

select file_type,
          percent_space_used        as used,
          percent_space_reclaimable as reclaimable,
          number_of_files           as "number"
     from v$flash_recovery_area_usage;

执行这个看看

正常啊，你asmcmd后lsdg看一下

两个节点的参数都是一样的，1000G

上杀手锏，试试这个吧，

重置一下v$recovery_file_dest

 alter session set events 'immediate trace name kra_options level 1';

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=298937656790111&id=2780810.1&displayIndex=4&_afrWindowMode=0&_adf.ctrl-state=5yt49g99d_484

问题处理的怎么样？解决了么

看起来不需要重启，mos上的文档，风险应该比较可控。

最后咋解决的呀，学习学习