rm -rf / 删库后除了跑路，你还可以Carry全场！
作为IT资讯界的活跃分子之一，删库到跑路一直是科技领域的百年硬梗！他真的很“硬”！据小编“不准确”统计，近年来由于删库导致的业界事故N起，数据丢失N万，预计损失达到N亿。
近几年发生的著名数据库删除事件有：
- 2017 年 2 月，GitLab 的一位系统管理员在给线上数据库做负载均衡工作时，遭受了 DDoS 攻击。在阻止了攻击之后，运维人员发现了数据库不同步的问题，便开始修复，在修复过程中，错误地在生产环境上执行了数据库目录删除命令，导致 300GB 数据被删成 4.5G，GitLab 被迫下线。
- 2017 年 9 月，某 IT 大厂技术工程师帮助某省移动进行扩容割接（即增加系统容量）时，不小心将 HSS 设备里面的用户数据格式化删除，导致某省移动近 100多万用户数据丢失，使用户手机8个多小时失联，不能通话上网。
在数据经济时代的今天，数据已经成为企业最核心的资产。删库的最后，有的工程师被迫跑路，有的工程师被迫离职..
IT运维十年头，错误操作事故天天有！当我们真的出现误删库的时候，你第一时间想到的是如何跟自己的领导解释？还是收拾行李跑路？
作为一个身经百战的老同志，千万不要有以上的两个念头，解决问题的方法是如何快速找回被删除的表和数据。
删库分为物理删库和逻辑删库两种，今天小编就同大家分享一波在这两种情况下的删库自救方式~
目录
1. 物理删除数据库
1.1 某个数据文件被rm掉了
1.2 整个数据库数据文件被物理rm掉了
2. 逻辑删除数据库
2.1 闪回单个表
2.2 闪回数据库
3. 总结
3.1 对数据库维护流程的思考
3.2 数据备份机制
1. 物理删除数据库
最常见的误操作有由于网络卡，想输入：
rm -rf /tmp
可能网络卡顿一下，打成了
rm -rf / tmp
针对rm数据库数据文件，只能通过备份文件进行恢复。
1.1 某个数据文件被rm掉了
某个数据文件被rm掉，此时可以基于数据文件的恢复，或者基于表空间的恢复（如果数据文件很大，表空间恢复比较慢）。
第一步：设置的数据文件脱机
SQL>alter database datafile 4 offline;
第二步：由RMAN装载数据文件
RMAN>restore datafile 4;
第三步：对损坏的数据文件进行恢复
RMAN>recover datafile 4;
第四步：设置已恢复数据文件联机
RMAN>sql “alter database datafile 4 online”;
第五步：查看数据文件的可用性
SQL>select name,enabled,status from v$datafile;
至此，一个非系统表空间的数据文件恢复过程完成。
1.2 整个数据库数据文件被物理rm掉了
用于数据库彻底崩溃，只能基于全数据库恢复方法。
这种方法很简单（时间可能会很长！）---装载回数据库的一个完整备份集进行恢复操作。
- 首先需要启动数据库实例。
- 在控制文件完好的情况下，启动到mount状态是没有问题的。
- 如果控制文件损坏，则只能启动到nomount状态。
在本例中，数据库可以启动到mount状态。
第一步：启动实例
SQL>startup mount
第二步：进入到RMAN环境下
$rman target /
第三步：装载数据库备份
RMAN>restore database;
第四步：执行下面的命令进行数据库的完全恢复
RMAN>recover database;
第五步：打开数据库
RMAN>alter database open;
2. 逻辑删除数据库
以Oracle为例，MySQL、SQL Server等数据库类似。
在Oracle数据库实际操作中，经常会使用delete语句删除数据，有时会误操作了不应该删除的数据。
2.1 闪回单个表
Oracle有一个初始化参数RECYCLEBIN来控制闪回功能的开启与关闭。
默认时，此参数设置为ON，这表示所有删除的表都要进入回收站，可利用闪回删除特性恢复它们。
通过设置此参数的值为OFF，关闭闪回删除特性，表在被删除前不进入回收站。
1） 查看回收站
回收站是一个逻辑结构，一个名为RECYCLEBIN$的数据字典。
你可以通过USERRECYCLEBIN视图（RECYCLEBIN为USERRECYCLEBIN的同义词），查看自己的回收站中的当前登记的内容。
也可以通过DBA_RECYCLEBIN视图查看整个数据库的回收站的内容。例如：
SQL>select owner,original_name,object_name,ts_name,droptime from dba_recyclebin;
在用户级，可从RECYCLEBIN视图而不是DBA_RECYCLEBIN视图中选择。也可以在SQL*PLUS中使用SHOW RECYCLEBIN命令：
SQL>SHOW RECYCLEBIN
2） 恢复被删除的表
SQL>FLASHBACK TABLE persons TO BEFORE DROP;
当然也可以使用系统生成的表名
注意：为使用FLASHBACK TABLE table_name TO BEFORE DROP命令取回一个表，你必须拥有它或者具有此表的删除权限（DROP TABLE或DROP ANY TABLE）。为使用PURGE命令，需要类似的权限。为了查询回收站中的对象，必须具有SELECT权限和FLASHBACK权限。
3） 永久删除表
永久删除表
SQL>DROP TABLE persons PURGE;
永久删除回收站中的表
SQL>PURGE TABLE persons; SQL>PURGE index persons;
2.2 闪回数据库
闪回数据库功能复原数据文件但不需要备份的数据文件，它只使用部分归档重做日志信息。
闪回数据库操作将数据库的所有数据文件倒回到以前的某个特定时间点。
说明：只能在没有介质故障时闪回一个数据库。如果丢失了数据文件或数据文件讹误，则必须采用从备份复原的数据文件进行恢复。
以下情况使用闪回数据库：
- 找回某个删除的模式
- 在某个用户错误影响到整个数据库时
- 在错误地截断一个表时
- 在一个批作业只执行了部分更改时
1） 配置闪回数据库
为了配置闪回数据库特性，需要进行一系列的操作，如下所示：
a) 通过查询V$DATABASE视图或简单地发布下面的命令，检查数据库是否处于归档方式：
SQL>ARCHIVE LOG LIST;
如果数据库不处于归档模式，可用如下代码所示的ALTER DATABASE语句打开归档日志，代码如下:
SQL>SHUTDOWN IMMEDIATE; SQL>STARTUP MOUNT; SQL>ALTER DATABASE ARCHIVELOG; SQL>STARTUP
b) 设置快闪恢复区
方法一：在初始化参数文件(init.ora)中配置
DB_RECOVERY_FILE_DEST_SIZE = 10G DB_RECOVERY_FILE_DEST = ‘/u01/oradata/rvc_area’
方法二：动态定义
SQL>ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G SQL>ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = ‘/u01/oradata/rvc_area’
c) 设置DBFLASHBACKTETENTION_TARGET初始化参数，指定可以闪回数据库到过去的多长时间。
下面的代码设置闪回目标为1天（1440分钟）：
SQL>ALTER db_flashback_retention_target = 1440;
d) 关闭数据库并用安装方式打开它。
如果使用的是单个实例，可简单地使用mount命令：
SQL>SHUTDOWN IMMEDIATE; SQL>STARTUP MOUNT;
e) 启用闪回数据库特性
SQL>ALTER DATABASE FLASHBACK ON;
f) 使用ALTER DATABASE OPEN命令打开数据库，然后查询V$DATABASE视图，验证闪回数据库特性已经启用：
SQL>STARTUP OPEN; SQL>SELECT FLASHBACK_ON FROM V$DATABASE;
2） 闪回数据库操作
a) 闪回数据库操作分为时间、SCN及日志序列号
方式一：时间
SQL> Flashback database to timestamp to_timestamp('09-10-14 14:37:05','yy-mm-dd
hh24:mi:ss');方式二：SCN
SQL> Flashback database to scn 947921;
方式三：日志序列号
SQL>FLASHBACK DATABASE TO SEQUENCE 12345;
b) 打开数据库
SQL> alter database open resetlogs;
另一方面，如果你对闪回数据库操作后的数据库状态不满意，可发布下面的命令撤销整个闪回操作的结果：
SQL>RECOVER DATABASE;
RECOVER DATABASE命令将应用归档重做日志中的所有更改，使数据库再次回到当前状态，进行一个完全的恢复。
如果在闪回数据库时，认为第一次返回不够，可再次执行FLASHBACK DATABASE命令，使数据库进一步返回。
如果返回太多，可使用RECOVER DATABASE UNTIL命令使数据库后退。
3. 总结
3.1 数据库被删除抛开系统安全设计的缺陷外，就是数据库的维护流程存在改进的地方，比如:
- 对于重要数据库内容的修改、删除的流程应该是什么？
- 特别是对于整个数据库的删除流程应该是什么样的？
- 仅有弹窗提示够不够？
- 系统是否有足够的验证或检测过程？
3.2 除此之外，可靠的数据备份机制是你最可靠的数据安全避风港。
