數(shù)據(jù)庫中刪用戶刪表空間的操作還能恢復嗎

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

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

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

PS：他這里沒有指明閃回是閃回查詢？閃回表？閃回數(shù)據(jù)庫？那我們就從一個不了解閃回特性的角度來一一看這個問題（這里假設是這個用戶下就一張表）

下面是整個分析過程：

場景一、閃回查詢

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的閃回查詢在這種場景并不能找回數(shù)據(jù)。

場景二、閃回表（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并不會把表放入回收站的，那么我們再怎么執(zhí)行flashback table也是于事無補。

最后我們再來嘗試一下閃回數(shù)據(jù)庫，看看它是否能夠成為救命稻草。其實閃回數(shù)據(jù)庫的前提條件就是開啟歸檔，那么抱歉這條路也行不通。

假設現(xiàn)在開了閃回數(shù)據(jù)庫（flashback database，當然包括開啟歸檔），那么我們誤刪的數(shù)據(jù)一定就能被找回嗎？

場景三、閃回數(shù)據(jù)庫（一）

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'

這里說明一下閃回數(shù)據(jù)庫的原理：flashbackdatabase用來將數(shù)據(jù)庫中的數(shù)據(jù)恢復到之前的某個時間點，而非介質恢復。這里的 drop tablespace  including contents and datafiles（使用including datafile效果都相同），會將對應的數(shù)據(jù)文件刪除。所以現(xiàn)在即便是開啟了閃回數(shù)據(jù)庫特性也無濟于事。

那么要是在上面的情況下，我只執(zhí)行了drop usercascade命令，而沒有執(zhí)行drop tablespace  including datafile（在閃回數(shù)據(jù)庫模式下），結果又會有什么不同呢？

場景四、閃回數(shù)據(jù)庫（二）

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

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