今天使用者說他資料庫的一條記錄不知道被什麼人給刪除了，也不知道是有人惡意破壞還是具體其它原因！

和使用者商量了一下，首先需要找到具體那個時間點被刪掉的，確定使用資料庫閃回查詢，使用的語句是select * from tablename as of scn scnnum where 查詢條件。

scn也可以換成timestamp,我們查詢下午3點05分記錄已經沒有了，查詢2點50的時候報ora-01555的錯。使用者說2點50的時候他還登陸過。現在基本可以把時間鎖定在這15分鐘。

然後開始分析當時的歸檔，希望找到資料庫都在幹什麼。直接用logmnr分析歸檔太複雜了，使用者開啟toad，裡面直接由logmnr的按鈕，選擇具體哪個歸檔，toad就開始進行分析，出來結果我們手工儲存成文字檔案，使用utraledit進行分析查詢，我們在第二個例項的一個歸檔上找到了該條語句，delete那條記錄。

查到這，知道具體的時間，具體執行的語句，我們抓了改例項主機上監聽的log，檢視沒有發現可疑的連線，然後繼續分析歸檔日誌裡面執行該語句前後資料庫執行的其他語句，沒有發現可疑的語句，基本判斷不是有人惡意破壞，有發現上面有一條類似的語句，也是刪除一條記錄，兩個刪除時間基本挨著，有相同的條件關聯。使用者開始分析具體的應用程式，最後結論是程式的一個bug。

以前對閃回一知半解。又檢視了具體的資料，尤其是閃回查詢報ora-01555回滾段的錯，他使用回滾段，那flash_recover_area用來儲存什麼，那個裡面設定的db_flashback_retention_target的值又是管幹啥的呢，回收站又是幹啥的，儲存在在哪了呢。

回來看看相關的資料，理解如下,flashback在10g中得到加強，分為三種型別的閃回，第一種是database的閃回，這使用的是flashbacklog，該log儲存在flash_recover_area區裡面，想要實現資料庫的閃回，media錯誤是不行的，資料庫也必須事先開啟flash

資料庫的閃回

相關文章