Prestazioni e risoluzione dei problemi per l'estrazione dei dati SAP

Questo articolo fa parte della serie di articoli "SAP estendi e innova i dati: Best practices".

• Identificare le origini dati SAP
• Scegliere il connettore SAP migliore
• Prestazioni e risoluzione dei problemi per l'estrazione dei dati SAP
• Sicurezza dell'integrazione dei dati per SAP in Azure
• Architettura generica di integrazione dei dati SAP

Esistono molti modi per connettersi al sistema SAP per l'integrazione dei dati. Le sezioni seguenti descrivono considerazioni e raccomandazioni generali e specifiche del connettore.

Performance

È importante configurare le impostazioni ottimali per l'origine e la destinazione in modo da ottenere prestazioni ottimali durante l'estrazione e l'elaborazione dei dati.

Considerazioni generali

• Verificare che i parametri SAP corretti siano impostati per una connessione simultanea massima.
• Prendere in considerazione l'uso del tipo di accesso del gruppo SAP per migliorare le prestazioni e la distribuzione del carico.
• Assicurarsi che la macchina virtuale del runtime di integrazione self-hosted sia ridimensionata in modo adeguato e sia altamente disponibile.
• Quando si usano set di dati di grandi dimensioni, verificare se il connettore in uso offre una funzionalità di partizionamento. Molti connettori SAP supportano il partizionamento e la parallelizzazione delle funzionalità per velocizzare i carichi di dati. Quando si usa questo metodo, i dati vengono inseriti in blocchi più piccoli che possono essere caricati usando diversi processi paralleli. Per altre informazioni, vedere la documentazione specifica del connettore.

Raccomandazioni generali

• Usare la transazione SAP RZ12 per modificare i valori per il numero massimo di connessioni simultanee.

  Parametri SAP per RFC - RZ12: il parametro seguente può limitare il numero di chiamate RFC consentite per un utente o un'applicazione, quindi assicurarsi che questa restrizione non causi un collo di bottiglia.

  

  

• Connessione a SAP tramite il gruppo di accesso: SHIR (runtime di integrazione self-hosted) deve connettersi a SAP usando un gruppo di accesso SAP (tramite server dei messaggi) e non a un server di applicazioni specifico per garantire una distribuzione del carico di lavoro su tutti i server di applicazioni disponibili.

  Annotazioni

  Il cluster Spark di Dataflow e SHIR sono potenti. Molte attività di copia SAP interne, ad esempio 16, possono essere attivate ed eseguite. Tuttavia, se il numero di connessioni simultanee del server SAP è ridotto, ad esempio 8, perf legge i dati dal lato SAP.

• Iniziare con 4 vCPU e macchine virtuali da 16 GB per SHIR. I passaggi seguenti illustrano la connessione del processo di lavoro della finestra di dialogo in SAP con SHIR.

  1. Controllare se il cliente usa un computer fisico scadente per configurare e installare SHIR per eseguire una copia SAP interna.
  2. Vai al portale di Azure Data Factory e trova il servizio collegato SAP CDC utilizzato nel flusso di dati. Controllare il nome SHIR a cui si fa riferimento.
  3. Controllare le impostazioni cpu, memoria, rete e disco del computer fisico in cui è installato SHIR.
  4. Controllare quanti diawp.exe sono in esecuzione nel computer SHIR. Un diawp.exe può eseguire un'attività di copia. Il numero di diawp.exe è basato sulle impostazioni cpu, memoria, rete e disco del computer.

  

• Se si vogliono eseguire più partizioni in parallelo in SHIR contemporaneamente, usare una potente macchina virtuale per configurare SHIR. In alternativa, sfruttare la scalabilità orizzontale utilizzando le funzionalità SHIR di alta disponibilità e scalabilità per avere più nodi. Per altre informazioni, vedere Disponibilità elevata e scalabilità.

Partitions

La sezione seguente descrive il processo di partizionamento per un connettore SAP CDC. Il processo è lo stesso per un connettore SAP Table e SAP BW Open Hub.

