场景前提
现场情况是 一套单实例没开归档没备份没dg 的oracle 11.2.0.4的数据库。
数据库表空间使用率95%，数据文件的目录磁盘又快满了。
触发原因
简单的问题但朋友刚接触oracle数据库，朋友咨询我怎么做，我给的建议是：先关闭当前磁盘目录下的所有数据文件的自动扩展，再挂载新的磁盘，给表空间新增数据文件，扩容表空间
下面是我朋友的操作 ：先关闭了所有数据文件的自动扩展，再新增磁盘，格式化并挂载磁盘。再扩容表空间
也是很简单很容易对吧，但还是出问题了
问题出现
问题出在挂载磁盘时，目前的数据文件目录有一个叫 /oradata，里面有几个当前的数据文件，于是他新建了一个目录 /oradata2打算把新的磁盘挂载到/oradata2下。
但是
在挂载目录的时候 他直接把磁盘挂载到 /oradata目录上了。 数据库非核心数据文件无法访问不会立刻宕机。所以他没立刻发现，并且在这个挂载好的目录里新建了数据文件。 然后过了一夜直到第二天查表有部分数据查不出来了才发现。select count（*）的时候 会报错。
然后 骚操作 又来了
问题加剧
他发现之后，立即先把新增的数据文件mv 到其他文件夹了。然后umount /oradata 发现umount不了，然后慌了，找我了。
为什么敢直接mv数据文件呢，他解释说：“那些文件都是新的里面应该没有数据，移动了应该不会有影响“ 。。。。。。
很刺激，干这么久数据库，第一次见到直接对运行中的数据库的数据文件下手的。
我听了很难受，没归档，没备份，没dg。好在是一个中间库，数据不是很重要。正好是下班路上，电话指挥他处理。但他也不敢再操作了。担心umount之后原来的数据文件还是会丢失。最后等我到寝室开了向日葵 才了解到具体情况
问题明确
目前问题有两个
- /oradata目录里新增的数据文件mv了，数据库找不到了
- 之前文件夹里的数据文件也没了
问题处理办法
处理办法1.0
- 让他查询一下数据文件中的表，把表数据移动至其他表空间。再把新文件从数据库中删除，然后 再umount文件夹
结果： 那几数据文件涉及的表有十几张，总量100多g，那几个表，一旦移动就会读取被移走的数据文件中的数据块，就会报错。所以这条路走不通
处理办法2.0
- 数据文件被mv走了相当于是被删除，试图从proc目录中恢复。
- /oradata目录mount新磁盘之前的文件，将/oradata新磁盘取消挂载就会恢复
- 恢复文件恢复后，使用bbed修改文件scn号起库。
问题处理过程
- 查询当前数据库的dbw进程的进程号，进入 /proc/pid/fd/目录下查找被mv走的文件，cp至/oradata2 目录存放
- 关闭数据库，将/oradata目录取消挂载。取消挂载后目录内文件正常恢复
- 启动数据库至mount状态。并查阅数据文件scn号
- 编译bbed，使用bbed查询正常数据文件的scn，bbed修改相关数据文件的scn号。
- recover数据文件，正常起库
问题处理结果
数据库正常启动，但数据部分丢失。
问题全过程复盘
下面是我测试环境的故障复原流程
1、还原故障前环境，
单实例，无归档，/oradata目录有数据文件，新增/oradata2目录，新增磁盘并挂载至/oradata目录
1.数据库正常时
2./oradata目录覆盖挂载，挂载后重新进入目录，文件消失
3.在/oradata目录mount新磁盘后，对数据库表查询时，数据库已经开始告警
4.在挂载新磁盘后的/oradata目录 新增数据文件8.9.10
5。再将/oradata目录中已存在新增的数据文件，mv 文件至/oradata2
至此，已完成开始恢复前状态，下面开始恢复操作
1、恢复数据文件，
查询dbwr进程号为2363,进入查看/proc/2363/fd目录下, mv走的新文件被标记为delete。
将新的文件 cp 至/oradata2并修改名字。
2、关闭数据库并umount/oradata目录，umount后，原文件均恢复，
再将/oradata2 中的目录移至/oradata目录中
3.上传bbed 相关文件至对应目录，只需上传 sbbdpt.o ssbbded.o bbedus.msb 三个文件即可
sbbdpt.o ssbbded.o 上传至$oracle_home/rdbms/lib
bbedus.msb 上传至$oracle_home/rdbms/mesg
编译bbed工具,使用oracle用户，在$oracle_home/rdbms/lib 目录执行make命令,make完成后，./bbed 执行bbed命令，默认密码为blockedit
重新启动数据库，数据库报错，启动至mount状态
查询scn 发现 8.9.10 数据文件scn不一致
查看8.9.10 对应的数据文件为新建的数据文件（奇怪的是原来/oradata目录被覆盖的数据文件5.6.7的scn是正常的，没有深究，先恢复数据库）
使用bbed修改scn
1.编辑bbed 参数文件，使用语句从数据库中查出如下信息
新建filelist.txt 文件，将查出的文件复制至filelist.txt中。新建bbed.par文件，写入如下参数
使用bbed.par文件打开bbed，可查看到可编辑的文件
查看正常的数据文件 1 的 文件头，scn信息记录在 kcvfh – kcvfhckp- kcvcpscn- kscnbas中
文件头块中包含两个大的结构，kcvfh 和 tailcjk
查看kcvfh ，找到kscnbas 对应的值为16进制的scn值 002abdef 10进制为2801135
也可以直接输出 kcvfhckp . kcvcpscn 这个结构就是存的 scn ，他基于 8k 的偏移量为 484
也可以直接输出内容
输出的内容中“ efbd2a00 ”就是 11 号文件的 scn 号。这里存的是 16 进制，需要转换为 10 进制。由于 linux 存的是小字节序，意味着实际存的数是反过来的。所以“ ef|bd|2a|00 ”反过来就是“ 00|2a|bd|ef ”，在计算器算一下，该数转换为 10 进制后的数字为“ 2801135 ”，正好是文件 1的 scn 号！
再查看文件8 9 10 的scn
8号文件 002ab147 - 2797895
9号文件 002ab2ab - 2798251
10号文件 002ab3cd - 2798541
现在修改8.9.10 的数据文件头的scn号
修改8号文件
修改 9号文件
修改10号文件
修改完成
检查数据文件scn 均为一致，rcover一下数据文件，然后 开库。数据库正常开启，但是可能丢失部分数据。所以在生产环境中重要的数据库一定要开归档 一定要开归档 一定要开归档 。
此次bbed 只是使用了，对命令半知半解，听说bbed还可以修改表数据库，研究研究
