在bw中，存在兩種資料抽取方式，完全更新與增量更新，完全更新是每次把截至到某個時間的資料全部抽取，增量抽取則只抽取上次和本次抽取之間更新的資料，很顯然，增量抽取能夠提高系統效率，根據sap幫 助的說法，增量更新又分為時間戳和增量佇列兩種方法，其中財務資料的抽取為時間戳增量法，後勤資料的抽取為增強佇列法。對於增量更新，都需要先對資料抽取 進行初始化，然後再進行增量的抽取。對於時間戳增量法，系統存在乙個延遲時間，即時間戳設定時間與記賬時間的差異，比如時間戳是根據建立時間（或輸入時 間）來確定是否更新的依據，而在抽取開始時（時間戳已標記），此時憑證已建立而未記賬（即未更新至資料庫），則此次無法抽取到該憑證，但下次抽取時，由於 已在時間戳範圍之外，也不再進行抽取，從而導致抽取資料遺漏，避免此問題，sap幫助上給出了通過設定安全抽取時間的方法，設定檢視為bwom2_v_safety， 可根據不同的資料來源設定不同的安全時間，兩個小時為推薦設定，我的理解是這個安全時間是對於已經建立但未儲存在憑證而言，如果在這個安全時間內儲存了，則 此次抽取將包含在內，那時間戳標記會改變嗎？如時間戳標記不變，則在安全時間內抽取不能結束，需一直等待憑證儲存然後抽取？未進行測試，不知這樣理解是否 正確。有的人會說，既然這樣，何不根據記賬時間來標記時間戳，我想如果根據記賬日期，則增量更新問題更大，因為有的時候經常在下月往上月記賬（財務正常結 帳是這樣的），如果根據記賬日期判斷，則遺漏資料更多。財務上的時間戳標記表為bwom2_timest，其中ts_low和ts_high欄位為兩次更新之間的時間差，修改憑證日期表則為bwfi_aedat。後勤資料抽取相關的t_code有lbwg/lbwe/lbwq/rsa7等，後勤資料是先儲存在r3端，然後再抽取到bw中的。
舉個例子：
比如你6小時抽取一次資料，假如你第一次在12:00抽取，那麼下次應該是18:00抽取，那麼應該來說18:00抽取的資料是 12:00-18:00的資料才對，但是有種情況需要你考慮，比如我11:55在做乙個憑證，但是中間我去吃飯，12:30才回來完成這個憑證，那麼這個 憑證就是11:55建立的，在12:00抽取的時候，由於憑證沒有產生，因此無法抽取，但是下次18:00抽取的時候，由於這個憑證是在11:55建立 的，所以也無法抽取到。
做bw資料倉儲最重要的一條準則就是「不重複、不遺漏」，那麼這樣你就遺漏了資料，那麼sap就想了個辦法，就是比如這次我抽取從 06:00-12:00，那麼下次我抽取從11:30-18:00，這樣上面的憑證就能抽取出來了吧，這時候11:30-12:00就有半個小時的重複， 這個就叫做lower limit。
同上，比如我12:00抽取的時候，不想抽取06:00-12:00，而是想抽取06:00-11:30，那麼我就設定乙個higher limit 為30分鐘，則抽取的時候就不會到最新的時間，而是需要過賬半小時前的憑證。
比如我設定了30分鐘的lower limit，30分鐘的higher limit，那麼我12:00抽取的資料應該是05:00-11:30的資料，下次抽取的資料時11:00-17:30,在下次就是 17:00-23:30，在下次就是23:00-05:30，在下次就是05:00-11:30，如此迴圈。
但是如果設定了lower limit和higher limit之後，請記得在bw中使用dso來處理資料。
關於kettle時間戳增量更新
之前看到的一篇文章kettle實現資料實時增量同步，這位大佬提出了時間戳增量回滾同步的一種方式，我是根據這篇文章之上進行探索的。但是遇到了一些問題，這裡進行一下記錄 只能同步往前 day這段時間內的刪除操作，因為回滾了一段時間 day，作者也宣告了這點 也只能同步往前 day這段時間內的刪除操作，為...
時間戳實現增量資料同步
資料同步 1 靠記錄中本身的時間戳來增量更新 分頁獲取必須排序 時間戳 排序後也會出錯 會出現記錄跳過的情況 中途指令碼停止更是會出錯 非分頁的會出問題，指令碼中斷更會出問題 時間戳不能保證是從低到高 解決方法 1 分頁條數為1 並排序但效率不高 2 分頁採用每次獲取比當前時間戳大的的limit條數...
mysql增量抽取方法 增量抽取 時間戳方式實現
時間戳方式抽取資料 介紹 它是一種基於快照比較的變化資料捕獲方式，在源表上增加乙個時間戳字段，系統中更新修改表資料的時候，同時修改時間戳字段的值。當進行資料抽取時，通過比較上次 抽取時間與時間戳字段的值來決定抽取那些資料。有的資料庫的時間戳支援自動更新，即表的其他欄位的資料發生變化時，自動更新時間戳...