Il ridimensionamento può essere eseguito sul runtime di integrazione self-hosted o sul runtime di integrazione di Azure a seconda dei requisiti di prestazioni. Esaminare il consumo di CPU dello SHIR per visualizzare le metriche e così decidere l'approccio di ridimensionamento. Il shir può essere ridimensionato verticalmente o orizzontalmente in base alle esigenze. È consigliabile distribuire il runtime di integrazione di Azure in uno SKU inferiore. Scala per soddisfare i tuoi requisiti di performance come determinato tramite test di carico, piuttosto che partire da livelli più alti senza necessità.

Il partizionamento è utile per carichi completi iniziali o di grandi dimensioni e in genere non è necessario per i carichi differenziali. Se non si specifica la partizione, per impostazione predefinita, 1 "producer" nel sistema SAP (in genere un processo batch) recupera i dati di origine nella coda dei dati operativi (ODQ) e SHIR recupera i dati da ODQ. Per impostazione predefinita, SHIR usa quattro thread per recuperare i dati da ODQ, quindi potenzialmente quattro processi di dialogo vengono occupati in SAP in quel momento.

L'idea del partizionamento consiste nel suddividere un set di dati iniziale di grandi dimensioni in più subset di dimensioni inferiori che sono idealmente uguali e che possono essere elaborati in parallelo. Questo metodo riduce il tempo necessario per produrre i dati dalla tabella di origine in ODQ in modo lineare. Questo metodo presuppone che sul lato SAP siano presenti risorse sufficienti per gestire il carico.

Considerazioni sulla progettazione per l'esecuzione delle pipeline con CDC

• Controllare la durata della fase di SAP.

• Controllare le prestazioni in fase di esecuzione nel sistema di raccolta.

• Prendere in considerazione l'uso della funzionalità di partizionamento per migliorare le prestazioni per migliorare la velocità effettiva.

• Se il tempo impiegato per il trasferimento da SAP a staging è lento, prendere in considerazione il ridimensionamento di SHIR a specifiche più elevate.

  

• Controllare se il tempo di elaborazione del sink è troppo lento.

  

  Se per eseguire il flusso di dati di mapping viene usato un cluster di piccole dimensioni, potrebbe influire sulle prestazioni nel sink. Usare un cluster di grandi dimensioni, ad esempio 16 + 256 core, in modo che il perf legga i dati dallo stadio e li scriva nel sink.

• Per volumi di dati di grandi dimensioni, è consigliabile partizionare il carico per eseguire processi paralleli, ma mantenere il numero di partizioni minore o uguale al core del runtime di integrazione di Azure, detto anche core del cluster Spark.

  Usare la scheda Ottimizza per definire le partizioni. È possibile usare il partizionamento di origine nel connettore CDC.

  

  Annotazioni

  • Esiste una correlazione diretta tra il numero di partizioni con core SHIR e i nodi del runtime di integrazione Azure.
  • Il connettore SAP CDC è elencato in ODQMON nel sistema SAP come tipo di iscrittore Odata "Accesso Odata per il provisioning dei dati operativi".

Considerazioni sulla progettazione quando si usa un connettore Table

• Ottimizzare il partizionamento per ottenere prestazioni migliori.
• Prendere in considerazione il grado di parallelismo di SAP Table.
• Si consideri una singola progettazione di file per il sink di destinazione.
• Misurare la capacità di elaborazione quando si usano grandi volumi di dati.

Consigli di progettazione quando si usa un connettore Table

• Partizione: Quando si esegue la partizione nel connettore di tabelle SAP, un'istruzione select sottostante viene suddivisa in più parti, usando le clausole where in un campo appropriato, ad esempio un campo con cardinalità elevata. Se la tabella SAP ha un volume elevato di dati, abilitare il partizionamento per suddividere i dati in partizioni più piccole. Provare a ottimizzare il numero di partizioni (parametro maxPartitionsNumber) in modo che le partizioni siano sufficientemente piccole per evitare dump di memoria in SAP ma abbastanza grandi da velocizzare l'estrazione.

