數據庫中刪用戶刪表空間的操作還能恢復嗎

這篇文章主要講解了“數據庫中刪用戶刪表空間的操作還能恢復嗎”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“數據庫中刪用戶刪表空間的操作還能恢復嗎”吧！

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

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

感謝各位的閱讀，以上就是“數據庫中刪用戶刪表空間的操作還能恢復嗎”的內容了，經過本文的學習后，相信大家對數據庫中刪用戶刪表空間的操作還能恢復嗎這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！