資料庫閃回技術在Oracle Database 10g就向大家提供了。因為閃回不需要對資料檔案做restore的動作，是以資料恢複的時間相比傳統RMAN進行恢複要快許多。這項技術一直受到DBA的喜歡，比如經常可以使用表閃回，資料庫閃回快速修複人為造成的資料錯誤，也可以使用閃回查詢，了解記錄之前的狀态。但閃回技術不是萬能的，它也受到許多限制，但随着資料庫版本的不斷更新，閃回功能在各個版本都得到了增強。
我們假設這樣的場景：今天是周三，我們發現某個PDB的資料出現人為錯誤，然後将這個PDB通過資料庫閃回技術，将資料庫閃回到周一，并使用resetlogs的方式打開這個PDB。閃回操作執行完成後，發現閃回的時間是錯誤的，不應該将這個PDB閃回到周一，而是應該閃回到周二。在Oracle Database 20c之前，如果出現上面的情況，恐怕就要使用其他技術對這個PDB進行恢複了。這也是為什麼，我們在使用閃回資料庫技術之前，我們先要進行查詢，确定正确的閃回時間點，否則就會出現如上圖所示，已經閃回到周一，再想閃回到周二就不可以了。
從20c開始，PDB的閃回功能得到了增強，即便是從周三閃回到了周一，也支援從周三閃回到周二。
接下來我們就通過實驗來驗證一下。
使用這項技術有三個前提條件：
1、資料庫啟動歸檔
2、資料庫開啟閃回
3、使用local undo
我們還是使用之前實驗中所使用的Database 20c當中的pdb，名字為pdb1。假設我們在周一的時候，hr使用者下面有一個table，名字為fb_tab1，裡面有1000條記錄。
然後建立一個restore point名字叫做rp001。
接下來，我們向這個表中添加1000條記錄，認為是周二的資料情況，然後建立restore point名字為rp002。
使用同樣的方法，建立出周三的資料，然後建立restore point名字為rp003。
接下來，我們将PDB1關閉，然後閃回到第一個restore point：rp001，然後将資料庫以resetlogs方式打開。我們通過觀察，發現資料表中的記錄恢複到了1000條。
然後，我們再将資料庫PDB1，閃回到第二個restore point：rp002，這項操作在之前的版本中是不支援的，而從20c開始提供了很好的支援。我們看到資料表中的資料已經恢複到了restore point：rp002的狀态，有2000條資料。
如果您願意，可以将資料庫閃回到第三個restore point，這項操作在之前也是不支援的，而在20c當中是沒有問題的。
在20c當中，PDB還有好多新的特性，請您參考官方文檔擷取更多資訊。