一、事件过程
昨天遇到一个棘手的问题，Oracle数据库安装所在的磁盘空间满了，博主第一时间想的是将空间占比最大的dbf数据文件迁移走。
由于此前没有操作过此类事务，不做多想，博主直接剪切到其他空闲盘符，结果提示文件已在OracleServiceORCL中打开，无法操作移动。。。
机智的博主在网上搜索了半天，最后灵机一动想着将文件脱机后迁移，但是此前也没有接触过数据文件脱机，于是瞎操作一通，最后差点导致悲剧的发生！（后文附数据文件脱机教程，详见三点）
由于不清楚应该在什么窗口和模式下执行脱机命令，且当时手上只有一个测试库，另一个测试库因为中病毒被甲方爸爸干掉了，剩下的那个测试库在执行关闭数据库命令半天没有响应。
眼见电脑只剩一丝残血就要关机，数据库也马上要因为磁盘空间已满而崩溃，心急如焚的博主，心一横直接挑了个看起来没啥用，又不像系统数据文件的UNDOTBS01.DBF下手，这个数据文件属于UNDOTBS1表空间，在dba_data_files表中的online_status是online，不是system，一看就不是特别重要的亚子。。
于是年轻的博主直接在plsql的sql窗口中执行脱机命令，依稀记得执行后的报错提示是无法读取或操作文件啥的（英文不好加上夜深没耐心看），但是执行完后提交按钮亮了起来，博主没着急提交，再次查询了一遍状态，当时UNDOTBS01.DBF文件的状态已经变更为recover了，虽然没有达到offline的目的，相比online也算略有所获，于是心满意地点击了提交按钮。。。
这时博主仍然不忘自己的最终目的，心心念念继续将dbf文件迁移走，但是还是失败了，很挫败有木有，此时电脑也好死不死的没电了，不得不吐槽超薄本就这点很垃圾，时间也到了深夜两点，只能等第二天去工作的地方拿电源了，于是不算安稳的睡过去了。。
第二天早上，由于还记挂着昨晚没搞完的工作，昏沉沉的醒来，打开手机一看，10:00，微信消息和电话爆炸，数据库和系统果然不负众望地崩溃了。。急忙忙起来赶往工作地，心中一万头草泥马奔腾而过。
甲方爸爸联系不上博主，已经紧急扩容磁盘，但是系统依然报错。听闻此，博主心中警觉就是昨晚搞出来的recover状态导致，查看系统报错果然如此。系统登录的报错提示更新登录日志表失败，在数据库查询这张更新日志表，发现表不存在，想着能快点解决，不做多想，直接操作建表语句，结果提示 “ 非系统表空间不能使用系统回退段 ”。
来不及仔细思考，直接在plsql的命令窗口查询数据库回滚管理模式和回滚表空间，嗯，回滚表空间就是我昨晚搞的那个，心态爆炸。发现回滚管理模式auto没问题。
继续查询回滚段状态，status提示我"needs recovery"
ok，明白问题所在，解决起来就很快了。
二、文件恢复
1、windows键+R键，输入cmd进入命令窗口
2、输入“sqlplus as sysdba” ,以管理员身份登录Oracle数据库
3、输入“shutdown immediate;”，关闭数据库
4、输入“startup mount;”，是数据库处于挂载模式，只挂实例，不启动数据库，只有mount模式下才能使数据文件脱机或恢复，包括开启数据库归档，非归档模式下使用rman备份，都需处于该模式下方可继续操作
5、输入“ recover datafile 'D:\app\Administrator\oradata\UNDOTBS01.DBF' ”命令恢复数据文件，若文件仍在原处，并未移动或删除，可直接输入“recover datafile 3”命令，（文件路径未更改指dba_data_files中的file_name路径，3指该表中的file_id）
6、文件恢复后，此时的数据文件在dba_data_files表的online_status会变成offline，所以还需继续输入“alter database datafile 3 online;”
7、最后，输入“alter database open;”命令，打开数据库
三、扩展
如果要将数据文件脱机，只需将第二点中的第6条命令改成“alter database datafile 3 offline”即可。