• Parallelismo: Il grado di parallelismo di copia (parametro parallelCopies) funziona in combinazione con il partizionamento e istruisce lo SHIR per effettuare chiamate RFC parallele al sistema SAP. Ad esempio, se si imposta questo parametro su 4, il servizio genera simultaneamente ed esegue quattro query in base all'opzione di partizione e alle impostazioni specificate. Ogni query recupera una parte di dati dalla tabella SAP.

  Per ottenere risultati ottimali, il numero di partizioni deve essere un multiplo del numero del grado di parallelismo di copia.

  Quando si copiano dati dalla Tabella SAP ai sink binari, il conteggio parallelo effettivo viene modificato automaticamente in base alla quantità di memoria disponibile in SHIR. Registrare le dimensioni della macchina virtuale SHIR per ogni ciclo di test, il grado di parallelismo di copia e il numero di partizioni. Osservare le prestazioni della macchina virtuale SHIR, le prestazioni del sistema SAP di origine e il grado di parallelismo desiderato. Usare un processo iterativo per identificare le impostazioni ottimali e le dimensioni ideali per la macchina virtuale SHIR. Prendere in considerazione tutte le pipeline di inserimento che caricano simultaneamente i dati da uno o più sistemi SAP.

  Si noti il numero osservato di chiamate RFC a SAP rispetto al grado di parallelismo configurato. Se il numero di chiamate RFC a SAP è minore del grado di parallelismo, verificare che la macchina virtuale SHIR disponga di risorse di memoria e CPU sufficienti. Scegliere una macchina virtuale più grande, se necessario. Il sistema SAP di origine è configurato per limitare il numero di connessioni parallele. Per altre informazioni, vedere la sezione Raccomandazioni generali in questo articolo.

• Numero di file: Quando si copiano dati in un archivio dati basato su file e il sink di destinazione è configurato come cartella, per impostazione predefinita vengono generati più file. Se si imposta la fileName proprietà nel sink, i dati sono scritti in un singolo file. È consigliabile scrivere in una cartella come più file perché ottiene una velocità effettiva di scrittura superiore rispetto alla scrittura in un singolo file.

• Benchmark delle prestazioni: È consigliabile usare l'esercizio di benchmarking delle prestazioni per inserire grandi quantità di dati. Questo metodo varia i parametri, ad esempio il partizionamento, il grado di parallelismo e il numero di file per determinare l'impostazione ottimale per l'architettura, il volume e il tipo di dati specificati. Raccogliere dati dai test nel formato seguente.

  

Risoluzione dei problemi

• Per l'estrazione lenta o non riuscita dal sistema SAP, usare i log SAP di SM37 e associarli alle letture in Data Factory.

• Se viene attivato un solo processo batch, impostare le partizioni di origine SAP per migliorare le prestazioni nel flusso di dati di mapping in Data Factory. Per altre informazioni, vedere il passaggio 6 in Mappare le proprietà del flusso di dati.

• Se nel sistema SAP vengono attivati più processi batch e si verifica una differenza significativa tra l'ora di inizio di ogni processo batch, modificare le dimensioni del runtime di integrazione di Azure. Quando si aumenta il numero di nodi driver in Azure IR, aumenta il parallelismo dei processi batch sul lato SAP.

  Annotazioni

  Il numero massimo di nodi driver per Azure IR è 16. Ogni nodo del driver può attivare un solo processo batch.

• Verificare i log su SHIR. Per visualizzare i log, passare alla macchina virtuale SHIR. Aprire il visualizzatore eventi > registri applicazioni e servizi > connettori > runtime di integrazione.

• Per inviare i log al supporto, passare alla macchina virtuale SHIR. Apri il Configuration Manager di Integration Runtime> Diagnostic> Invio Log. Questa azione invia i log degli ultimi sette giorni e fornisce un ID del report. È necessario questo ID report e RunId della tua esecuzione. Documentare l'ID del report per riferimento futuro.

