1、增量管理標準數(shù)據(jù)源增量增量管理是向數(shù)據(jù)倉庫提供數(shù)據(jù)時所必需的，其作用在于及時加載數(shù)據(jù)倉庫的源系統(tǒng)中更改的數(shù)據(jù)，以及把需要傳輸?shù)綌?shù)據(jù)倉庫的數(shù)據(jù)縮小到最相關的數(shù)據(jù)范圍。此外，增量管理將有助于您對各自應用程序更改數(shù)據(jù)的訪問，在某些情況下，還將使您第一時間獲取這些數(shù)據(jù)。下圖說明了哪些BI 源系統(tǒng)類型支持增量管理。增量管理意味著能夠在單個數(shù)據(jù)請求中只將新建、已更改的數(shù)據(jù)記錄提取到BI 系統(tǒng)中。從技術角度而言，這表示請求DataSource 的“增量更新”。標有“DQ” = 增量隊列的表表明由增量隊列使用的源系統(tǒng)暫時儲存新建、已更改的數(shù)據(jù)記錄（下面再做詳細解釋）。增量隊列是SAP 源系統(tǒng)中用于增量記錄（即

2、新記錄和已更改的記錄）的臨時中央資源庫。BI 增量隊列基于SAP Web 應用程序服務器(qRFC) RFC 技術中的隊列功能。Delta增量管理分為（看下圖）： 對標準SAP數(shù)據(jù)源增量 對LO后勤數(shù)據(jù)增量 對其他數(shù)據(jù)源增量，如文件等既然我們要對數(shù)據(jù)進行增量，那么首先就應該找到存放數(shù)據(jù)的數(shù)據(jù)源，也就是說要找到一個數(shù)據(jù)源的目錄，也就是下面第一個表。詳細查看所有字段可輸入T-Code SE11，在輸入下面表名稱查看詳細信息）。 ) R- T7 s i) w NROOSOURCE表：定義了每個數(shù)據(jù)源的基本屬性。下面我們先來分析一下這個表，這里我們只分析一些重要的字段。 TYPE（表示數(shù)據(jù)源的類型）

3、EXMETHOD：Extraction Method(抽取方法) TFMETHODS：Transfer Methods(傳輸方法) ZDD_ABLE字段表示是否支持“早期增量初始化”，這個表示在初始化時候是否繼續(xù)收集增量； DETLA(Delta Process for a DataSource) （這個字段很重要）增量流程是指數(shù)據(jù)的傳輸過程。它指定如何在BI中確定數(shù)據(jù)目標的數(shù)據(jù)。例如，這使您能設計出DataSource 適合的數(shù)據(jù)目標、更新方法以及序列化的完成方法從上圖可以看到它有20種增量流程，我們接著開始了解下一些重要的增量流程。增量過程字段都存儲在下面這個表中。 RODELTAM表：定

4、義了每種增量提取方式的方法，這里的增量過程表也是需要講解一些重要字段，方便對增量有更深入和全方位的了解。（下面圖中的X表示Yes的意思，“ ”空表示NO）下圖是每個字段的解釋（看不懂沒關系，后面會有更深入的介紹）。好的我們繼續(xù)介紹幾種重要的增量流程方法的詳細含義：ABR采用前鏡像、后鏡像和反轉鏡像的更新模式，既支持覆蓋又支持累加，所以數(shù)據(jù)源可以更新到DSO或者CUBE；AIE 采用后鏡像模式，只支持覆蓋，不支持累加，所以該類型數(shù)據(jù)源不能直接加載到CUBE，一般會先加載到DSO; 在FI-AR/AP中此種增量處理方式應用較多；ADD只支持累加，采用的是附加鏡像的更新方式，所以既可以更新到DSO又

