删用户删表空间的操作还能flashback回来吗？

青旅半醒 2022-05-08 00:28 79阅读 0赞

有一次在某微信群里，有人提问以下两条操作还能恢复吗？而且是在没有开归档。紧接着又有人提问数据库是否开了闪回？

drop user aaa cascade;
    drop tablespace asd including contents and datafiles;

PS：他这里没有指明闪回是闪回查询？闪回表？闪回数据库？那我们就从一个不了解闪回特性的角度来一一看这个问题（这里假设是这个用户下就一张表）

**下面是整个分析过程：**

**场景一、闪回查询**

SQL> create table aaa.a1(id number);
    
    Table created.
    
    SQL> insert into aaa.a1 values(3);
    
    1 row created.
    
    SQL> commit;
    
    Commit complete.
    
    SQL> select dbms_flashback.get_system_change_number from dual;
    
    GET_SYSTEM_CHANGE_NUMBER
    ------------------------
    
    3575965
    
    SQL> drop user aaa cascade;
    
    User dropped.
    
    SQL> select * from aaa.a1 as of scn 3575965;
    
    select * from aaa.a1 as of scn 3575965
                 *
    ERROR at line 1:
    ORA-00942: table or view does not exist

可以看出闪回查询是无效的，其实你要是懂一点闪回查询首先可以排除掉，因为闪回查询是基于undo的，而且undo受ddl影响的，drop操作并不会使用到undo表空间，所以基于undo的闪回查询在这种场景并不能找回数据。

**场景二、闪回表（flashback table）**

SQL> flashback table aaa.a1 to before drop;
    
    flashback table aaa.a1 to before drop
    *
    ERROR at line 1:
    ORA-01435: user does not exist

drop user cascade并不会把表放入回收站的，那么我们再怎么执行flashback table也是于事无补。

最后我们再来尝试一下闪回数据库，看看它是否能够成为救命稻草。其实闪回数据库的前提条件就是开启归档，那么抱歉这条路也行不通。

假设现在开了闪回数据库（flashback database，当然包括开启归档），那么我们误删的数据一定就能被找回吗？

**场景三、闪回数据库（一）**

SQL> select dbms_flashback.get_system_change_number from dual;
    
    GET_SYSTEM_CHANGE_NUMBER
    ------------------------
    
    3574600
    
    SQL> drop user aaa cascade;
    
    User dropped.
    
    SQL> drop tablespace asd including contents and datafiles;
    
    Tablespace dropped.
    
    SQL> shutdown immediate;
    
    Database closed.
    
    Database dismounted.
    
    ORACLE instance shut down.
    
    SQL> startup mount;
    
    ORACLE instance started.
    
    Total System Global Area  889389056 bytes
    Fixed Size    2258360 bytes
    Variable Size  574622280 bytes
    Database Buffers  306184192 bytes
    Redo Buffers    6324224 bytes
    Database mounted.
    
    SQL> flashback database to scn 3574600;    //闪回到误操作前
    
    Flashback complete.
    
    SQL> alter database open read only;  //以read only模式打开
    
    Database altered.
    
    SQL> select * from aaa.a1;
    select * from aaa.a1
                  *
    ERROR at line 1:
    ORA-00376: file 10 cannot be read at this time
    ORA-01111: name for data file 10 is unknown - rename to correct file
    ORA-01110: data file 10: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00010'

这里说明一下闪回数据库的原理：flashbackdatabase用来将数据库中的数据恢复到之前的某个时间点，而非介质恢复。这里的 drop tablespace  including contents and datafiles（使用including datafile效果都相同），会将对应的数据文件删除。所以现在即便是开启了闪回数据库特性也无济于事。

那么要是在上面的情况下，我只执行了drop usercascade命令，而没有执行drop tablespace  including datafile（在闪回数据库模式下），结果又会有什么不同呢？

**场景四、闪回数据库（二）**

SQL> select dbms_flashback.get_system_change_number from dual;
    
    GET_SYSTEM_CHANGE_NUMBER
    ------------------------
    3581891
    
    SQL> drop user db1 cascade;
    
    User dropped.
    
    SQL> shutdown immediate;
    
    Database closed.
    
    Database dismounted.
    ORACLE instance shut down.
    SQL> startup mount;
    ORACLE instance started.
    Total System Global Area  889389056 bytes
    Fixed Size    2258360 bytes
    Variable Size  574622280 bytes
    Database Buffers  306184192 bytes
    Redo Buffers    6324224 bytes
    Database mounted.
    
    SQL> flashback database to scn 3581891;
    
    Flashback complete.
    
    SQL> alter database open read  only;
    
    Database altered.
    
    SQL> select * from db1.milktwo;
    
    ID           NAME
    ---------- ----------------------
    33 kk
    2 hh

总结，闪回数据库（flashbackdatabase）特性开启的情况下，如果我们只是做了drop user删除用户数据而没有删除datafile，那么我们就可以使用flashback database恢复数据，不同场景使用不同的闪回恢复技术，希望我的分享能够帮助到你。如果感兴趣可以期待下次drop tablespace  includingdatafile的分享。

### **|  作者简介** ###

**李誉军，沃趣科技数据库工程师**

主要参与公司产品实施、测试、维护以及优化。