又鸽了一个月，没有记录就没有发生，还是记录下。

今天遇到同事执行了drop user xxx cascade，没错，是在生产环境。

首先我看到这个，心里有点慌，但是后来一想，既然能执行成功，说明当前这个用户并没有连接，如果有连接是删除不成功的，即使你添加了 cascade 参数，那就说明这个用户很大概率是不用的用户了，再 看他执行的SQL 是从一个 YYYYMMDDxxxx-注销用户的文本里复制的，这是他之前做过的单子的记录，他要复制删除用户的语句，然后一不小心复制了这个语句在没有修改用户名的情况下并且执行了。

从这两个迹象来看，我感觉他可能看错了，我让他再确认一下，库以及用户等信息。最后还是确认是在错误的库中执行的。

先从技术角度来说下，刚开始我看到执行成功了，说明用户当时没有连到库里，这可能是个不用的用户。周围的同事说加了 cascade 是可以强制删除的，这个时候我头有点大，让联系公司二线，我在这边测试环境新建用户进行测试下：

1
2
3
4
5
6
7
8
sys@ARMDB 17:00:30>  drop user f008 cascade;
 drop user f008 cascade
*
ERROR at line 1:
ORA-01940: cannot drop a user that is currently connected


Elapsed: 00:00:00.05

经过测试，如果用户当前正连在数据库上，即使使用 cascade参数也是无法删除的，我这里松了一口气，这时公司二线也回来了，他三下五除二，经过一番查询，确认这个用户确实没有登录，最重要的是这个用户下没有对象。这里先暂时重新创建用户解决。

现在说下，用户已经drop了，二线是如何确认的上面的信息呢。原来他是通过 闪回查询确认的，这个方法确实秒，不愧为二线。

1
2
3
4
create table xxx.user$ as select * from sys.user$ as of timestamp sysdate-1/24;
create table xxx.obj$ as select * from sys.obj$ as of timestamp sysdate-1/24;
select * from xxx.user$ where NAME='XXXXXX';
select * from xxx.obj$ where OWNER#=xxxx;

经过查询，确认删除的用户下没有对象，心里舒了一口气。

这里说下，如果删除的用户下有对象该如何常规恢复。

这里说下常规恢复了，不常规恢复不太了解。

1、首先想到的是闪回，如果开启了闪回，可以闪回道drop之前的时间点，但是代价较大，通常没开闪回，闪回数据库是整体闪回，通常是不可能这样操作的。

2、就是通过备份来恢复，前提是有有效的备份，最好是expdp逻辑导出的，如果是rman 和归档来恢复，可能稍微麻烦一些，expdp逻辑导出可能会丢失备份到操作直接的数据。总之，不管怎么恢复都代价很大，可能丢失数据。业务中断肯定是不可避免的了。

记录之：要对生产环境有敬畏之心，一定要清楚自己的操作。。

原文作者: liups.com

原文链接: http://liups.cn/posts/34edc9e2/

许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议