5、可以更新到CUBE。一般來說：CO的數(shù)據(jù)源都是ADD的，差額鏡像，E FI的基本都是AIE，后鏡像，E LO的基本都是ABR，這個就不用說了，很明細，新、前、后、翻轉的鏡像都存，量很大，D 自建的默認是AIE，同F(xiàn)I（BT的是沒有提供更改方法，所以自建的統(tǒng)一都是AIE），E 主數(shù)據(jù)的一般采用AIE、AIM和NEWE，說明比較側重結果和新增數(shù)據(jù)。Generic Delta 通用增量流程服務如果需要，您也可以集成“通用DataSource” 的增量流程。但是，需要符合某些前提條件。必須具有一種確認已傳輸數(shù)據(jù)記錄的方式，以便能夠確定增量。也就是說怎么去判斷記錄是增量產生的。一般來說非后勤和主數(shù)據(jù)還有

6、自建的數(shù)據(jù)源都是Generic Delta。輸入T-Code“RSO2”進入數(shù)據(jù)源管理，如果要使用“通用增量流程”，點擊下圖中紅圈按鈕。進入下圖界面：這個界面是做什么用的哪？這里就是前面說的設置判斷數(shù)據(jù)是否為增量數(shù)據(jù)的地方。 有四中字段類型來選擇：1 Time stamp (UTC) 世界通用時間2 Time stamp (Local) 本地時間3 Calendar Day 日歷日4 Numeric Pointer 數(shù)字指針（例如憑證編號等） 設置增量選擇的安全間隔上下限安全間隔上限如果此值為初始值，則存在提取期間產生的記錄無法提取的危險。示例：使用時戳指定增量。上次讀取的時戳是12:00:0

7、0。下次增量提取從12:30:00 開始。因此，選擇間隔從12:00:00 到12:30:00。提取結束時，計數(shù)器設置為12:30:00。比如文檔記錄的創(chuàng)建時間是12:25，保存時間是12:35。此記錄不包括在已提取數(shù)據(jù)范圍之內，但下次由于記錄的時戳，也不提取此記錄。為此，讀取和傳輸數(shù)據(jù)之間的安全間隔應總是大于為此DataSource（為時戳增量）創(chuàng)建記錄所需的最大時間范圍，或應該是足夠大的數(shù)據(jù)間隔（使用連續(xù)的數(shù)字指定增量）。安全間隔下限此字段包括必須從上次增量提取的最大值進行提取的值，以確定下次增量提取的時戳下限。示例：使用時戳指定增量。提取的數(shù)據(jù)為主數(shù)據(jù)：僅傳輸后像，覆蓋BI 中的狀態(tài)。對

8、于此類數(shù)據(jù)，記錄可能提取到BI 兩次而不會出現(xiàn)問題?？紤]到這一情況，總是將當前時戳用作提取期間的上限：然后，下次提取的下限不會無縫連接到上次提取的上限。然而，它接受與此上限減去安全間隔相符合的值。此安全間隔必須足夠大，以便提取可以包含上次提取時已經收到時戳但未讀取的所有值。當然，記錄或許可以傳輸兩次，但這不會因上述原因而帶來任何影響。 也可以選擇增量的類型，如New Status for Changed Reocrds(適合DSO和Cube), Additive Delta（適合DSO）.同事我們也可以查看設置增量的隊列狀態(tài)信息。RSA7進入增量隊列管理，如下圖上面穿插的介紹了通用數(shù)據(jù)源的增量

9、方法。下面接著講解標準數(shù)據(jù)源的參數(shù)。我們接著RODELTAM表其他字段來講解。增量類型字段(RODELTAM-DELTATYPE) 是增量流程的屬性。它描述了如何在增量流程中加載增量。以下特性值是允許的： : 未定義增量類型。 A:DataSource 使用ALE 更新指針確定增量。此方法主要與DataSource 結合使用，用于SAP 源系統(tǒng)的屬性和文本中。它也用于使通用DataSource 能夠提供增量值（提供基礎主數(shù)據(jù)表支持通用DataSource）。主數(shù)據(jù)的ALE 更新指針已經提供了很多年。在過去，它們用于協(xié)調SAP 系統(tǒng)外的主數(shù)據(jù)。 D:SAP 應用程序將增量數(shù)據(jù)記錄直接寫入至Dat

