没有删除过数据库的DBA职业生涯是不完整的，删除过数据库还能幸存的DBA一定是订阅了“Oracle”公众号。
昨晚有朋友在微信群中求助讨论，误删除了一个MySQL的数据库，整个恢复过程和以下文章中提到的步骤完全相同，只要MySQL主进程还没有退出，从文件句柄中可以恢复文件最终挽回损失。类似的lsof找到那些被标记为Deleted的文件（以下是参考示意图）。
让我们完整的再复习一下这篇文章的步骤，一定要记住这种方法：
今天有客户的数据库意外被删除了整个目录中的数据文件，操作系统级别的删除，然而幸运的是这个数据库没有崩溃，仍然处于 open 状态的时候，客户就发现了问题，求助到我们，最终完整地恢复了所有数据文件。
在 Linux 下大致重新演示一下恢复的过程，恢复的步骤与数据库版本没有太大关系，与操作系统的不同会有所不同。
1. 在数据库 open 的时候，直接删除 users 表空间中的数据文件。
2. 尝试在 users 表空间中创建表，开始报错。
在告警日志中，同样也可以看到类似信息。
3. 检查 dbwr 的进程 PID
4. dbwr 会打开所有数据文件的句柄。在 proc 目录中可以查到，目录名是进程 PID，fd 表示文件描述符。
注意其中“/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf (deleted)”字样，表示该文件已经被删除，如果是 Solaris 操作系统，ls 命令不会有如此清晰的显示，为了在 Solaris 系统中确认哪个句柄对应哪个文件，则需要使用 lsof 程序。
5. 直接 cp 该句柄文件名回原位置。
6. 进行数据文件 recover
完成数据文件恢复。
恢复的原理是，在 Linux 操作系统中，如果文件从操作系统级别被rm掉，之前打开该文件的进程仍然持有相应的文件句柄，所指向的文件仍然可以读写，并且该文件的文件描述符可以从 /proc 目录中获得。但是要注意的是，此时如果关闭数据库，则此句柄会消失，那么除了扫描磁盘进行文件恢复之外就没有其它方法了，因此在数据库出现问题的时候，如果不确认情况的复杂程度，千万不要随便关闭数据库。重启数据库往往是没有意义的，甚至是致命的。
当然，客户的操作系统是Solaris，并且客户删除的文件还包括 current online redo log，因此还有其它更复杂的操作，不在这里描述。