根據時間欄位匯入資料的問題總結

在之前的博文中介紹過如何透過exchange partition,split partition達到快速的資料切換，對於上百G的大表來說，速度都在秒級完成
對於大分割槽重新分割槽來說，上面的步驟已經夠用了，但是對於資料清理來說，工作才剛剛開始，這是一種邏輯的資料清理，因為目前分割槽表中重新分割槽後沒有資料，對於歷史資料可以選擇按照分割槽邏輯使用insert append的方式進行資料匯入。
因為分割槽規則是按照時間欄位，所以在資料匯入的時候犯了一個錯誤，就是簡單使用下面的形式來匯入資料。
Insert /*+append*/ into TEST_LOG select * from LOG_CLNUP where time =to_date('20150721','YYYYMMDD');
簡單以為這種情況會吧2015年7月21日的資料匯入，但是從測試情況來說，資料量是在少得厲害，才發現其實這種情況下，預設是會使用0時0分0秒的情況。
我們把隨便一個日期進行按日期格式化，然後使用精細化的格式輸出。

SQL> select to_char(to_date('2014-10-05','yyyy-mm-dd'),'yyyy-mm-dd hh24:mi:ss') from dual;

TO_CHAR(TO_DATE('20
-------------------
2014-10-05 00:00:00
當然了，這個錯誤是一個低階錯誤，我們來看我們要做的正事。
分割槽規則是按照月份，即每個月都有一個對應的分割槽，則我們計劃使用下面的格式來插入資料。
 Insert /*+append*/ into TEST_LOG select * from LOG_CLNUP where time between to_date('20150721','YYYYMMDD')and to_date('20150722','YYYYMMDD') ;

按照這樣的邏輯應該是沒有問題的。不過還是有一定的隱患，後面會單獨說。
按照表的資料量，每天的增量資料都在百萬，千萬，所以按照天來匯入還是比較合理的，如果按照月，可能時間會很長，而且不好控制。所以按照天來進行資料匯入就需要使用動態sql。
第一個思路就是使用Pl/sql來做。比如對於表TEST_LOG我們這麼做，其實還有好幾個類似的表。方法雷同。

end loop;
end;
/

這種情況下會生成相應的語句來動態插入。
比如

我們就根據sysdate-i的方式來得到相應的日期。這種方式相對來說也能接受，不過比如你在晚上10點執行指令碼，結果過了凌晨，這個時候sysdate就會發生變化，有些日子的資料很可能就會匯入兩次。所以說這種方式也是不夠合理的。就算在當天完成，你去檢視sysdate-i的時候也不是很方便，至少我透過這個不能很快知道我要插入資料的日期。還得推算，有的月31天，有的月30天。。。
所以相對還是這種方式要好一些。
Insert /*+append*/ into TEST_LOG partition(P_2015_07) select * from LOG_CLNUP where time  between to_date('20150701','YYYYMMDD') and to_date('20150702','YYYYMMDD');
如果希望使用動態sql來完成，可以這麼做。

在絕大多數的場景裡這種資料匯入方式是沒有問題的，但是有一種場景會報下面的錯誤。比如

這個問題還是在時間戳上出了問題，因為時間戳跨分割槽了。所以在檢查的時候會有一些問題。
可以這麼改。
Insert /*+append*/ into M_START_LOG partition(P_2015_06) select * from M_START_LOG_CLNUP where time  between to_date('20150630 00:00:00','YYYYMMDD hh24:mi:ss') and to_date('20150630 23:59:59','YYYYMMDD hh24:mi:ss');
這種方式就可以了。如果希望該成這種方式也可以，指令碼變化不大，我就不列舉了。
所以透過這個透過時間戳匯入資料的案例來看，還是有不少的坑的，還是需要不斷驗證，大膽猜想，小心求證。