10、aSource 的增量隊列（“推送”）。每條數(shù)據(jù)記錄a) 在保存/更新應用程序的相應事務時單獨儲存在增量隊列中（例如，F(xiàn)I-AR/AP 或LO Cockpit 中的直接增量） b) 通過應用程序特定的作業(yè)寫入至增量隊列的增量數(shù)據(jù)記錄組中（在更新事務后）。但是，在每一種情況下，增量數(shù)據(jù)記錄在執(zhí)行增量更新前仍然是SAP 源系統(tǒng)增量隊列中的記錄。如果是DataSource 增量更新，則讀取此增量隊列，并將增量隊列中的數(shù)據(jù)記錄傳輸?shù)紹I 系統(tǒng)。此增量類型通常用于通過字段或控制表無法為基礎應用程序表確定增量數(shù)據(jù)記錄的應用程序中。 E:DataSource 在請求時通過提取器確定增量。這表示請求時提取器必

11、須能夠為DataSource 提供增量記錄（“拉取”）。提取器將已經確定的增量數(shù)據(jù)記錄放在增量隊列中，然后再從增量隊列中傳輸?shù)秸埱蟮腂I 目標系統(tǒng)。如果已經為多個BI 系統(tǒng)執(zhí)行了增量初始化，或為同個BI 系統(tǒng)執(zhí)行了多次增量初始化，則提取器必須加載所有增量初始化的增量記錄，并將增量記錄保存在特定于BI 目標系統(tǒng)的所有增量隊列中。此增量類型通常用于通過字段或控制表能夠為基礎應用程序表確定增量數(shù)據(jù)記錄的應用程序中（例如，每個增量記錄的時戳信息）。 F:通過平面文件加載增量數(shù)據(jù)記錄。這種增量類型僅用于平面文件源系統(tǒng)的DataSource 中。在執(zhí)行InfoPackage 時，將平面文件導入到PSA。然

12、后開始數(shù)據(jù)加載流程。這里不使用增量隊列。這里再穿插介紹下平面文件的增量流程。重要的Delta Type： D Generic Delta for Service API - PUSH方式 E Extractor Delivers OLTP Source Delta - PULL 方式序列化請求DREQSER字段。下圖是是增量流程中的序列化請求的3種方式。1 無序列化。2 對請求序列化。3 對數(shù)據(jù)包的序列化。通過上面學習我們知道了： 一個數(shù)據(jù)源支持什么樣的增量更新； 數(shù)據(jù)能更新到什么樣的對象中； 增量更新的類型和序列化方式；我們來簡單列一下增量提取的操作步驟：1 分析要提取的數(shù)據(jù)源（RSO2），

13、然后查看其是否可以做Delta，它的增量流程用哪個，增量類型用哪個，增量怎樣序列化。2 到BI數(shù)據(jù)源（RSA1）進行復制數(shù)據(jù)源。3 創(chuàng)建InfoPackage，對其進行增量參數(shù)選擇，要匹配在R/3數(shù)據(jù)源端的配置。4 然后抽取數(shù)據(jù)到對應的DSO或者Cube中?，F(xiàn)在記錄模式描述了數(shù)據(jù)記錄包含的更改類型。各種增量流程間的差異是每個增量流程僅支持七個可能特性值的子集。如果DataSource 實施的增量流程使用多個特性值，則字段ROCANCEL（保存記錄模式）自動成為此DataSource 的一部分。DataSource 的此字段會分配到BI 系統(tǒng)的InfoObject 0RECORDMODE 中。特

14、性值如下： : 記錄提供后像。在更改記錄或添加數(shù)據(jù)后傳輸記錄狀態(tài)。只有在請求相應的前像時，才會將記錄直接更新到InfoCube（稍后解釋）。 X:記錄提供前像。在更改或刪除記錄前傳輸記錄狀態(tài)。所有可以匯總（關鍵值）的記錄屬性必須用加/減沖銷符號進行傳輸。沖銷加/減符號由提取器（缺省）或服務Service API 負責。這些記錄在DataStore 對象的非附加（覆蓋）更新中予以忽略。前像補充后像。 A:記錄提供附加圖像。如果屬性可以集合，則僅傳輸更改。如果屬性無法集合，則傳輸數(shù)據(jù)更改或創(chuàng)建后的狀態(tài)。記錄可以無限制地更新到InfoCube，但需要對DataStore 對象進行附加更新。 D:記錄

