点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

接到一个告警，反馈一套RAC+RAC ADG主备延迟已达到20分钟以上，原本以为是个日志应用延迟的小问题，毕竟这套库运行稳定，也未听说有大的变更。

登录检查后发现，备库日志应用经常已经挂掉：

尝试重启，发现很快会自动关闭。这时候意识到问题应该没有那么简单了。

打起精神，仔细检查数据库状态：

• 实例及集群运行正常；

• 服务器及数据库负载正常；

• 归档目录空间充足。

进一步排查数据库日志，发现了线索：

MRP0进程第一次异常退出日志信息：

以上日志可以看出，重启启动MRP进程后，很快异常退出，原因则是339号数据文件异常，这个数据文件路径竟然是本地目录（本环境为ASM），这显然是有问题的。查询该数据文件状态也为RECOVER。

联系值班人员得知，应客户需求，刚刚对一使用率高的表空间进行了紧急扩容操作，但因为DATA磁盘组资源不足，因此新增数据文件创建目录为另一磁盘组。

首先想到一个可能性，会不会是备库standby_file_management参数设置有问题，设置成了manual：

结果发现，竟然是AUTO。看样子问题不在这里，还要继续深入排查。

突然联想到刚才值班人员说到的一个信息，新增数据文件是扩容到另一个磁盘组，有没有可能是这个环节出现问题，马上检查数据库配置。

首先，备库缺失339之后新扩容的所有数据文件；

其次：

备库的db_create_file_dest还是已经没有空间的DATA磁盘组，到这里，问题就很明白了，主库扩容的数据文件到新的磁盘组，但备库依然会将数据文件创建到DATA磁盘组，而该磁盘组已经没有空间，自然会报错，从而引发备库日志应用进程也出现异常。

找到了原因，处理起来就容易了，既然备库数据文件创建异常，那就需要重建异常的数据文件到新磁盘组中，然后再拉起MRP进程即可。

这次异常的根本原因是备库db_create_file_dest参数未置空或者修改为新磁盘组，导致新增数据文件仍尝试创建在已无空间的DATA磁盘组，但创建失败并导致MRP进程异常，进而触发备库日志应用延迟告警。

处理过程：

SQL> alter system set standby_file_management=MANUAL sid=’*’ scope=both;
SQL>alter database create datafile ‘/u01/app/oracle/product/19.0.0/dbhome_1/dbs/UNNAMED00339’ as ‘+DATA02’ size 30G autoextend off;
SQL> alter system set standby_file_management=AUTO sid=’*’ scope=both;

重新发起备库MRP进程即可。

END