記一次資料恢復

記一次資料恢復

同事不小心把生產的一個表truncate了，匆忙來找我想解決辦法。
一開始想到了用helldba站點的兄弟寫的truncate恢復辦法，但之前實際操作過，太複雜，要建表空間，還要很多許可權。
手忙腳亂了一下後，冷靜下來一想，還有個老耿寫的gdul工具，有恢復truncate的資料的選項。於是趕緊上傳工具，然後安裝。

安裝過程需要sys密碼。

下面是操作過程：
1、先bootstrap初始化
2、看下錶資料所在的表空間的ts#：info
3、掃描表表空間：scan tablespace [ts#]
4、同事說這個表被truncate過幾次，所以用下面這個命令無法直接恢復：untrunc table [user].[table_name]
5、改用drop表的恢復方式：先對錶空間取樣：sample segment all；然後unload表：unload table [user].[table_name] object_id [data_object_id]
   但是在找data_object_id上發生了問題----這個表空間下有幾百個表，
   也就是sample出來的檔案有幾百個，如何能找到那個檔案呢？如何快速的定位到我們要恢復的那個表的data_object_id呢？
   我把所有dict檔案cat到一個檔案中，然後用欄位型別為date來篩選，結果發現大部分表都有這個date型別，無法高效的篩選出想要的表。
   然後，想到用date型別結合欄位數來匹配查，發現還是太多，找起來太慢。在找的過程中，突然靈光一現，何不用col0032（這個表的欄位數）來匹配，
   因為欄位名命名都有規律，都是按COL+4位數字（不足左側0補足）來編號的，所以。。。。。就很快找到了。
4、然後unload table [user].[table_name] object_id 12345
5、按照匯出的dmp檔案，匯入到庫中，資料恢復完成。

對於這次恢復，非常感謝老耿寫的這個工具，可操作性和使用性非常好。
另外，對這個工具，我也有一些建議。當恢復的時效性要求非常高時，對於表空間中資料物件比較多的情況下，
如何“快速”的定位到所要恢復的資料物件id非常重要。我覺得可以提供一個命令，列出所有資料物件的id和欄位數（同我分析檔案的過程一樣），以便檢視。