15、必須刪除。僅傳輸代碼。此記錄只能更新到DataSource 對象（因此DataStore也只能更新到DataSource 對象）。 R:記錄提供倒像。此記錄的內容與前像相同。唯一的區(qū)別是更新DataStore 對象時：刪除代碼相同的現(xiàn)有記錄。 N:記錄提供新像。此記錄的內容與沒有前像的后像相同。創(chuàng)建記錄時，應傳輸新像而不是后像。新像補充倒像。在表RODELTAM中，可以確定增量更新（列UPDM_NIM、UPDM_BIM、UPDM_AIM、UPDM_ADD UPDM_DEL 和UPDM_RIM）所使用的特性值。該表必須確保增量流程中只使用上述有用的特性值組合。在以“增量更新”模式提取數(shù)據(jù)時，使用

16、增量流程的DataSource 僅為記錄模式提供增量流程中指定的、已提取記錄的特性值。文件增量流程如果增量流程使用平面文件，數(shù)據(jù)不會通過增量隊列傳輸?shù)紹I。而是直接從DataSource 加載到PSA。在此平面文件DataSource 的傳輸規(guī)則中設置的增量流程必須得到關于基本數(shù)據(jù)和其增量屬性的通知。FIL0 增量數(shù)據(jù)（后像）FIL1 增量數(shù)據(jù)（增量圖像）LO增量流程LIS的更新方法(早期更新方法)：同步更新（V1）：DELTA隊列與憑證同步更新，如果DELTA隊列寫入出現(xiàn)錯誤，那么憑證也被取消。異步修改（V2）：與V1相比，寫入DELTA若出現(xiàn)錯誤，不對憑證的保存產生影響。 異步收集更新（V

17、3）：與做憑證沒有關系。在后臺定義一程序，定時運行，收集產生變化的數(shù)據(jù)到DELTA隊列。知道了早期3種更新模式后，再來看LBWE中的幾種增量模式：Direct Delta:這就是一種V1模式，數(shù)據(jù)同步更新到增量隊列，這種模式系統(tǒng)負荷很重，特別是對于業(yè)務量大的憑證；這是一種V1，直接V1到Delta Queue，我們目前的LO數(shù)據(jù)源統(tǒng)統(tǒng)采用這個；“直接增量”的好處與屬性： 通過在V1 過帳流程中寫入增量隊列，使用應用程序的排隊概念來保證按憑證進行的序列化。 對于憑證較少的客戶，如果在重組期間的初始化流程和增量初始化請求中出現(xiàn)停機時間，則建議采用該流程。 此流程會比V3 或“隊列化增量”更加重V1

18、 的負擔。對于具有上述憑證數(shù)量的客戶，這實際上并不是一個因素。 提取與V2 更新無關。 對更新數(shù)據(jù)或提取隊列進行其他監(jiān)控是沒有必要的。Queued Delta：類似于V3的更新模式，與V3更新的區(qū)別在于，數(shù)據(jù)先被收集到一個抽取隊列中（V1模式），然后被送到增量隊列（V3模式）。Queue Delta:這是一種混合型，先V1到Extraction Queue，后V3到Delta Queue；借助于此更新模式，在提取隊列中收集受影響應用程序中的提取數(shù)據(jù)，而不是在更新數(shù)據(jù)中收集，并且可以將這些提取數(shù)據(jù)通過更新集中運行以類似于V3 更新的方式傳輸?shù)皆隽筷犃?。根?jù)應用程序，可以將多達10,000 次的憑證增量提取集中到每DataSource 增量隊列中的LUW。“隊列化增量”的好處和屬性： 通過在V1 更新流程中寫入提取隊列，使用應用程序的排隊概念來確保按憑證進行的序列化。 由于在定期處理（SAP 建議每小時執(zhí)行一次）的提取隊列中收集數(shù)據(jù)，所以特別建議憑證數(shù)量很多的客戶采用該流程。 收集運行使用與以前相同的報告(RMBWV311,.)。 在初始化過程中，在增量初始化請求過程中收集新憑證數(shù)據(jù)會減