刪使用者刪表空間的操作還能flashback回來嗎？

有一次在某微信群裡，有人提問以下兩條操作還能恢復嗎？而且是在沒有開歸檔。緊接著 又 有人提問資料庫是否開了閃回？

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的分享。

|  作者簡介

李譽軍，沃趣科技資料庫工程師

主要參與公司產品實施、測試、維護以及最佳化。