• Quando si utilizza il connettore SAP CDC in uno scenario SLT:

  • Assicurarsi che i prerequisiti siano soddisfatti. I ruoli sono necessari per l'utente SLT (SAP Landscape Transformation), ad esempio ADFSLTUSER nei sistemi OLTP o ECC affinché la replica SLT funzioni. Per altre informazioni, vedere Quali autorizzazioni e ruoli sono necessari.

  • Se si verificano errori in uno scenario SLT, vedere le raccomandazioni per l'analisi. Isolare e testare prima lo scenario all'interno della soluzione SAP. Ad esempio, testarlo all'esterno di Data Factory eseguendo il programma di test fornito da SAP RODPS_REPL_TEST in SE38. Se il problema si trova sul lato SAP, viene visualizzato lo stesso errore quando si usa il report. È possibile analizzare l'estrazione dei dati in SAP usando il codice ODQMONdella transazione .

    Se la replica funziona quando si usa questo report di test, ma non con Data Factory, contattare il supporto di Azure o Data Factory.

    L'esempio seguente mostra un report per RODPS_REPL_TEST in SE38:

    

    

    

    Nell'esempio seguente viene illustrato il codice ODQMONdella transazione :

    

  • Quando il servizio collegato Data Factory si connette al sistema SLT, non mostra gli ID trasferimento di massa SLT quando si aggiorna il campo Contesto .

    

  • Per eseguire lo scenario di replica ODP/ODQ per il server di replica SAP LT, attivare l'implementazione del componente aggiuntivo aziendale (BAdI) seguente.

    Badi: BADI_ODQ_QUEUE_MODEL

    Implementazione del miglioramento: ODQ_ENH_SLT_REPLICATION

    1. Nella transazione LTRC passare alla scheda Expert Function e selezionare Attiva/Disattiva implementazione BAdI per attivare l'implementazione.

       

    2. Selezionare Sì.

       

    3. Nella cartella delle funzioni specifiche odQ/ODP selezionare Controlla se l'implementazione di BAdI è attiva.

       

       La finestra di dialogo mostra l'attività del programma.

       

• Reimpostare le sottoscrizioni. Per iniziare con un'estrazione aggiornata o arrestare i dati di replica, rimuovere la sottoscrizione in ODQMON. Questa azione rimuove anche le registrazioni dal LTRC. Dopo aver reimpostato la sottoscrizione, potrebbero essere necessari alcuni minuti prima di visualizzare l'effetto in LTRC. Pianificare le attività di manutenzione del provisioning dei dati operativi (ODP) per mantenere pulite le code delta, ad esempio ODQ_CLEANUP_CLIENT_004

• CDS_VIEW (transazione DHCDCMON). A partire da S/4HANA 1909, SAP replica i dati dalle viste CDS che usano trigger basati su dati anziché colonne di data. Il concetto è simile a SLT, ma invece di usare la transazione LTRC per monitorarlo, si usa la transazione DHCDCMON.

Risoluzione dei problemi di SLT

Il server di replica SLT fornisce la replica dei dati in tempo reale da origini SAP e/o origini non SAP alle destinazioni SAP e/o non SAP. Esistono tre tipi di set di strumenti per monitorare l'estrazione da SLT ad Azure.

• ODQMON è lo strumento di monitoraggio complessivo per l'estrazione dei dati. Avviare l'analisi con ODQMON per tenere traccia delle incoerenze dei dati, analisi delle prestazioni iniziali e aprire le richieste di sottoscrizione ed estrazione.
• LTRC è la transazione da usare per controllare l'analisi delle prestazioni. È utile se si verificano problemi di replica dei dati dal sistema di origine a ODP perché è possibile monitorare il flusso di dati e trovare incoerenze.
• SM37 fornisce un monitoraggio dettagliato di ogni passaggio di estrazione SLT.

La normale manutenzione deve essere eseguita usando ODQMON dove è possibile gestire direttamente la sottoscrizione e non è consigliabile usare LTRC per lo stesso.

