版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/Partner2016/article/details/88390115
哇，一个心惊胆战的上午。
我们的核心下发库的Oradata所在的磁盘满了（D盘，可使用空间为0了），必须将其中的一个大的.dbf文件迁移到另一个磁盘中。
当时，奇怪的是，通过plsql竟然也能顺利连接正常访问。
哦，我明白了。估计因为数据库没重启，如果重启的话，肯定会报如文201912的错。
虽然能正常访问，但是D盘空间满，必须得做动作，否则以后再往该盘里的.dbf写的时候，就没法写。
于是，百度 .dbf文件迁移的方法，找到一篇很赞的文章:
https://blog.csdn.net/Maybe______/article/details/78711942
跟权威的工程师核实了一下，该文章的做法是可行的。
而且他还给出了如下指示:
停库，拷贝，启动到mount，再修改路径
不放心可以先复制，拷过去之后再把原来的删除
个人觉得他的这个方案比链接中的方案更好，更安全。
在数据库停库后再进行.dbf文件拷贝。
好，那就照着做：
- sqlplus / as sysdba
- sql>shutdown immediate;-----文201912、文201913有介绍如何检测数据库是否已关闭
- sql>select name from v$datafile;—查找要迁移的dbf文件路径
- 拷贝.dbf文件到E: \app\oradata\orcl
- sql>startup mount;—以mount方式启动数据库
- sql>alter database rename file ‘C:\app\oradata\orcl\ SYSTEM01.DBF’ to 'E: \app\oradata\orcl\ SYSTEM01.DBF ';
- sql>alter database open;
在执行转移的时候，我一直很担心，.dbf迁移是否需要处理对应的表空间相关的事情。得到核实，不需要。
其实，更保险的方案：
在第3步，执行：
select t1.NAME,t2.NAME
from v$tablespace t1,v$datafile t2
where t1.ts#=t2.ts#;
这样，看一下，您要迁移的这个.dbf文件到底属于哪个表空间
然后，在第7步结束后，再执行一遍，以作比较。
确认无误后，可以把D盘的.dbf文件删除~
全文终。