有一次在某微信群里,有人提问以下两条操作还能恢复吗?而且是在没有开归档。紧接着又有人提问数据库是否开了闪回?
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的分享。
李誉军,沃趣科技数据库工程师
主要参与公司产品实施、测试、维护以及优化。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。