刪使用者刪表空間的操作還能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的分享。
| 作者簡介
李譽軍,沃趣科技資料庫工程師
主要參與公司產品實施、測試、維護以及優化。