使用flashback query巧妙抽取指定資料

在生產環境中存在著大量的資料，和業務是密切相關的。比如系統中的某個業務流程出現了問題，如果想復現就會顯得非常困難，甚至是不太可能的，比如電信系統中存在著大量的客戶資訊，相關聯的表的資料量都基本在千萬，億級。
如果要抽取，是全量抽取還是增量抽取。全量抽取可行，但是實際操作起來也不現實，如果要在測試環境中復現，可能需要大量的儲存空間，而且相比來說也顯得有些浪費，同事對於資料安全也是很大的隱患，畢竟我們不願意客戶資訊這麼輕易的暴露出來。
如果增量的，問題的關鍵是怎麼增量，比如從100萬客戶資訊中抽取一個客戶的資訊，按照這個要求抽取某個表的資料還是可行，但是如果很多表之間存在依賴，存在關聯，很多表抽取就會是一個很大的困擾，畢竟對於dba來說，要控制這個抽取過程而且還要兼顧業務，是很困難的。
除此之外，還有一個主要問題就是在大批量資料中，怎麼保證資料的事務一致性，比如存在表customer,subscriber，一個客戶customer下可以對應多個使用者subscriber,如果我們定位customer下的某個subscriber,這個時候，可能會有很多的事務在執行，我們需要同時保證subscriber相關的表的資料在同一個事務內是一致的。這對於抽取資料復現來說就是最基本的資料保證了。所以從抽取難度上和資料完整性上我們需要做一些工作。

其實我們可以巧妙的利用flashback query來完成這個看似不可能完成的任務。
我畫了如下的圖示進行解釋。
首先在資料來源頭的schema中存在著一些表，我們假設為table1,table2,table3...
table1,table2,....這些表之間是存在著一些對應關係的。比如customer表的customer_id和subscriber表中的customer_id是對應的。subcriber表的subscriber_id和產品訂購表是存在關聯的，這些關聯關係至關重要。
即圖中綠色的部分，這些都是一些表關係的定義，根據表中的欄位進行對映。這樣一個幾百萬資料的表根據對映關係可能就會過濾出來很少的資料來。
這個抽取的過程怎麼保證事務資料的完整性呢，這個時候就需要flashback query來完成。在抽取的時候我們會根據需要的時間戳來作為資料抽取的基準時間，所有的關聯的表都會基於這個時間戳進行抽取。
比如對於customer表，我們提供了customer_id=100
抽取customer表就會是下面的樣子。
select * from customer as of timestamp xxxxx where customer_id=100;
如果customer和subscriber的對映關係是customer_id
則抽取subscriber就是
select *from subscriber as of timestamp xxxxx where customer_id=100;
以此類推，中間的藍色柱子就代表抽取的基線時間。


如果抽取的進展順利，這些資料是能夠很快抽取抽起來的，那麼問題來了，怎麼生成dump檔案呢，這個時候我們可以考慮使用一個臨時的schema來存在這些抽取的表資料，因為抽取的資料量是很小的，所以可以考慮使用一個臨時的schema，直接在這個schema中匯出資料即可。
即圖中右半邊的temp schema。
有了臨時的schema,那麼抽取的資料是怎麼放到臨時的schema中呢，還是使用最普通的ctas
對於customer表使用
create table customer nologging as select * from customer as of timestamp xxxxx where customer_id=100;
對於subscriber表使用
create table subscriber nologging as select *from subscriber as of timestamp xxxxx where customer_id=100;
因為這個schema的臨時使用，實在找不出需要更多日誌的理由，所以可以考慮直接使用logging選項來，加快臨時表的生成速度。這樣資料就會順利在temp schema中生成，這個時候就跟鋼鐵匯入磨具已經成型了，後期的加工就更加靈活了。
在哪個測試環境需要我們就可以靈活的使用exp/expdp來匯出dump，根據需要匯入制定的環境了。
整個過程還是比較簡單的，但是其中還是有很多的細節需要注意，一個是抽取的邏輯，這個需要和開發，業務部門進行配合，把表的依賴，關聯關係確認，另外就是抽取的粒度，儘量保證抽取的粒度要小，即最好提供限定的個別id來，如果抽取的資料量大了，對於系統的負載來說也是很高，得不償失。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1707381/，如需轉載，請註明出處，否則將追究法律責任。