SAP 資料擷取的效能和疑難排解
本文是「SAP 擴充及創新資料:最佳做法」文章系列中的一部分。
有許多方式可以連線到 SAP 系統以進行資料整合。 下列各節說明一般和連接器特定的考慮和建議。
效能
請務必設定來源和目標的最佳設定,以便在資料擷取和處理期間達到最佳效能。
一般考量
- 請確定已針對最大並行連線設定正確的 SAP 參數。
- 請考慮使用 SAP 群組登入類型來提升效能和負載分佈。
- 請確定自我裝載整合執行時間 (SHIR) 虛擬機器的大小適當且具有高可用性。
- 當您使用大型資料集時,請檢查您使用的連接器是否提供資料分割功能。 許多 SAP 連接器都支援分割和平行處理功能,以加速資料載入。 當您使用此方法時,資料會封裝成較小的區塊,可使用數個平行進程載入。 如需詳細資訊,請參閱連接器特定檔。
一般建議
使用 SAP 交易 RZ12 修改最大並行連線的值。
RFC 的 SAP 參數 - RZ12:下列參數可以限制一位使用者或一個應用程式允許的 RFC 呼叫數目,因此請確定此限制不會造成瓶頸。
使用登入群組連線至 SAP:SHIR (自我裝載整合執行時間) 應該使用 SAP 登入群組 (透過訊息伺服器) 連線到 SAP,而不是特定應用程式伺服器,以確保工作負載分散到所有可用的應用程式伺服器。
注意
資料流程 Spark 叢集和 SHIR 功能強大。 許多內部 SAP 複製活動,例如 16,可以觸發和執行。 但是,如果 SAP 伺服器的並行連線號碼很小,例如 8,則效能會從 SAP 端讀取資料。
從 4vCPU 和 16 GB VM for SHIR 開始。 下列步驟顯示 SAP with SHIR 中對話工作程式的連線。
- 檢查客戶是否使用不佳的實體機器來設定並安裝 SHIR 來執行內部 SAP 複本。
- 移至Azure Data Factory入口網站,並尋找資料流程中使用的相關 SAP CDC 連結服務。 檢查參考的 SHIR 名稱。
- 檢查安裝 SHIR 之實體電腦的 CPU、記憶體、網路和磁片設定。
- 檢查 SHIR
diawp.exe
機器上有多少正在執行。 一個diawp.exe
可以執行一個複製活動。 的數目diawp.exe
是以電腦的 CPU、記憶體、網路和磁片設定為基礎。
如果您想要同時在 SHIR 上平行執行多個分割區,請使用功能強大的虛擬機器來設定 SHIR。 或使用 SHIR 高可用性和延展性功能相應放大,以擁有多個節點。 如需詳細資訊,請參閱高可用性和可擴縮性。
資料分割
下一節說明 SAP CDC 連接器的資料分割程式。 SAP 資料表和 SAP BW Open Hub 連接器的程式相同。
您可以根據您的效能需求,在自我裝載 IR 或 Azure IR 上執行調整。 檢閱 SHIR 的 CPU 耗用量,以檢視計量,以協助您決定調整方法。 根據需求,SHIR 可以垂直或水準調整。 建議您在較低的 SKU 上部署 Azure IR。 相應增加以符合透過負載測試決定的效能需求,而不是從不必要的結束開始。
注意
如果您達到 70% 的容量,請相應增加或相應放大 SHIR。
資料分割對於初始或大型完整載入很有用,而且通常不需要差異載入。 如果您未指定分割區,SAP 系統中預設為 1 個「產生者」,通常 (一個批次程式) 將來源資料擷取到運算元據佇列 (ODQ) ,而 SHIR 會從 ODQ 擷取資料。 根據預設,SHIR 會使用四個執行緒從 ODQ 擷取資料,因此目前 SAP 中可能會佔用四個對話進程。
資料分割的概念是將大型初始資料集分割成多個較小的不相鄰子集,這些子集在大小上最好相同,而且可以平行處理。 此方法會以線性方式減少從來源資料表產生資料到 ODQ 所需的時間。 此方法假設 SAP 端有足夠的資源可處理負載。
注意
- 平行執行的分割區數目受限於 Azure IR 中的驅動程式核心數目。 這項限制的解決方法目前正在進行中。
- SAP 交易 ODQMON 中的每個單位或封裝都是暫存資料夾中的單一檔案。
使用 CDC 執行管線時的設計考慮
檢查 SAP 到暫存持續時間。
檢查接收中的執行時間效能。
請考慮使用資料分割功能來增強效能,以提升輸送量。
如果 SAP 到階段持續時間緩慢,請考慮將 SHIR 大小調整為較高的規格。
檢查接收處理時間是否太慢。
如果使用小型叢集來執行對應資料流程,可能會影響接收的效能。 使用大型叢集,例如 16 + 256 核心,因此效能會從階段讀取資料,並寫入接收。
對於大型資料磁片區,我們建議分割負載以執行平行作業,但保留小於或等於 Azure IR 核心的資料分割數目,也稱為 Spark 叢集核心。
使用 [ 優化] 索引標籤來定義資料分割。 您可以在 CDC 連接器中使用來來源資料分割。
注意
- SHIR 核心和 Azure IR 節點的分割區數目之間有直接相互關聯。
- SAP CDC 連接器會列為 SAP 系統中 ODQMON 下的 Odata 訂閱者類型「運算元據布建的 Odata 存取」。
使用資料表連接器時的設計考慮
- 優化資料分割以提升效能。
- 請考慮 SAP 資料表中的平行處理原則程度。
- 請考慮目標接收的單一檔案設計。
- 當您使用大量資料量時,效能評定輸送量。
使用資料表連接器時的設計建議
分區: 當您在 SAP 資料表連接器中分割時,它會使用子句位於適當欄位上的 where 子句,將一個基礎 select 語句分割成數個,例如具有高基數的欄位。 如果您的 SAP 資料表有大量資料,請啟用資料分割,將資料分割成較小的分割區。 請嘗試將分割區數目優化 (參數
maxPartitionsNumber
) ,讓分割區夠小,以避免 SAP 中的記憶體傾印,但足以加速擷取。並行: 複製平行處理原則的程度 (參數
parallelCopies
) 與資料分割一起運作,並指示 SHIR 對 SAP 系統進行平行 RFC 呼叫。 例如,如果您將此參數設定為 4,服務會根據您指定的分割區選項和設定,同時產生並執行四個查詢。 每個查詢都會從 SAP 資料表擷取一部分的資料。為了獲得最佳結果,分割區數目應該是複製平行處理原則程度的倍數。
當您將資料從 SAP 資料表複製到二進位接收時,會根據 SHIR 中可用的記憶體數量,自動調整實際的平行計數。 記錄每個測試週期的 SHIR VM 大小、複製平行處理原則的程度,以及分割區數目。 觀察 SHIR VM 的效能、來源 SAP 系統的效能,以及所需的平行處理原則程度。 使用反復程式來識別最佳設定,以及 SHIR VM 的理想大小。 請考慮同時從一或多個 SAP 系統載入資料的所有擷取管線。
請注意針對已設定的平行處理原則程度,對 SAP 的 RFC 呼叫數目。 如果 SAP 的 RFC 呼叫數目小於平行處理原則的程度,請確認 SHIR VM 有足夠的記憶體和 CPU 資源可用。 視需要選擇較大的虛擬機器。 來源 SAP 系統已設定為限制平行連線的數目。 如需詳細資訊,請參閱本文中的 一般建議 一節。
檔案數目: 當您將資料複製到檔案型資料存放區,並將目標接收設定為資料夾時,預設會產生多個檔案。 如果您在接收中設定
fileName
屬性,資料會寫入單一檔案。 建議您以多個檔案的形式寫入資料夾,因為相較于寫入至單一檔案,它會取得較高的寫入輸送量。效能效能評定: 建議您使用效能基準測試練習來內嵌大量資料。 這個方法會改變參數,例如資料分割、平行處理原則的程度,以及檔案數目,以判斷指定架構、磁片區和資料類型的最佳設定。 以下列格式從測試收集資料。
疑難排解
若要從 SAP 系統緩慢或失敗擷取,請使用 SM37 中的 SAP 記錄,並將它們與 Data Factory 中的讀數相符。
如果只觸發一個批次作業,請將 SAP 來來源資料分割設定為在 Data Factory 中的對應資料流程中具有效能改善。 如需詳細資訊,請參閱 對應資料流程屬性中的步驟 6。
如果在 SAP 系統中觸發多個批次作業 ,而且每個批次作業的開始時間之間有顯著的差異,請變更 Azure IR 的大小。 當您增加 Azure IR 中的驅動程式節點數目時,SAP 端批次作業的平行處理原則會增加。
注意
Azure IR 的驅動程式節點數目上限為 16。 每個驅動程式節點只能觸發一個批次程式。
檢查 SHIR 中的記錄。 若要檢視記錄,請移至 SHIR VM。 開啟事件檢視器 > 應用程式和服務記錄 > 連接器 > 整合執行時間。
若要傳送記錄以支援,請移至 SHIR VM。 開啟 Integration Runtime 組態管理員 > 診斷 > 傳送記錄。 此動作會從過去七天傳送記錄,並提供報表識別碼。 您需要此執行的報告識別碼和 RunId。 記錄報表識別碼以供日後參考。
當您在 SLT 案例中使用 SAP CDC 連接器時:
確定符合必要條件。 SAP 環境轉換 (SLT) 使用者需要角色,例如 OLTP 系統中的 ADFSLTUSER 或 ECC,SLT 複寫才能運作。 如需詳細資訊,請參閱 需要哪些授權和角色。
如果 SLT 案例發生錯誤,請參閱分析的建議。 先隔離並測試 SAP 解決方案內的案例。 例如,藉由在 SE38 中執行 SAP
RODPS_REPL_TEST
所提供的測試程式,在 Data Factory 外部進行測試。 如果問題位於 SAP 端,當您使用報表時,您會收到相同的錯誤。 您可以使用交易程式碼ODQMON
來分析 SAP 中的資料擷取。如果您使用此測試報告,但不適用於 Data Factory,請連絡 Azure 或 Data Factory 支援。
下列範例顯示 SE38 中的 報表
RODPS_REPL_TEST
:下列範例顯示交易碼
ODQMON
:當 Data Factory 連結服務連線到 SLT 系統時,當您重新整理 [內容 ] 欄位時,它不會顯示 SLT 大量傳輸識別碼。
若要執行 SAP LT 複寫伺服器的 ODP/ODQ 複寫案例,請啟用下列商務增益集 (BAdI) 實作。
BAdI:
BADI_ODQ_QUEUE_MODEL
增強實作:
ODQ_ENH_SLT_REPLICATION
在交易 LTRC 中,移至 [專家函式 ] 索引標籤,然後選取 [ 啟用/停用 BAdI 實 作] 以啟用實作。
選取 [是] 。
在 ODQ/ODP 特定函式 資料夾中,選取 [檢查 BAdI 實作是否為使用中]。
對話方塊會顯示程式活動。
重設訂用帳戶。 若要從全新擷取或停止複寫資料開始,請移除 ODQMON 中的訂用帳戶。 此動作也會從 LTRC 移除專案。 重設訂用帳戶之後,可能需要幾分鐘的時間,才會在 LTRC 中看到效果。 排程作業資料布建 (ODP) 清理作業,以讓差異佇列保持乾淨,例如
ODQ_CLEANUP_CLIENT_004
CDS_VIEW (DHCDCMON 交易) 。 從 S/4HANA 1909 起,SAP 會從使用資料型觸發程式而非日期資料行的 CDS 檢視複寫資料。 此概念類似于 SLT,但不要使用 LTRC 交易來監視它,而是使用 DHCDCMON 交易。
SLT 疑難排解
SLT 複寫伺服器提供從 SAP 來源和非 SAP 來源到 SAP 目標和/或非 SAP 目標的即時資料複寫。 有三種類型的工具組可監視從 SLT 到 Azure 的擷取。
- ODQMON 是資料擷取的整體監視工具。 使用 ODQMON 開始分析,以追蹤資料不一致、初始效能分析,以及開啟訂用帳戶和擷取要求。
- LTRC 是用來檢查效能分析的交易。 如果您有從來源系統到 ODP 的資料複寫問題,因為您可以監視資料流程並找出不一致的情況,這非常有用。
- SM37 提供每個 SLT 擷取步驟的詳細監視。
一般內部處理應該使用 ODQMON 來完成,您可以在其中直接管理訂用帳戶,而且您不應該使用相同的 LTRC。
從 SLT 擷取資料時可能會遇到問題,例如:
擷取不會執行。 檢查 SAP CDC 連線是否已在 ODQMON 中建立連線,並檢查訂用帳戶是否存在。
資料不一致。 檢查 ODQMON 以查看資料的個別要求,並確認您可以在該處看到資料。 如果您在 ODQMON 中看到資料,但無法在 Azure Synapse 或 Data Factory 中看到資料,調查應該會在 Azure 端進行。 如果您看不到 ODQMON 中的資料,請使用 LTRC 執行 SLT 架構的分析。
效能問題。 資料擷取是兩個步驟的方法。 首先,SLT 會從來源系統讀取資料,並將其傳輸至 ODP。 其次,SAP CDC 連接器會從 ODP 挑選資料,並將其傳輸至所選的資料存放區。 LTRC 交易可讓您分析擷取程式的第一個部分。 若要分析從 ODP 到 Azure 的資料擷取,請使用 ODQMON 和 Data Factory 或 Synapse 監視工具。
SLT 效能
在初始載入模式中 (ODPSLT) ,有三個步驟可從 SLT 將資料擷取到 ODP:
- 建立移轉物件。 此程式只需要幾秒鐘的時間。
- 存取將來源資料表分割成較社區塊的計畫計算。 此步驟取決於您在 SLT 組態期間選取的初始載入模式,以及資料表的大小。 建議使用資源優化選項。
- 資料載入會將資料從來源系統傳輸至 ODP。
每個步驟都是由背景工作所控制。 您可以使用 SM37 和 LTRC 交易來監視持續時間。 如果您的系統過度使用,背景工作可能會在稍後啟動,因為沒有足夠的可用批次工作程式。 當工作閒置時,效能會受到影響。
如果存取計畫計算需要很長的時間,且您的初始負載模式設定為「效能優化」,請將它變更為「資源優化」,然後重新執行擷取。 如果資料載入需要很長的時間,請增加組態中的平行線程數目。
如果您使用獨立架構進行 SLT 複寫 (專用 SLT 複寫伺服器) ,來源系統和複寫伺服器之間的網路輸送量可能會影響擷取效能。
針對複寫:
- 請確定您有足夠的資料傳輸作業未保留給初始負載。
- 檢查負載統計資料中沒有未處理的記錄資料表記錄。
- 確定複寫選項已設定為即時。
LTRS 提供進階複寫設定。 如需詳細資訊,請參閱 SLT 疑難排解指南。
不同的 SAP 版本有不同的 LTRC 使用者介面。 下列螢幕擷取畫面顯示兩個不同版本的相同頁面。
SAP S/4HANA:
SAP ECC:
監視器
如需監視 SAP 資料擷取的資訊,請參閱下列資源: