作者 | JiekeXu
来源 | JiekeXu之路(ID: JiekeXu_IT)
二、解决问题 当出现这个问题时，紧急处理办法就是先将业务切到一个节点上，即出错的节点，或者允许的话可将其另一个节点直接关闭，然后得想办法将此数据文件迁移到它原来的共享裸设备中，其实也很简单，大概就是先 offline 数据文件，然后 rman 中 copy 此数据文件，接着数据库中 alter database rename 数据文件, 做 recover 恢复，然后 online 即可。 当然，将其迁移到裸设备共享文件系统中的前提条件就是要有裸设备，经过存储和系统层面的添加，划分出如下四块裸设备： 使用前面做好的裸设备迁移，下面是一个完整的步骤： 如下是 alert 日志中出现的步骤，可作为参考：三、添加表空间数据文件
迁移完成后另一节点便可以正常访问此数据文件中的数据了，最后要说的一点就是这个裸设备该怎么添加数据文件呢？一是查看 dba_data_files.file_name 确认以前的数据文件位置，或者查看 alert 日志查看添加成功的记录，两者均可：
如下是一个成功添加的案例，可参考：
四、11g RAC 如何做？
11g 或者以上可以使用 asmcmd copy 本地文件到磁盘组，这是一个很不错的新功能，那么通常在 11g 及以上 RAC 中，由于忘记写盘号 "+" 导致出现问题。
这样便添加到本地文件系统了，还没有任何报错，下面我们来看看具体的操作步骤：
1、切换日志、offline 要迁移的数据文件
2、拷贝本地文件到ASM
3、修改控制文件信息，online 数据文件
4、检查验证
多次切换日志，检查数据库告警日志有无报错，发现无异常，另一节点也可以正常访问了，说明问题已解决，本地文件系统的数据文件后期可清理了。
好咯，今天的分享就到这里了，如果本文对您有一丁点儿帮助，请多支持“在看”与转发，不求小费了哪怕是一个小小的赞，您的鼓励都将是我熬夜写文章最大的动力，让我有一直写下去的动力，最后一起加油,奥利给！