接到应用开发反馈，业务出现故障，重启业务平台报数据库表空间插入失败，查看alter日志发现其中之一个表空间使用率已经接近100%。于是给空间添加数据文件，再次查看表空间使用率，发现使用率仅仅降低了一点，多出的这些空间足够应付业务运行一段时间，所以先让业务平台尽快恢复使用。
接下来，查看备库的alter日志如下：
说明主库添加的数据文件，在备库中未能添加成功。这时第一反应就是存储空间是否有问题，于是赶紧登陆ASM查看磁盘空间，果然，磁盘DATA的剩余空间不够主库添加数据文件大小的空间。
于是跟服务器运维同事申请划分磁盘，扩容。
扩容后，主库切换日志，发现备库并没有同步。再次查看备库alter日志，报错如下：
由报错信息可看出，在备库空间不足的情况下，主库添加的数据文件在备库中并没有成功创建，备库将需要添加的数据文件已UNNAME命名形式记录下来。所以，我们就需要将主库成功添加的数据文件在备库成功创建出来。
将备库设置为recover恢复模式
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
设置备库为手动模式
SQL> alter system set standby_file_management=manual;
System altered.
添加数据文件到备库
SQL> alter database create datafile '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/UNNAMED00018' as '+DATA/phdatafile/adm191.dbf';
Database altered.
将备库设置为自动模式
SQL> alter system set standby_file_management=auto;
System altered.
重新归档接收主库日志
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
查看备库归档进程状态
SQL> select process,status from v$managed_standby;
PROCESS STATUS
------------------ ------------------------
ARCH CLOSING
ARCH CONNECTED
ARCH CLOSING
RFS IDLE
RFS IDLE
RFS IDLE
MRP0 APPLYING_LOG
主库切换日志再次查看备库日志，备库正确接收主库的归档日志，至于，故障解决。
这件事的教训就是要充分重视日常的数据库和存储的巡检工作，如果能提前巡检发现到问题，就不会发展到影响公司正常业务的地步了。