È possibile riscontrare problemi durante l'estrazione di dati da SLT, ad esempio:

• L'estrazione non funziona. Controllare se la connessione SAP CDC ha creato una connessione in ODQMON e verificare se la sottoscrizione esiste.

• Incoerenze dei dati. Controllare ODQMON per visualizzare la singola richiesta di dati e verificare che sia possibile visualizzare i dati. Se è possibile visualizzare i dati in ODQMON ma non in Azure Synapse o Data Factory, l'indagine dovrebbe verificarsi sul lato Azure. Se non è possibile visualizzare i dati in ODQMON, eseguire un'analisi del framework SLT usando LTRC.

• Problemi di prestazioni. L'estrazione dei dati è un approccio in due passaggi. Prima di tutto, SLT legge i dati dal sistema di origine e lo trasferisce a ODP. In secondo luogo, il connettore SAP CDC preleva i dati da ODP e lo trasferisce nell'archivio dati scelto. La transazione LTRC consente di analizzare la prima parte del processo di estrazione. Per analizzare l'estrazione dei dati da ODP ad Azure, usare ODQMON e Data Factory o gli strumenti di monitoraggio di Synapse.

  Annotazioni

  Per ulteriori informazioni, vedi queste risorse:

  • Connettore SAP CDC e SLT - Parte 1 - Panoramica e architettura
  • Connettore SAP CDC e SLT - Parte 2 - Configurazione iniziale

Prestazioni SLT

Nella modalità di caricamento iniziale (ODPSLT) è necessario eseguire tre passaggi per estrarre i dati da SLT in ODP:

1. Creare oggetti di migrazione. Questo processo richiede solo un paio di secondi.
2. Accedere al calcolo del piano che suddivide la tabella di origine in blocchi più piccoli. Questo passaggio dipende dalla modalità di caricamento iniziale selezionata durante la configurazione SLT e dalle dimensioni della tabella. È consigliabile usare l'opzione ottimizzata per le risorse.
3. Il caricamento dei dati trasferisce i dati dal sistema di origine a ODP.

• Ogni passaggio è controllato dai processi in background. È possibile utilizzare le transazioni SM37 e LTRC per monitorare la durata. Se il sistema è sovrautilato, i processi in background potrebbero essere avviati in un secondo momento perché non sono presenti processi di lavoro batch gratuiti sufficienti. Quando le attività sono inattive, le prestazioni risentono.

• Se il calcolo del piano di accesso richiede molto tempo e la modalità di caricamento iniziale è impostata su "ottimizzata per le prestazioni", impostarla su "ottimizzata per le risorse" ed eseguire di nuovo l'estrazione. Se il caricamento dei dati richiede molto tempo, aumentare il numero di thread paralleli nella configurazione.

• Se si usa un'architettura autonoma per la replica SLT (server di replica SLT dedicato), la velocità effettiva di rete tra il sistema di origine e il server di replica potrebbe influire sulle prestazioni di estrazione.

• Per la duplicazione:

  • Assicurarsi di disporre di processi di trasferimento dati sufficienti che non siano riservati per il caricamento iniziale.
  • Verificare che non sia presente un record di tabella di registrazione non elaborato nelle statistiche di caricamento.
  • Assicurarsi che l'opzione di replica sia impostata su in tempo reale.

• Le impostazioni di replica avanzate sono disponibili in LTRS. Per altre informazioni, vedere la guida alla risoluzione dei problemi SLT.

• Versioni sap diverse hanno interfacce utente LTRC diverse. Gli screenshot seguenti mostrano la stessa pagina per due versioni diverse.

  SAP S/4HANA:

  

  SAP ECC:

  

Monitor

Per informazioni sul monitoraggio dell'estrazione dei dati SAP, vedere queste risorse:

• Monitorare visivamente Data Factory
• Monitorare le code delta

Passaggi successivi

• Sicurezza dell'integrazione dei dati SAP