Questa guida mostra agli amministratori di SAP LT Replication Server, agli ingegneri dei dati SAP o ad altri come eseguire attività operative, come l'ottimizzazione delle prestazioni e gli aggiornamenti delle versioni, per la versione 2.9 (la più recente) di BigQuery Connector per SAP.
Ottimizzazione delle prestazioni di replica
Il rendimento della replica può essere influenzato da più fattori. I fattori specifici che si applicano possono variare da un'installazione all'altra e possono cambiare nel tempo.
Le sezioni seguenti forniscono indicazioni su come ottimizzare alcuni dei fattori più comuni che possono influire sulle prestazioni.
Per ulteriori informazioni sul rendimento della replica con BigQuery Connector per SAP, vedi Pianificazione del rendimento.
Impostare le opzioni di rendimento per le tabelle
In SAP LT Replication Server puoi specificare le opzioni di replica per ogni tabella che influiscono sulle prestazioni.
In particolare, le prestazioni di replica per le tabelle di grandi dimensioni, che richiedono più tempo e risorse per la replica, possono trarre vantaggio dalla specifica di intervalli e dall'aumento del numero massimo di job di replica paralleli che possono essere utilizzati per la tabella.
Esempi di tabelle che in genere aumentano di dimensioni sono MSEG
, ACDOCA
e MATDOC
, tra le altre.
Quando specifichi job di replica paralleli per tabelle di grandi dimensioni, devi bilanciare il numero di job paralleli che consenti per una determinata tabella con il numero totale di job paralleli consentiti nella configurazione del trasferimento collettivo. La tua organizzazione potrebbe anche limitare il numero di job di replica paralleli che puoi specificare per un determinato server.
Per impostare le opzioni di rendimento per una tabella:
Nella GUI di SAP, inserisci la transazione SAP
LTRS
.Nella schermata Impostazioni di replica avanzate, specifica l'ID delle impostazioni di trasferimento collettivo per la tabella.
Nella gerarchia di cartelle Impostazioni di replica avanzate, fai clic sulla cartella Opzioni di rendimento per visualizzare le tabelle in cui sono definite le opzioni di rendimento.
Se la tabella che ti serve non è elencata, fai clic con il tasto destro del mouse sulla cartella Opzioni prestazioni, quindi seleziona Aggiungi tabella.
Specifica un nome per la tabella.
Specifica le seguenti opzioni in base alle esigenze:
- Nella sezione General Performance Options (Opzioni generali di rendimento):
- Numero di job paralleli, per impostare il numero massimo di job di replica paralleli che possono essere utilizzati per la tabella.
- Numero di sequenza, per dare la priorità alla replica di questa tabella rispetto ad altre repliche di tabelle.
- Nella sezione Initial Load Options (Opzioni di caricamento iniziale):
- Per Tipo di lettura, seleziona Calcolo intervallo tipo di lettura 1, se la tabella non è troppo grande. Per saperne di più, consulta Prestazioni e impostazioni avanzate di replica LTRS.
- Per Dimensioni pacchetto, specifica le dimensioni in byte delle porzioni di record inviate a SAP LT Replication Server.
- Se selezioni un tipo di lettura che utilizza intervalli, definisci intervalli appropriati.
- Nella sezione Opzione di replica:
- Per Intervalli per la tabella di logging, specifica Nessun intervallo per l'opzione più affidabile.
- Se selezioni Specifica intervalli manualmente, definisci intervalli appropriati.
- Nella sezione General Performance Options (Opzioni generali di rendimento):
Fai clic su Salva.
Benchmark delle prestazioni di base
Per aiutarti a valutare il rendimento della replica, questa sezione contiene numeri di rendimento di base osservati nei sistemi di test Google Cloud , sia per la replica CDC tramite Pub/Sub sia per la replica dei dati di streaming.
A causa dei numerosi fattori diversi che influiscono sul rendimento, è probabile che i tuoi numeri sul rendimento varino.
Ad esempio, se i tuoi sistemi SAP non vengono eseguiti su Google Cloud, i tassi di caricamento e replica potrebbero essere più lenti rispetto ai tassi di base a causa di fattori quali la latenza di rete e l'overhead associato ai token di accesso. Se la tabella di origine ha meno colonne o se installi SAP LT Replication Server sul proprio server in un'architettura autonoma, le tariffe potrebbero essere più veloci perché SAP LT Replication Server non deve competere con il sistema di origine per le risorse.
Replica CDC tramite Pub/Sub: numeri di rendimento di base osservati
Per la replica CDC tramite Pub/Sub, i seguenti numeri di rendimento rappresentano il rendimento di base osservato da Google Cloud per ogni tipo di sistema di origine durante i test. In ogni sistema di test, SAP LT Replication Server è stato installato sul sistema di origine SAP in un'architettura incorporata su VM Compute Engine. Il sistema di origine SAP era in esecuzione nella stessa Google Cloud regione del set di dati BigQuery di destinazione.
Per informazioni sulla configurazione dei sistemi di test, consulta Configurazione del sistema di test delle prestazioni di base.
Per visualizzare i numeri di rendimento, fai clic sul tipo di sistema di origine:
S/4HANA
- Tabella: ACDOCA
- 343 milioni di record
- 477 colonne
- Caricamento iniziale
- Velocità di caricamento:280 milioni di record all'ora in media
- Durata del carico:73,5 minuti in media
- Replica
- Tasso di modifica della tabella di origine:40 milioni di record all'ora in media
- Tasso di replica massimo:in media 40 milioni di record all'ora
ECC
- Tabella: MSEG
- 300 milioni di record
- 188 colonne
- Caricamento iniziale
- Velocità di caricamento:308 milioni di record all'ora in media
- Durata del carico:58 minuti in media
- Replica
- Tasso di modifica della tabella di origine:40 milioni di record all'ora in media
- Tasso di replica massimo:in media 55,2 milioni di record all'ora
I numeri di rendimento precedenti sono le baseline osservate dai testerGoogle Cloud .
Il rendimento osservato è stato migliore nei sistemi di test che avevano i seguenti attributi:
- SAP LT Replication Server è stato installato sulla propria VM in un'architettura
autonoma.
- Per i sistemi S/4HANA, è stato osservato che un'architettura autonoma ha un tasso di caricamento iniziale circa il 42% più veloce di un'architettura incorporata grazie allo scaling indipendente dei processi SAP LT Replication Server.
- Per i sistemi ECC, è stato osservato che un'architettura autonoma ha un tasso di caricamento iniziale circa il 10% più veloce di un'architettura incorporata grazie allo scaling indipendente dei processi SAP LT Replication Server.
- La tabella di origine aveva meno colonne.
- La dimensione complessiva in byte dei record era inferiore.
Per informazioni sugli attributi di sistema che puoi modificare per migliorare il rendimento, vedi:
Replica dei dati in streaming: numeri di rendimento della base di riferimento osservati
Per la replica dei dati di streaming, i seguenti numeri di rendimento rappresentano il rendimento di base osservato da Google Cloud per ogni tipo di sistema di origine durante i test. In ogni sistema di test, SAP LT Replication Server è stato installato sul sistema di origine SAP in un'architettura incorporata su VM Compute Engine. Il sistema di origine SAP era in esecuzione nella stessa Google Cloud regione del set di dati BigQuery di destinazione.
Per informazioni sulla configurazione dei sistemi di test, consulta Configurazione del sistema di test delle prestazioni di base.
Per visualizzare i numeri di rendimento, fai clic sul tipo di sistema di origine:
S/4HANA
- Tabella: ACDOCA
- 343 milioni di record
- 477 colonne
- Caricamento iniziale
- Velocità di caricamento:350 milioni di record all'ora in media
- Durata del carico:59 minuti in media
- Replica
- Tasso di modifica della tabella di origine:in media 50 milioni di record all'ora
- Velocità di replica massima:in media 50 milioni di record all'ora
ECC
- Tabella: MSEG
- 203 milioni di record
- 188 colonne
- Caricamento iniziale
- Velocità di caricamento:385 milioni di record all'ora in media
- Durata del carico:32 minuti in media
- Replica
- Tasso di modifica della tabella di origine:in media 50 milioni di record all'ora
- Tasso di replica massimo:in media 69 milioni di record all'ora
I numeri di rendimento precedenti sono le baseline osservate dai testerGoogle Cloud .
Il rendimento osservato è stato migliore nei sistemi di test che avevano i seguenti attributi:
- SAP LT Replication Server è stato installato sulla propria VM in un'architettura
autonoma.
- Per i sistemi S/4HANA, è stato osservato che un'architettura autonoma ha un tasso di caricamento iniziale circa il 42% più veloce di un'architettura incorporata grazie allo scaling indipendente dei processi SAP LT Replication Server.
- Per i sistemi ECC, è stato osservato che un'architettura autonoma ha un tasso di caricamento iniziale circa il 10% più veloce di un'architettura incorporata grazie allo scaling indipendente dei processi SAP LT Replication Server.
- La tabella di origine aveva meno colonne.
- La dimensione complessiva in byte dei record era inferiore.
Per informazioni sugli attributi di sistema che puoi modificare per migliorare il rendimento, vedi:
Configurazione del sistema di test delle prestazioni di base
I sistemi di test descritti in questa sezione hanno prodotto i numeri di rendimento di base elencati nelle sezioni precedenti, Benchmark del rendimento di base.
I sistemi di test, inclusi il sistema di origine SAP, SAP LT Replication Server e il set di dati BigQuery, venivano eseguiti su VM Compute Engine nella stessa regione Google Cloud .
In ogni sistema, i server e il carico di lavoro sono stati progettati per simulare un carico di lavoro più pesante e un volume di replica più elevato che è probabile trovare in molte installazioni reali.
Per visualizzare gli attributi del sistema di test, fai clic sul tipo di sistema di origine:
S/4HANA
- Architettura di installazione di SAP LT Replication Server:
- Architettura incorporata
- Server del sistema di origine:
- Due server delle applicazioni, ciascuno su un tipo di macchina personalizzata di Compute Engine basato su N2 con le seguenti specifiche:
- vCPU: 60
- Memoria: 324 GB
- Piattaforma CPU: Intel Cascade Lake
- Un server SAP HANA su una VM Compute Engine
m1-ultramem-80
con le seguenti specifiche:- vCPU: 80
- Memoria: 1900 GB
- Piattaforma CPU: Intel Broadwell
- Due server delle applicazioni, ciascuno su un tipo di macchina personalizzata di Compute Engine basato su N2 con le seguenti specifiche:
- Versioni software:
- S/4HANA 1909
- SAP LT Replication Server: S/4CORE 104 SP00
- Dimensioni della tabella:
- Nome tabella: ACDOCA, dati delle voci di giornale della contabilità generale
- Numero di record: 343 milioni
- Numero di colonne: 477
- Processi di lavoro su ogni server delle applicazioni:
- 60 processi di Dialog
- 220 Processi in background
- Carica le impostazioni in SAP LT Replication Server:
- Lavori: 99
- Tipo di lettura: 1 intervallo
- Calcolo: intervalli automatici
- Impostazioni di replica:
- Lavori: 99
- Utilizza i campi chiave per calcolare gli intervalli per la tabella di registrazione
- 128 intervalli
ECC
- Architettura di installazione di SAP LT Replication Server:
- Architettura incorporata
- Server del sistema di origine:
- Due server delle applicazioni, ciascuno su una VM di Compute Engine con le seguenti specifiche:
- vCPU: 60
- Memoria: 348 GB
- Piattaforma CPU: Intel Cascade Lake
n2-highmem-48
- Due server delle applicazioni, ciascuno su una VM di Compute Engine con le seguenti specifiche:
- Versioni software:
- SAP NetWeaver: 7.0 EHP2
- SAP LT Replication Server: DMIS 2011_1_700 SP17
- Dimensioni della tabella:
- Tabella: MSEG, documenti di gestione dell'inventario dei materiali
- Numero di record: 203 milioni
- Numero di colonne: 188
- Processi di lavoro su ogni server delle applicazioni:
- 60 processi di Dialog
- 100 processi in background
- Carica le impostazioni in SAP LT Replication Server:
- Lavori: 99
- Tipo di lettura: 5 Mittente
- Coda: intervalli manuali
- Impostazioni di replica:
- Lavori: 99
- Intervalli per la tabella di logging: utilizza i campi chiave per calcolare gli intervalli
- Numero di intervalli: 128
Dimensioni dinamiche dei segmenti
Se si verificano errori perché le dimensioni in byte dei chunk superano le dimensioni massime in byte per le richieste HTTP accettate da BigQuery, devi ridurre manualmente le dimensioni in byte riducendo le dimensioni dei chunk. La funzionalità di dimensioni dinamiche dei blocchi consente di ridurre automaticamente le dimensioni dei blocchi e riprovare la replica in BigQuery quando le dimensioni in byte di un blocco superano le dimensioni massime in byte per le richieste HTTP accettate da BigQuery. La dimensione dinamica dei blocchi ti aiuta a evitare la maggior parte degli errori di replica dovuti al superamento della dimensione in byte di una richiesta. Potresti ricevere un errore solo se la dimensione del chunk raggiunge 1, ma la dimensione in byte rimane superiore al limite di BigQuery sul numero di byte in ogni richiesta HTTP.
Per abilitare la dimensione dinamica dei blocchi nella configurazione del trasferimento collettivo per una tabella,
utilizza la transazione /GOOG/SLT_SETTINGS
.
La dimensione dinamica del chunk è un'impostazione facoltativa. Per informazioni su
come attivare le dimensioni dinamiche dei chunk, vedi:
- Per la replica CDC tramite Pub/Sub, consulta Specificare la creazione di tabelle e altri attributi generali.
- Per la replica dei dati di streaming, vedi Specificare la creazione di tabelle e altri attributi generali.
Quando abiliti il dimensionamento dinamico dei chunk, la dimensione massima dei chunk di BigQuery Connector per SAP è allineata ai limiti di quota del servizio sottostante:
- Per la replica CDC tramite Pub/Sub: i limiti di quota di Pub/Sub, ovvero 1000 record.
- Per la replica dei dati di streaming: i limiti di quota di BigQuery, che è di 50.000 record.
Per ulteriori informazioni sulle dimensioni dei segmenti, vedi Dimensioni delle porzioni e dimensioni dei segmenti.
Come funziona la dimensione dinamica dei chunk
Con la dimensione dinamica dei chunk, se la richiesta HTTP con la dimensione iniziale dei chunk supera il limite di BigQuery per le dimensioni in byte, BigQuery Connector per SAP riduce la dimensione dei chunk e riprova a inviare i dati. BigQuery Connector per SAP continua a ridurre le dimensioni del blocco e ritenta di inviare i dati a BigQuery, finché i dati non vengono trasferiti correttamente per un determinato blocco o finché le dimensioni del blocco non raggiungono 1.
La dimensione del blocco ridotta finale, per la quale il trasferimento dei dati è andato a buon fine, viene quindi utilizzata come dimensione del blocco per tutti i blocchi rimanenti di quella parte. Puoi trovare la dimensione finale ridotta del chunk che ha avuto esito positivo per ogni parte nei log dell'applicazione SAP LT Replication Server come messaggio informativo:
Dynamic chunking triggered. Chunk size reduced from
INITIAL_CHUNK_SIZE_VALUE to FINAL_REDUCED_CHUNK_SIZE_VALUE
.
Per le parti successive e le repliche successive, BigQuery Connector per SAP inizia a inviare dati a BigQuery con le dimensioni del blocco configurate nella transazione /GOOG/SLT_SETTINGS
e continua a ridurre le dimensioni del blocco se viene attivata la suddivisione dinamica in blocchi.
Per impostazione predefinita, la dimensione del blocco viene ridotta del 50% dopo ogni nuovo tentativo. Se vuoi ridurre le dimensioni del blocco di una percentuale inferiore o superiore, modifica i parametri delle impostazioni avanzate.
Vediamo con un esempio come viene determinata la dimensione dei blocchi nel processo di replica quando la dimensione dinamica dei blocchi è abilitata per una tabella.
Per questo esempio, viene utilizzata la replica CDC tramite Pub/Sub.
Quando la dimensione della porzione di SAP LT Replication Server è maggiore della dimensione del blocco di BigQuery Connector per SAP e la dimensione del blocco di 1000 record è definita nella transazione /GOOG/SLT_SETTINGS
. BigQuery Connector per SAP replica una parte in
BigQuery nel seguente modo:
Quando la replica inizia per una porzione che contiene 2000 record, la dimensione del blocco per il primo blocco è di 1000 record, ma se la dimensione in byte della richiesta HTTP è superiore a 10 MB, BigQuery Connector per SAP riduce la dimensione del blocco del 50% e la nuova dimensione del blocco diventa 500 record.
BigQuery Connector per SAP riprova a inviare le dimensioni del blocco di 500 record, ma se le dimensioni in byte della richiesta HTTP sono ancora superiori a 10 MB, allora BigQuery Connector per SAP riduce ulteriormente le dimensioni del blocco del 50%, e le nuove dimensioni del blocco diventano 250 record.
BigQuery Connector per SAP tenta di inviare le dimensioni del blocco di 250 record. Se le dimensioni in byte della richiesta HTTP per questo blocco sono inferiori a 10 MB, la replica ha esito positivo e i dati vengono inseriti in BigQuery.
La dimensione del blocco per tutti i blocchi successivi diventa di 250 record, a condizione che la dimensione in byte di ogni richiesta HTTP sia inferiore a 10 MB. Se le dimensioni in byte della richiesta HTTP per qualsiasi blocco successivo superano i 10 MB, alloraBigQuery Connector per SAPAP riduce nuovamente le dimensioni del blocco e riprova a inviare i dati a BigQuery, finché il trasferimento dei dati non va a buon fine per un determinato blocco. La dimensione ridotta del chunk viene utilizzata solo per la parte corrente della replica corrente.
Rendimento con dimensioni dei chunk dinamiche
Le dimensioni dinamiche dei chunk possono influire sulle prestazioni della replica in BigQuery. Per ogni blocco, BigQuery Connector per SAP calcola il numero di record in un blocco e controlla le dimensioni in byte delle richieste HTTP. Se la dimensione in byte è superiore a 10 MB, BigQuery Connector per SAP riduce la dimensione del blocco e riprova a inviare i dati a BigQuery, il che aumenta il tempo di replica complessivo.
Utilizza le dimensioni dinamiche dei chunk solo in situazioni specifiche, in cui anche dopo aver configurato una dimensione ideale dei chunk per alcuni record di dati, le dimensioni della richiesta potrebbero superare il limite delle richieste HTTP di BigQuery e non vuoi ricevere un errore relativo alle dimensioni dei chunk. Ad esempio:
- Tabelle di origine che contengono una grande varianza nella scarsità dei dati nei campi, ovvero per alcuni record vengono mantenuti meno campi mentre per alcuni record vengono mantenuti molti campi.
- Tabelle di origine che contengono campi di testo lungo come
EDID4-SDATA
,VARI-CLUSTID
eREPOSRC-DATA
.
Puoi anche utilizzare le dimensioni dinamiche dei chunk durante la fase di test per identificare le dimensioni ideali dei chunk per una tabella che puoi definire nel tuo sistema SAP di produzione.
Per saperne di più sulla configurazione delle dimensioni dei segmenti, vedi:
- Per la replica CDC tramite Pub/Sub, consulta Specificare la creazione di tabelle e altri attributi generali.
- Per la replica dei dati di streaming, vedi Specificare la creazione di tabelle e altri attributi generali.
Convalide della cache
La funzionalità di convalida della cache è disponibile solo con la replica CDC tramite Pub/Sub.
La funzionalità Convalide della cache, utilizzata in particolare durante i caricamenti iniziali dei dati, migliora notevolmente le prestazioni delle chiamate di trasferimento dei dati da SAP a Google Cloud memorizzando nella cache i risultati della convalida della pipeline dopo il primo controllo riuscito. In questo modo vengono eliminati i passaggi di convalida ridondanti per i trasferimenti di dati successivi, risparmiando tempo e risorse.
Si tratta di un'impostazione consigliata, in particolare durante
la fase di caricamento iniziale dei dati. Per attivare questa funzionalità, seleziona la casella di controllo
Cache Val (Cache Validations) nella transazione /GOOG/SLT_SETTINGS
.
Per informazioni su come attivare questa funzionalità, vedi Specificare la creazione di tabelle e altri attributi generali.
Quando questa impostazione è attiva, BigQuery Connector per SAP esegue un controllo iniziale per verificare che la pipeline Google Cloud sia configurata correttamente e sia coerente con lo schema della tabella definito in SAP. Questa pipeline comprende l'argomento Pub/Sub, il relativo schema, la sottoscrizione BigQuery e la tabella BigQuery di destinazione. Dopo questa convalida iniziale e la creazione della pipeline, i risultati vengono archiviati nella memoria condivisa SAP. Per tutte le chiamate di trasferimento dei dati successive, questo passaggio di convalida viene quindi ignorato, ottimizzando le prestazioni riducendo i controlli ridondanti.
Cancella la convalida memorizzata nella cache
Quando la funzionalità Convalide della cache è abilitata e aggiorni la definizione della tabella SAP,
le modifiche strutturali vengono aggiornate solo dopo la scadenza della convalida memorizzata nella cache esistente.
In questi casi, puoi cancellare manualmente i risultati della convalida memorizzati nella cache.
Per cancellare i risultati della convalida memorizzati nella cache, esegui la transazione SE38
, quindi esegui il programma /GOOG/R_GCP_CLEAR_CACHE
o la transazione /GOOG/BQPS_CLR_CACHE
.
Pulisci gli artefatti Google Cloud
Per gli ambienti di sviluppo, per rimuovere le risorse Google Cloud collegate a un ID trasferimento collettivo, puoi utilizzare il programma /GOOG/R_CLEANUP_CPS_ARTIFACTS
.
Questo programma elimina l'argomento Pub/Sub associato, il relativo schema Pub/Sub e la sottoscrizione BigQuery.
Trasferire le impostazioni di trasferimento collettivo alla produzione
Per trasferire le impostazioni di trasferimento collettivo in produzione, devi prima esportarle da un sistema di sviluppo e poi importarle nel sistema di produzione.
Se vuoi, puoi importare tre parti separate delle impostazioni di un trasferimento collettivo in produzione:
- Le impostazioni di replica avanzate, a cui è possibile accedere utilizzando la transazione
LTRS
. - Le impostazioni della chiave client della tabella
/GOOG/CLIENT_KEY
, a cui è possibile accedere utilizzando la transazioneSM30
. - BigQuery Connector per SAP le impostazioni di trasferimento collettivo, a cui è possibile
accedere utilizzando la transazione
/GOOG/SLT_SETTINGS
.
Esportare le impostazioni di trasferimento collettivo da un sistema di sviluppo
Nel sistema di sviluppo di SAP LT Replication Server, esporta ogni parte delle impostazioni di trasferimento collettivo:
Esporta le impostazioni di replica avanzate:
- Esegui la transazione
LTRS
. - Seleziona i record di trasferimento collettivo che stai trasferendo in produzione.
- Dal menu a discesa File, seleziona Esporta tutte le impostazioni.
- Nella finestra di dialogo Impostazioni di esportazione, seleziona una destinazione e fai clic su Salva. Le impostazioni vengono salvate in un file compresso in formato CSV sulla tua workstation locale.
- Esegui la transazione
Esporta le impostazioni di trasferimento collettivo di BigQuery Connector per SAP:
Esegui la transazione
/GOOG/SLT_SETTINGS
:/n/GOOG/SLT_SETTINGS
Nel campo Tabella delle impostazioni, seleziona Trasferimento collettivo.
Seleziona i record di trasferimento collettivo che stai trasferendo in produzione.
Fai clic su Trasferimento collettivo del trasporto.
In Richiesta prompt per Workbench, inserisci il numero della richiesta di trasporto e fai clic sull'icona Continua. Per ogni record di trasferimento di massa selezionato, le impostazioni delle seguenti tabelle di configurazione personalizzata sono incluse nel trasporto:
/GOOG/BQ_MASTR
/GOOG/BQ_TABLE
/GOOG/BQ_FIELD
Le impostazioni di trasferimento collettivo vengono salvate in una richiesta di trasporto.
Esporta le impostazioni della chiave client includendo manualmente i contenuti della tabella
/GOOG/CLIENT_KEY
nella richiesta di trasporto.Salva i file sulla workstation locale.
Importare le impostazioni di trasferimento collettivo in un sistema di produzione
Nel sistema di produzione SAP LT Replication Server, importa ogni parte delle impostazioni di trasferimento collettivo:
Crea una configurazione di replica SAP LT Replication Server per le impostazioni di trasferimento collettivo.
Importa le impostazioni di replica avanzate:
- Esegui la transazione
LTRS
. - Seleziona il trasferimento collettivo che hai creato nel primo passaggio.
- Dal menu a discesa File, seleziona Importa tutte le impostazioni.
- Nella finestra di dialogo Scegli file, seleziona il file compresso dalla workstation locale e fai clic su Apri. Le impostazioni vengono importate come impostazioni per il trasferimento collettivo.
- Esegui la transazione
Importa la richiesta di trasporto che contiene le impostazioni di trasferimento collettivo.
Esegui la transazione
SM30
.Aggiorna le impostazioni della chiave client in base alle esigenze per l'ambiente di produzione.
Esegui la transazione
/GOOG/SLT_SETTINGS
:/n/GOOG/SLT_SETTINGS
Verifica che i trasferimenti collettivi corretti vengano visualizzati nella schermata Trasferimenti collettivi.
Nella colonna ID trasferimento collettivo, sostituisci l'ID trasferimento collettivo del sistema di sviluppo con l'ID trasferimento collettivo della configurazione di replica che hai creato nel primo passaggio.
Nelle schermate delle impostazioni Tabelle e Campi successive, aggiorna gli altri valori per la mappatura di tabelle e campi in base alle necessità per l'ambiente di produzione.
Testa la configurazione avviando un caricamento iniziale o una replica.
Aggiorna BigQuery Connector per SAP
Google Cloud fornisce nuove release di BigQuery Connector per SAP come trasporti SAP.
Gli amministratori SAP possono aggiornare BigQuery Connector per SAP seguendo questi passaggi:
- Disattiva la configurazione in SAP LT Replication Server.
- Importa la nuova richiesta di trasporto SAP.
- Dopo aver convalidato l'importazione e l'attivazione dell'oggetto, attiva la configurazione in SAP LT Replication Server.
Aggiorna gcloud CLI
Devi mantenere aggiornata Google Cloud CLI sull'host SAP LT Replication Server.
Per saperne di più sulla gestione di gcloud CLI, vedi Gestione dei componenti di gcloud CLI.
Monitoraggio
Puoi monitorare diversi punti lungo il percorso dei dati dall'origine dati SAP alla tabella BigQuery di destinazione, tra cui:
- Infrastruttura: rete, hardware e sistema operativo
- Livello del database SAP
- Il livello applicativo SAP
- BigQuery Connector per SAP
- BigQuery
- Pub/Sub
Le opzioni di monitoraggio in ciascuno di questi punti sono presentate nelle sottosezioni seguenti.
Monitoraggio dell'infrastruttura
Su Google Cloud, puoi installare Ops Agent sulle tue VM host per il monitoraggio e il logging avanzati. L'agente Ops invia i dati a Cloud Monitoring nella console Google Cloud .
Per ulteriori informazioni, vedi:
Per i sistemi che non vengono eseguiti su Google Cloud, puoi anche ottenere
informazioni sul server eseguendo transazioni SAP, ad esempio
la transazione ST06
.
Monitoraggio del livello di database
Utilizza i codici transazione SAP standard per monitorare l'integrità del database.
Il codice transazione DBACOCKPIT
è la transazione più comune per
monitorare il database. Questa transazione fornisce anche log dettagliati
che puoi utilizzare per risolvere gli errori.
Per SAP HANA, puoi utilizzare SAP HANA Studio per le operazioni SAP HANA. Puoi installare SAP HANA Studio su qualsiasi macchina frontend.
Quando risolvi i problemi di prestazioni o di altro tipo, controlla quanto segue nel database di origine:
- Istruzioni SQL costose
- Serrature
- Carica cronologia
- Indici
- Processi
Monitoraggio del livello applicazione
Puoi utilizzare gli strumenti di monitoraggio e risoluzione dei problemi delle applicazioni SAP per monitorare e risolvere i problemi di BigQuery Connector per SAP, perché viene eseguito nel livello applicazione.
Il monitoraggio e la risoluzione dei problemi delle applicazioni SAP possono essere ulteriormente classificati in quanto segue:
- Monitoraggio e risoluzione dei problemi SAP standard
- Monitoraggio e risoluzione dei problemi di BigQuery Connector per SAP
Per i paesaggi più grandi, puoi utilizzare SAP Solution Manager come strumento di monitoraggio centrale.
Puoi utilizzare i codici transazione SAP nel seguente elenco per monitorare e diagnosticare i problemi sui singoli sistemi di applicazioni SAP:
- Stato della configurazione SLT:
LTRC
- Errori e log SLT:
LTRO
eSLG1
- Internet Communication Manager (chiamate HTTP e HTTPS):
SMICM
- Sicurezza e certificati:
STRUST
- SAP transports:
STMS
- Connessioni RFC:
SM59
- Comando del sistema operativo:
SM69
- Controllo del pacchetto:
SE80
- Controlli di autorizzazione:
SU53
- Lavori in background:
SM37
- Log di sistema:
SM21
Monitoraggio di Pub/Sub
Utilizza Cloud Monitoring per visualizzare le metriche di Pub/Sub e per creare grafici e avvisi.
Ogni metrica è associata a un tipo di risorsa, pubsub_topic
o
pubsub_subscription
, e include anche un insieme di etichette che forniscono
dimensioni aggiuntive per il filtraggio e l'analisi.
Anche se puoi ancora utilizzare il Monitoring Query Language (MQL) per le configurazioni esistenti, ti consigliamo di utilizzare il Prometheus Query Language (PromQL) per creare nuove query. PromQL offre un modo potente e flessibile per analizzare i dati Pub/Sub, in linea con gli standard di settore per l'osservabilità.
Per ulteriori informazioni su Monitoring, consulta la documentazione di Cloud Monitoring.
Monitoraggio dell'argomento messaggi non recapitabili per i messaggi non recapitabili
Un argomento messaggi non recapitabili in Pub/Sub è un argomento dedicato in cui i messaggi che non possono essere elaborati correttamente da un abbonamento vengono inviati dopo un numero configurato di tentativi di consegna. Per identificare e analizzare i messaggi non recapitati, prevenire la perdita di dati e comprendere lo stato di integrità dell'elaborazione dei messaggi, devi monitorare l'argomento messaggi non recapitabili.
Per monitorare in modo efficace l'argomento messaggi non recapitabili, in genere configuri un abbonamento
all'argomento messaggi non recapitabili che definisci nella configurazione del trasferimento collettivo.
Successivamente, monitora questo abbonamento specifico utilizzando lo stesso tipo di risorsa pubsub_subscription
e le relative metriche.
Metriche principali dell'argomento messaggi non recapitabili
Per capire come eseguire query sulle metriche per l'abbonamento all'argomento di messaggi non recapitabili, esplora i seguenti esempi di PromQL:
- Conteggio dei messaggi inoltrati all'argomento messaggi non recapitabili: questa è la metrica più
importante per capire se i messaggi non vengono recapitati.
sum(rate(pubsub_googleapis_com:subscription_dead_letter_message_count{subscription_id="DEAD_LETTER_TOPIC_SUBSCRIPTION_ID"}[5m]))
- Numero di messaggi non confermati nell'argomento dead letter: indica i
messaggi in attesa di elaborazione o revisione nella DLQ.
Un numero costantemente elevato o in aumento suggerisce un problema che richiede attenzione.
pubsub_googleapis_com:subscription_num_unacked_messages{subscription_id="DEAD_LETTER_TOPIC_SUBSCRIPTION_ID"}
- Età del messaggio non riconosciuto meno recente nell'argomento messaggi non recapitabili: un valore in aumento indica
un backlog crescente di messaggi non riusciti che non vengono gestiti.
pubsub_googleapis_com:subscription_oldest_unacked_message_age{subscription_id="DEAD_LETTER_TOPIC_SUBSCRIPTION_ID"}
- Dimensioni backlog (byte) nell'argomento messaggi non recapitabili: fornisce informazioni sul
volume di dati nell'argomento messaggi non recapitabili.
pubsub_googleapis_com:subscription_backlog_bytes{subscription_id="DEAD_LETTER_TOPIC_SUBSCRIPTION_ID"}
Best practice per il monitoraggio degli argomento messaggi non recapitabili
Per il monitoraggio degli argomento messaggi non recapitabili, applica le seguenti best practice:
Crea avvisi dedicati: configura avvisi per gli aumenti di
pubsub_googleapis_com:subscription_num_unacked_messages
opubsub_googleapis_com:subscription_oldest_unacked_message_age
nell'abbonamento all'argomento di messaggi non recapitabili.Dashboard per l'argomento dead letter: crea una dashboard dedicata in Monitoring per visualizzare lo stato dell'argomento dead letter nel tuo progetto.
Intervento umano: i messaggi nell'argomento messaggi non recapitabili spesso richiedono un'ispezione e un intervento manuali per comprendere la causa principale dell'errore, ad esempio dati non validi, bug dell'applicazione e interruzioni del servizio esterno.
Rielaborazione automatica (con cautela): per determinati errori prevedibili, potresti implementare processi automatizzati, come le funzioni Cloud Run e i job Dataflow, per utilizzare i messaggi delargomento messaggi non recapitabilir, tentare di correggerli e ripubblicarli nell'argomento originale. Gestisci questa situazione con estrema attenzione per evitare loop infiniti.
Monitoraggio di BigQuery
Utilizza Monitoring per visualizzare le metriche di BigQuery e
creare grafici e avvisi. Ogni metrica ha un tipo di risorsa, ovvero
bigquery_dataset
, bigquery_project
o global
, nonché un insieme di
etichette.
Utilizza i tipi di risorse e le etichette per creare query in Monitoring Query Language (MQL).
Puoi raggruppare o filtrare ogni metrica utilizzando le etichette.
Per ulteriori informazioni su Monitoring, consulta la documentazione di Cloud Monitoring.
Visualizzare le impostazioni del connettore
Per visualizzare le impostazioni di trasferimento collettivo di BigQuery Connector per SAP, in SAP GUI,
esegui la transazione /GOOG/SLT_SETT_DISP
.
Visualizzare la versione del connettore
Per visualizzare la versione di BigQuery Connector per SAP installata sul tuo sistema,
in SAP GUI, esegui la transazione /GOOG/BQC_VERSION
.
Utilità del connettore
BigQuery Connector per SAP fornisce le seguenti utilità che ti aiutano a semplificare le operazioni sui dati e a ottimizzare le prestazioni tramite funzionalità come preparazione, convalida, trasformazione e simulazione del caricamento dei dati:
Utilità | Replica dei dati in streaming | Replica CDC tramite Pub/Sub |
---|---|---|
Strumento Crea tabella | Supportato | Non supportata |
Strumento di conversione collettiva dei campi | Supportato | Non supportata |
Strumento di simulazione del carico | Supportato | Non supportata |
Strumento di convalida della replica | Supportato | Non supportata |
Strumento Stream Records | Non supportata | Supportato |
Strumento Crea tabella
Questo strumento non è supportato per la replica CDC tramite Pub/Sub.
Per le tabelle di origine vuote in SAP, SAP SLT impedisce la creazione di tabelle di destinazione in BigQuery. Se devi creare le tabelle di destinazione nel set di dati BigQuery per le tabelle di origine vuote, puoi utilizzare lo strumento Crea tabella.
Per eseguire lo strumento Crea tabella:
Nella GUI di SAP, esegui la transazione
/GOOG/CREATE_BQ_TAB
preceduta da/n
:/n/GOOG/CREATE_BQ_TAB
Nella schermata Crea tabelle di destinazione dalle impostazioni BQ, fornisci i valori per i seguenti campi:
- Chiave di trasferimento collettivo: la chiave di trasferimento collettivo che contiene le tabelle SAP.
- Nome tabella SAP: i nomi delle tabelle SAP che devi creare.
Fai clic sull'icona Esegui. Le tabelle di destinazione vengono create nel set di dati BigQuery.
Se vuoi, verifica nel set di dati BigQuery se la tabella è stata creata con lo schema corretto.
Strumento di conversione dei campi collettiva
Questo strumento non è supportato per la replica CDC tramite Pub/Sub.
Anche se BigQuery Connector per SAP suggerisce automaticamente i
tipi di dati BigQuery per la maggior parte dei campi, potrebbe essere necessario
mappare i campi manualmente. Anziché assegnare manualmente il tipo di dati a ogni
campo, puoi utilizzare lo strumento Conversione collettiva dei campi per mappare l'assegnazione del tipo di dati per tutti i campi nella schermata di mappatura dei campi della transazione /GOOG/SLT_SETTINGS
. Lo strumento di conversione collettiva dei campi converte tutti i mapping dei campi
per una tabella nel tipo STRING
su BigQuery.
Se una tabella è già in fase di replica o viene aggiunta per il caricamento iniziale
nella transazione LTRC
, non utilizzare lo strumento di conversione collettiva dei campi
per queste tabelle, in quanto potrebbe causare problemi di mancata corrispondenza dello schema.
Puoi utilizzare questo strumento solo per le tabelle SAP per le quali non è stato avviato il caricamento iniziale o la replica.
Per eseguire lo strumento di conversione collettiva dei campi:
Nella GUI di SAP, esegui la transazione
/GOOG/MASS_CNVT_FMAP
preceduta da/n
:/n/GOOG/MASS_CNVT_FMAP
Nella schermata Conversione in blocco dei campi, fornisci i valori per i seguenti campi:
- Chiave di trasferimento collettivo: la chiave di trasferimento collettivo che contiene le tabelle SAP.
- Nome tabella SAP: i nomi delle tabelle SAP per cui devi convertire tutti i mapping dei campi nel tipo
STRING
.
Fai clic sull'icona Esegui. Per le tabelle selezionate, tutti i mapping dei campi vengono convertiti nel tipo
STRING
.
Strumento di simulazione del carico
Questo strumento non è supportato per la replica CDC tramite Pub/Sub.
Questa sezione fornisce una panoramica dello strumento di simulazione del carico e di cosa puoi fare con esso.
Lo strumento di simulazione del caricamento è uno strumento di supporto per BigQuery Connector per SAP che consente di simulare la replica dei dati SAP in BigQuery. Lo strumento fa parte del trasporto che Google Cloud fornisce per BigQuery Connector per SAP. Utilizzi lo strumento di simulazione del caricamento per replicare i dati SAP di origine in BigQuery richiamando direttamente il Business Add In (BAdI) di BigQuery Connector per SAP. Poiché lo strumento di simulazione del carico non utilizza il framework SLT sottostante, i trigger SLT non sono interessati. Non utilizzare lo strumento di simulazione del carico per la replica dei dati negli ambienti di produzione.
Lo strumento di simulazione del carico fornisce un report che puoi analizzare per valutare le prestazioni della replica, identificare potenziali problemi, comprendere la causa principale dei problemi e risolverli prima della replica effettiva dei dati SAP in BigQuery utilizzando BigQuery Connector per SAP.
Di seguito sono riportati alcuni casi d'uso comuni in cui puoi utilizzare lo strumento di simulazione del carico:
- Riproduci e risolvi eventuali problemi di connettività di rete, autorizzazione o autenticazione.
- Genera log avanzati delle chiamate API BigQuery per risolvere i problemi.
- Per qualsiasi assistenza per la risoluzione dei problemi da parte dell'assistenza clienti Google Cloud, esegui lo strumento di simulazione del carico e fornisci i log al team di assistenza clienti.
- Misura le metriche sul rendimento fornendo il tempo impiegato per ogni passaggio del processo di replica.
- Per SAP LT Replication Server in un'architettura incorporata, determina una dimensione ottimale del blocco per le tabelle SAP.
Utilizza una configurazione di trasferimento collettivo di esempio con lo strumento di simulazione del caricamento che crei utilizzando la transazione personalizzata /GOOG/SLT_SETTINGS
.
Non utilizzare il set di dati di produzione e le tabelle BigQuery
per eseguire lo strumento di simulazione del carico.
Quando SAP LT Replication Server si trova in un'architettura incorporata, esegui lo strumento di simulazione del caricamento con le tabelle SAP standard come MARA
e T001
.
Quando SAP LT Replication Server si trova in un'architettura autonoma, esegui lo strumento
Simulazione di carico
con la tabella di esempio /GOOG/TEST_REPL
fornita Google Cloud
con BigQuery Connector per SAP. Lo strumento di simulazione del carico non supporta
la lettura delle tabelle di origine da un sistema remoto.
Per saperne di più sulle architetture per le origini dati SAP su Google Cloud, consulta Architettura di installazione.
Prerequisiti
Prima di eseguire lo strumento di simulazione del carico, assicurati che siano soddisfatti i seguenti prerequisiti:
BigQuery Connector per SAP è installato e configurato. Per informazioni sui passaggi di installazione e configurazione, consulta Installare BigQuery Connector for SAP e Configurare il connettore per la replica dei dati in streaming.
Gli utenti previsti hanno accesso alla transazione personalizzata
/GOOG/LOAD_SIMULATE
fornita da Google Cloud. Per saperne di più, consulta Creare ruoli e autorizzazioni SAP per BigQuery Connector per SAP.
Come eseguire lo strumento di simulazione del carico
Per eseguire lo strumento di simulazione del carico:
Nella GUI di SAP, inserisci la transazione
/GOOG/LOAD_SIMULATE
preceduta da/n
:/n/GOOG/LOAD_SIMULATE
Fai clic sull'icona Esegui. Viene visualizzata la schermata Simulazione di carico SLT.
In Opzioni di elaborazione, assicurati che l'opzione Esegui simulazione sia selezionata.
Nella sezione Opzioni di selezione, inserisci le seguenti specifiche:
- Dal menu a discesa nel campo Partner Google Cloud, seleziona BigQuery.
Nel campo Chiave di trasferimento collettivo, inserisci la chiave di trasferimento collettivo per la configurazione di trasferimento collettivo.
Utilizza una configurazione di trasferimento collettivo di esempio con lo strumento di simulazione del carico. Non utilizzare il set di dati di produzione e le tabelle BigQuery.
Nel campo Nome tabella, inserisci il nome della tabella SAP di origine che hai fornito nella configurazione di trasferimento collettivo di esempio.
(Facoltativo) Nel campo Condizione WHERE, inserisci una condizione per la selezione dei dati dalla tabella di origine.
Può contenere al massimo 255 caratteri. Ad esempio, se esegui lo strumento di simulazione del carico per la tabella SAP
MARA
e devi selezionare il numero di materiale da un intervallo specifico, allora per Where Condition, specifica un valore comeMATNR GE '000000000400000001' AND MATNR LE '000000000600000001'
.Nel campo Conteggio cicli, inserisci il numero di cicli di elaborazione eseguiti dallo strumento di simulazione del carico.
Questa operazione è utile quando devi confrontare l'aspetto del report di simulazione in più cicli. Il valore deve essere maggiore di 1.
Nel campo Conteggio record per ciclo, inserisci il numero di record che vuoi inviare a BigQuery in ogni ciclo di elaborazione. Il valore deve essere maggiore di 1.
Nel campo Dimensione porzione, inserisci il numero di record su Conteggio record per ciclo che SAP LT Replication Server invia a BAdI di BigQuery Connector per SAP in ogni porzione.
Seleziona uno o più flag in base alle esigenze:
Conteggio esatto dei record: indica che a BigQuery viene inviato esattamente lo stesso numero di record fornito nel campo Conteggio record per ciclo in ogni ciclo di elaborazione. Se la tabella non contiene record sufficienti, lo strumento di simulazione del carico duplica i record esistenti per raggiungere il conteggio richiesto. I record vengono duplicati solo per inserire i dati in BigQuery e non per inserirli nella tabella di origine.
Utilizza la struttura di destinazione SLT: utilizza la struttura della tabella di logging SLT per ottenere i campi della tabella di origine. Se questo flag non è impostato, i campi vengono letti direttamente dalla tabella di origine per generare la struttura di destinazione. Per ulteriori informazioni sul flusso di dati di SAP LT Replication Server, consulta Visualizzazione architetturale dettagliata del flusso di dati.
Log dettagliato: indica che i record di log vengono creati per tutti i metodi definiti in BigQuery Connector per SAP. Se questo flag non è impostato, vengono registrati solo i metodi importanti.
Cancella risultati precedenti: cancella i record di log creati in precedenza per lo stesso trasferimento collettivo e la stessa tabella SAP. Se il flag non è impostato, i log vengono aggiunti ai risultati precedenti.
Per eseguire lo strumento di simulazione del carico, fai clic sull'icona Esegui.
Al termine della simulazione di caricamento, nella sezione Opzioni di elaborazione, seleziona il pulsante di opzione Visualizza report.
Nella sezione Opzioni di selezione, inserisci le seguenti specifiche:
- Dal menu a discesa nel campo Partner Google Cloud, seleziona BigQuery.
- Nel campo Chiave di trasferimento collettivo, inserisci la chiave di trasferimento collettivo per la configurazione di trasferimento collettivo di esempio.
- Nel campo Nome tabella, inserisci il nome della tabella SAP di origine.
- (Facoltativo) Per visualizzare il report in base alla data di esecuzione della simulazione di caricamento, specifica un intervallo di date nel campo Data report.
- (Facoltativo) Per visualizzare l'ultimo report eseguito insieme a quello attuale, seleziona il flag Solo ultima esecuzione.
Per visualizzare il report, fai clic sull'icona Esegui.
Nella tabella seguente vengono descritte le colonne visualizzate nel report sulla simulazione:
Nome | Descrizione |
---|---|
Chiave di trasferimento | La chiave di trasferimento di massa per la configurazione del trasferimento di massa. |
SAP Table | Il nome della tabella SAP che viene replicata in BigQuery. |
Timestamp di inizio esecuzione | L'ora in cui è iniziata l'esecuzione di un metodo BigQuery Connector per SAP. |
Timestamp di completamento | L'ora in cui l'esecuzione è stata completata per un metodo BigQuery Connector per SAP. |
Numero job | Numero di job univoco per ogni esecuzione completata che viene generato automaticamente ogni volta che viene eseguito lo strumento di simulazione del carico. |
Ciclo Numb | Il numero di sequenza del ciclo di elaborazione in cui viene generato il report. Il Conteggio record per ciclo fornito nell'input di simulazione viene trasferito a BigQuery per ogni ciclo. |
Porzione Numb | Il numero di sequenza della porzione. Il conteggio dei record per ciclo fornito nell'input di simulazione viene suddiviso in porzioni in base alle dimensioni della porzione specificate. La BAdI di BigQuery Connector per SAP viene chiamata per ogni porzione. |
Nome corso | Il nome della classe del metodo BigQuery Connector per SAP. |
Nome metodo | Il nome del metodo BigQuery Connector per SAP. I metodi chiamati da BigQuery Connector per SAP vengono registrati in sequenza. Se nel campo di input della simulazione è selezionato il flag Log dettagliato, vengono registrati tutti i metodi, altrimenti vengono registrati solo quelli importanti. |
Richiamato dal metodo | L'ultimo metodo che ha richiamato il metodo BigQuery Connector per SAP corrente. |
Durata | Il tempo totale impiegato per l'esecuzione di un metodo BigQuery Connector per SAP. |
Conteggio consigli | Il numero di record passati a un metodo BigQuery Connector per SAP. Questo valore viene visualizzato solo per i metodi a cui vengono passati i record. |
Metodo URI | Il nome del metodo HTTP, nel caso in cui il metodo ABAP effettui una chiamata API BigQuery. |
Stringa URI | L'URL HTTP, nel caso in cui il metodo ABAP effettui una chiamata all'API BigQuery. |
Origine token | L'origine del token di autenticazione utilizzato dallo strumento di simulazione del carico. Questo vale solo se la memorizzazione nella cache dei token è
attivata nella tabella /GOOG/CLIENT_KEY . I valori possibili sono:
|
Data di scadenza | Il tempo per la scadenza del token di autenticazione. Questo è applicabile solo quando la memorizzazione nella cache dei token è attivata nella tabella /GOOG/CLIENT_KEY . |
Valore token | Valore del token di autenticazione utilizzato dallo strumento di simulazione del carico per accedere a BigQuery. |
Codice di reso | Il codice restituito dell'esecuzione del metodo. I valori possibili sono:
|
Testo dell'errore | Il titolo dell'errore, se presente. |
Descrizione errore | Informazioni dettagliate sull'errore. |
Dimensioni payload | La dimensione del payload HTTP per l'API BigQuery Insert. Se si verifica un errore nell'esecuzione del metodo e le dimensioni del payload sono superiori a 10 MB, puoi modificare le dimensioni del chunk per ridurre le dimensioni del payload. |
Testo informativo | Qualsiasi messaggio informativo pertinente generato dal BAdI di
BigQuery Connector per SAP. Ad esempio, quando viene attivata la suddivisione dinamica, viene visualizzato il seguente messaggio informativo:
Dynamic chunking triggered. Chunk size reduced from
INITIAL_CHUNK_SIZE_VALUE to FINAL_REDUCED_CHUNK_SIZE_VALUE . |
Stato | Stato di esecuzione del metodo. Se l'esecuzione di un metodo non va a buon fine, consulta la guida alla risoluzione dei problemi di BigQuery Connector per SAP per risolvere il problema. |
Strumento di simulazione del carico pianificato
Puoi pianificare l'esecuzione automatica dello strumento di simulazione del carico come
job in background su SAP LT Replication Server utilizzando il
nome del programma /GOOG/R_LOAD_SIMULATION
.
Per ulteriori informazioni sulla pianificazione dei job in background da SAP,
consulta Scheduling Background Jobs.
Convalida della replica
Se selezioni il flag Campi aggiuntivi quando crei la tabella BigQuery di destinazione con la transazione /GOOG/SLT_SETTINGS
, vengono aggiunte colonne allo schema della tabella per memorizzare il tipo di modifica a ogni record che ha attivato la replica e per un timestamp che riflette l'ora in cui SAP LT Replication Server ha ricevuto la parte contenente il record.
Puoi utilizzare i tipi di modifica e il timestamp per eseguire query sui seguenti tipi di conteggi dei record:
- Il numero di record caricati in una tabella BigQuery durante un caricamento iniziale.
- Il numero di record replicati in un giorno specificato in una tabella BigQuery.
- Il numero totale di record unici in una tabella BigQuery.
Per ottenere questi conteggi, puoi eseguire query sulla tabella BigQuery direttamente inviando query SQL nella console Google Cloud oppure puoi eseguire lo strumento di convalida della replica, che genera report che confrontano i conteggi dei record BigQuery con le statistiche o i conteggi dei record di SAP LT Replication Server della tabella di origine.
Per una panoramica del flag Campi aggiuntivi, consulta Campi aggiuntivi per le query di conteggio e le modifiche ai record.
Per informazioni su come specificare il flag Campi aggiuntivi, vedi Specificare la creazione di tabelle e altri attributi generali.
Query SQL per i conteggi dei record
Nella pagina Editor SQL di BigQuery nella consoleGoogle Cloud , puoi eseguire query SQL per controllare i conteggi dei record nelle tabelle BigQuery.
Puoi quindi confrontare i conteggi dei record BigQuery con i conteggi nella tabella di origine o nelle statistiche di SAP LT Replication Server.
Esegui query sul conteggio dei record inseriti nella modalità di caricamento iniziale
Quando lo schema di una tabella BigQuery include la colonna facoltativa
operation_flag
, i record inseriti nella tabella
in modalità di caricamento iniziale includono il flag dell'operazione L
.
Per ottenere il conteggio dei record ricevuti da BigQuery durante un caricamento iniziale, esegui la seguente query:
SELECT COUNT(*) FROM `PROJECT.DATASET.TABLE` WHERE operation_flag = 'L'
Esegui query sul numero di record inseriti in modalità di replica
Quando lo schema di una tabella BigQuery include la colonna facoltativa operation_flag
, i record inseriti nella tabella in modalità di replica includono uno dei seguenti flag di operazione:
I
: il record è stato inserito nella tabella di origine.D
: il record è stato eliminato dalla tabella di origine.U
: il record è stato aggiornato nella tabella di origine.
Per ottenere il conteggio dei record ricevuti da BigQuery in modalità di replica, esegui la seguente query:
SELECT COUNT(*) FROM `PROJECT.DATASET.TABLE` WHERE operation_flag = 'I' | 'D' | 'U'
Eseguire una query sul conteggio totale dei record in una tabella BigQuery
Quando lo schema di una tabella BigQuery include la colonna facoltativa
recordstamp
, il campo recordstamp
corrispondente di ogni record
inserito nella tabella contiene un timestamp che indica quando
il record è stato inviato da SAP LT Replication Server a BigQuery.
Quando CDC non è attivato, per ottenere un conteggio totale dei record in una tabella BigQuery che puoi confrontare con il conteggio totale dei record in una tabella di origine, puoi utilizzare i campi recordstamp
e is_deleted
per conteggiare i record univoci nella tabella BigQuery che non sono stati eliminati dalla tabella di origine.
Se la tabella di origine viene aggiornata attivamente o la replica è attiva quando esegui una query sui record, il conteggio dei record nelle tabelle di origine e di destinazione potrebbe non corrispondere esattamente.
Per ottenere il conteggio attuale dei record univoci nella tabella di destinazione BigQuery, esegui la seguente query:
SELECT COUNT(*) FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY KEY_FIELD_1, ..., KEY_FIELD_N ORDER BY recordstamp DESC) row_num FROM `PROJECT.DATASET.TABLE` ) WHERE row_num = 1 AND is_deleted = false
Quando CDC è attivato, per ottenere il conteggio attuale dei record univoci nella tabella di destinazione BigQuery, esegui la seguente query:
SELECT COUNT(*) FROM `PROJECT.DATASET.TABLE`;
Strumento di convalida della replica
Questo strumento non è supportato per la replica CDC tramite Pub/Sub.
Questa sezione fornisce una panoramica dello strumento di convalida della replica e di cosa puoi fare con esso.
Lo strumento di convalida della replica genera report che confrontano i conteggi dei record nella tabella BigQuery con le statistiche di SAP LT Replication Server e i conteggi dei record nella tabella di origine. Se i conteggi non corrispondono esattamente, lo strumento contrassegna il report con un cerchio rosso.
Per conteggiare i record in BigQuery, lo strumento utilizza le query SQL mostrate nella sezione precedente, Query SQL per i conteggi dei record.
Esegui periodicamente lo strumento di convalida della replica per verificare che SAP LT Replication Server e BigQuery Connector per SAP replichino i record in BigQuery come previsto.
Per eseguire lo strumento di convalida della replica, inserisci la transazione personalizzata
/GOOG/REPLIC_VALID
preceduta da /n
nella GUI SAP. Per
istruzioni passo passo, vedi Eseguire lo strumento di convalida della replica.
Report di convalida della replica
Puoi generare i seguenti report di convalida con lo strumento di convalida della replica:
- Conteggi caricamento iniziale:un confronto tra il numero di record inviati da SAP LT Replication Server in modalità di caricamento e il numero di record caricati in BigQuery.
- Conteggi di replica:un confronto tra il numero di record inviati da SAP LT Replication Server in modalità di replica e il numero di record inseriti in BigQuery in un giorno specifico.
- Conteggi attuali:un confronto puntuale del numero di record presenti nella tabella di origine e del numero di record unici in BigQuery. Il conteggio attuale nella tabella di origine non può visualizzare un numero maggiore del limite di numeri interi a 32 bit (da -2.147.483.648 a 2.147.483.647).
Puoi generare ogni report singolarmente oppure, selezionando Tutti i controlli quando esegui lo strumento, puoi generare tutti e tre i report in una singola esecuzione. Con il campo Nomi delle tabelle, puoi generare i report di convalida della replica per tabelle specifiche nella configurazione del trasferimento collettivo.
Visualizzare i report di convalida della replica
Dopo aver generato un report, puoi visualizzarlo selezionando il pulsante di opzione Visualizza report nella sezione Opzioni di elaborazione dell'interfaccia dello strumento di convalida della replica.
Le informazioni visualizzate dallo strumento di convalida della replica in ogni report variano leggermente a seconda del tipo di report.
Tutti i report includono i seguenti tipi di informazioni:
- Conteggi dei record di origine dalle statistiche di SAP LT Replication Server e dalla tabella di origine.
- Conteggi dei record di destinazione dalla tabella BigQuery di destinazione.
- Qualsiasi differenza tra i due conteggi. La differenza viene calcolata sottraendo i conteggi BigQuery dai conteggi dei record di origine. Un valore positivo indica un problema probabile, perché suggerisce che non tutti i record di origine vengono inseriti in BigQuery.
- La differenza nei conteggi visualizzata come percentuale del conteggio dei record di origine.
- Un indicatore visivo che mostra se i conteggi di origine e destinazione sono uguali o diversi.
Conteggi di record non uguali
Lo strumento di convalida della replica include un campo di stato in ogni report che visualizza.
Un quadrato verde nel campo dello stato indica che il conteggio dei record di origine è uguale al conteggio dei record di destinazione in BigQuery.
Un cerchio rosso nel campo dello stato indica che i conteggi dei record non sono uguali.
Un conteggio dei record non uguale non indica sempre un problema. I seguenti indicatori suggeriscono un possibile problema:
- Per un report Conteggi attuali, un valore diverso indica sempre un problema.
Per un report Conteggi caricamento iniziale o Conteggi replica, un valore positivo indica un probabile problema.
Un valore negativo relativamente basso non è un problema. A volte il conteggio in una tabella BigQuery di destinazione può essere leggermente superiore al conteggio dei record di origine a causa di eventi come interruzioni momentanee della connettività che causano l'invio di nuovo dei dati da parte di SAP LT Replication Server.
Se noti un conteggio non uniforme, esegui nuovamente il report per assicurarti che non sia causato da un problema temporaneo. Un conteggio dei record non uniforme può verificarsi a causa dell'elaborazione della replica al momento della generazione del report da parte dello strumento.
Per una tabella di origine molto grande o una tabella con filtri impostati in SAP LT Replication Server per il caricamento iniziale o la replica, lo strumento di convalida della replica potrebbe non essere in grado di conteggiare tutti i record necessari per un conteggio uguale.
Pianificare i controlli di convalida
Puoi pianificare l'esecuzione automatica dello strumento di convalida della replica a intervalli utilizzando la funzionalità di job in background di SAP.
Strumento Stream Records
Questo strumento non è supportato per la replica dei dati di streaming.
Lo strumento Trasmetti record ti consente di trasmettere record da SAP a Pub/Sub in base a criteri specifici. Per impostazione predefinita, crea una sottoscrizione con un filtro per trasmettere in streaming solo i record eliminati dalla tabella SAP di origine a BigQuery utilizzando l'API Storage Write tramite Pub/Sub. Tuttavia, puoi personalizzare le opzioni di filtro in base alle tue esigenze.
Per eseguire lo strumento Registra stream:
Nella GUI SAP, esegui la transazione /GOOG/BQPS_FLT_SUBS preceduta da
/n
:/n/GOOG/BQPS_FLT_SUBS
Nella schermata Record di stream, fornisci i valori per i seguenti campi:
- Chiave di trasferimento collettivo: la chiave di trasferimento collettivo che contiene le tabelle SAP.
- Nome tabella SAP: i nomi delle tabelle SAP per cui è necessario convertire tutti i mapping dei campi nel tipo
STRING
. - ID abbonamento filtro: il nome dell'abbonamento all'argomento esistente che devi creare.
- Condizione di filtro: condizione con cui viene creato l'abbonamento. Il filtro predefinito è impostato per trasmettere in streaming solo i record eliminati. Per informazioni sulla sintassi per creare un filtro, vedi Filtrare i messaggi.
Fai clic sull'icona Esegui. Per la tabella selezionata, viene creato un abbonamento con la condizione di filtro specificata.
Modificare la mappatura dei campi BigQuery in un file CSV
Le sezioni seguenti descrivono come esportare il mapping dei campi predefinito in modo che gli ingegneri dei dati o gli amministratori BigQuery possano modificare i valori dei campi di destinazione senza richiedere l'accesso a SAP LT Replication Server.
Quando modifichi i valori dei campi di destinazione, rispetta le seguenti regole:
- Non modificare i valori nelle colonne Nome tabella SAP e Nome campo SAP.
- Nella colonna Send Uncompressed Flag, per attivare la compressione dei record,
contrassegna il campo solo con
X
. In caso contrario, lascia vuoto il campo.
Crea un foglio di lavoro o un file di testo dei mapping dei campi predefiniti
Per creare un file CSV da modificare al di fuori di SAP LT Replication Server:
Esegui la transazione
/GOOG/SLT_SETTINGS
.Nella schermata Manutenzione impostazioni SLT, specifica i seguenti valori:
- Nel campo Partner Google Cloud, seleziona l'opzione di replica.
- Nel campo Tabella delle impostazioni, specifica i Campi.
- Nel campo Mass Transfer Key (Chiave di trasferimento collettivo), specifica l'ID del trasferimento collettivo che stai aggiornando.
- Nel campo Nome tabella, lascia vuoto il campo per lavorare con tutti i campi di tutte le tabelle o specifica un nome tabella per lavorare con una tabella specifica.
- Lascia vuoti tutti gli altri campi.
Fai clic sull'icona Esegui. Viene visualizzata la schermata Manutenzione impostazioni BigQuery - Campi.
Nella schermata Manutenzione impostazioni BigQuery - Campi, nascondi tutte le colonne tranne quelle dell'elenco seguente facendo clic con il tasto destro del mouse sulle intestazioni delle colonne e selezionando Nascondi dal menu a discesa:
- Nome tabella SAP
- Nome campo SAP
- Tipo Avro, applicabile per la replica CDC tramite Pub/Sub
- Elemento di dati esterni
- Nome campo esterno
- Descrizione campo
- Flag Invia non compresso
Con le colonne rimanenti visualizzate, fai clic sull'icona Esporta.
Dal menu Esporta, seleziona una delle seguenti opzioni:
- Foglio di lavoro
- File locale. Per facilitare la conversione dei contenuti del file in formato CSV, ti consigliamo di salvare il file in formato Testo con tabulazioni.
Salva i mapping dei campi predefiniti facendo clic sull'icona segno di spunta.
Convertire il foglio di lavoro o il file di testo in formato CSV
Per caricare le mappature dei campi modificate utilizzando la transazione personalizzata
/GOOG/SLT_SETTINGS
, le mappature dei campi
devono essere in formato CSV.
Se utilizzi un foglio di lavoro, salvalo come file CSV prima di caricarlo.
Se utilizzi un file locale in formato separato da tabulazione o in qualsiasi altro formato, devi modificare il file in modo che sia conforme al formato CSV.
Ad esempio:
SAP Table,SAP Field Name,AVRO Type,External Data Element,External Field Name,Field Description, Send Uncompressed Flag SAP_TABLE_NAME,SAP_FIELD_NAME1,AVRO_TYPE,EXTERNAL_DATA_ELEMENT,EXTERNAL_FIELD_NAME,FIELD_DESCRIPTION, SEND_UNCOMPRESSED_FLAG SAP_TABLE_NAME,SAP_FIELD_NAME2,AVRO_TYPE,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME2,BIGQUERY_FIELD_DESCRIPTION2, SEND_UNCOMPRESSED_FLAG2 SAP_TABLE_NAME,SAP_FIELD_NAME3,AVRO_TYPE,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME3,BIGQUERY_FIELD_DESCRIPTION3, SEND_UNCOMPRESSED_FLAG3
Carica il file CSV
Per caricare un file CSV modificato:
Esegui la transazione
/GOOG/SLT_SETTINGS
.Nella schermata Manutenzione impostazioni SLT, specifica i seguenti valori:
- Nel campo Tabella delle impostazioni, specifica i Campi.
- Nel campo Mass Transfer Key (Chiave di trasferimento collettivo), specifica l'ID del trasferimento collettivo che stai aggiornando.
- Seleziona la casella di controllo Carica da file.
Fai clic sull'icona Esegui. Viene visualizzata la finestra di dialogo Seleziona file da caricare.
Nella finestra di dialogo Seleziona il file da caricare, seleziona il file CSV che contiene i valori dei campi modificati.
Fai clic su Apri.
Se ricevi un avviso di sicurezza, fai clic su Consenti. Il file viene caricato e i valori modificati nel file vengono visualizzati nelle righe applicabili nella schermata Manutenzione impostazioni BigQuery - Campi.
Fai clic sull'icona Salva.
Per verificare che i valori siano applicati, confronta i valori nel file CSV con i valori visualizzati da SAP LT Replication Server.
Gestione degli errori nei dati di origine
Dopo aver ricevuto un blocco di record da BigQuery Connector per SAP, l'API BigQuery Streaming verifica la presenza di errori nei dati prima di inserire i record nella tabella BigQuery.
Puoi controllare il modo in cui l'API BigQuery e il BigQuery Connector per SAP rispondono quando vengono rilevati errori nei dati specificando i seguenti flag nelle impostazioni di trasferimento collettivo:
- Bandiera di
Skip Invalid Records
(SKIP
) - Bandiera di
Break at First Error Flag
(BREAK
)
Il flag SKIP
Se specifichi il flag SKIP
, quando
l'API BigQuery riceve un blocco di record e ne trova uno
con un errore di dati, l'API BigQuery scarta
o salta il record con l'errore e continua a inserire tutti gli altri
record del blocco nella tabella BigQuery.
Se non specifichi il flag SKIP
, quando BigQuery
trova un record con un errore di dati, BigQuery scarta l'intero
blocco senza inserire alcun record nella tabella
BigQuery. Questo è il comportamento standard.
La specifica del flag SKIP
è ideale per gli ambienti di sviluppo e QA
e non è consigliata per gli ambienti di produzione.
Puoi specificare il flag SKIP
nella transazione /GOOG/SLT_SETTINGS
durante la configurazione della replica. La specifica è memorizzata nella
tabella di configurazione /GOOG/BQ_MASTR
.
Per scoprire in che modo le specifiche SKIP
interagiscono con le specifiche BREAK
,
consulta la tabella della matrice per le interazioni tra SKIP
e BREAK
.
Il flag BREAK
Se specifichi il flag BREAK
, quando
BigQuery Connector per SAP riceve una notifica dall'API BigQuery che
è stato rilevato un errore nei dati di un record, BigQuery Connector per SAP interrompe
l'invio di record a BigQuery e termina il
job di replica. Questo è il comportamento standard.
Se non specifichi il flag BREAK
, quando
BigQuery Connector per SAP riceve una notifica da BigQuery che
è stato rilevato un errore nei dati di un record, BigQuery Connector per SAP continua
a inviare record a BigQuery inviando il blocco successivo
e il job di replica continua.
È consigliabile specificare il flag BREAK
negli ambienti di produzione.
Puoi specificare il flag BREAK
nella transazione /GOOG/SLT_SETTINGS
quando configuri la replica.
Quando crei una nuova chiave di trasferimento collettivo, il flag BREAK
è attivato per impostazione predefinita.
La specifica è memorizzata nella tabella di configurazione /GOOG/BQ_MASTR
.
Per scoprire in che modo le specifiche BREAK
interagiscono con le specifiche SKIP
,
consulta la tabella della matrice per le interazioni tra SKIP
e BREAK
.
Tabella della matrice per le interazioni tra SKIP
e BREAK
Puoi configurare BigQuery Connector per SAP per gestire gli errori dei dati nei seguenti modi:
SKIP flag |
BREAK flag |
Comportamento |
---|---|---|
FALSE | VERO |
BigQuery scarta il blocco corrente di record senza inserire alcun record del blocco corrente nella tabella BigQuery. BigQuery Connector per SAP non invia più blocchi di record dalla porzione corrente e indica a SAP LT Replication Server di terminare il job di replica. Questa è l'impostazione predefinita e consigliata. |
FALSE | FALSE |
BigQuery scarta il blocco corrente di record senza inserire alcun record del blocco corrente nella tabella BigQuery. BigQuery Connector per SAP invia i blocchi di record rimanenti dalla porzione corrente e recupera la porzione successiva. BigQuery Connector per SAP non indica a SAP LT Replication Server di terminare il job di replica. |
VERO | VERO |
BigQuery scarta solo il record che contiene l'errore e inserisce il resto dei record nel chunk corrente nella tabella BigQuery. BigQuery Connector per SAP non invia più blocchi di record dalla porzione corrente e indica a SAP LT Replication Server di terminare il job di replica. |
VERO | FALSE |
BigQuery scarta solo il record che contiene l'errore e inserisce il resto dei record nel chunk corrente nella tabella BigQuery. BigQuery Connector per SAP invia i blocchi di record rimanenti dalla porzione corrente e recupera la porzione successiva. BigQuery Connector per SAP non indica a SAP LT Replication Server di terminare il job di replica. |
Modifiche alla struttura della tabella
Questa sezione spiega come modificare la struttura della tabella di origine SAP per la quale è in corso una replica LTRC
esistente.
Per la replica CDC tramite Pub/Sub, lo schema Pub/Sub intermedio viene rivisto in base alle modifiche alla struttura della tabella. Quando lo schema Pub/Sub viene aggiornato, potrebbero essere necessari alcuni minuti prima che le modifiche diventino effettive. Tuttavia, non si verifica alcuna perdita di dati.
Aggiungere una colonna a una tabella di origine
Per aggiungere una nuova colonna a una tabella di origine:
Aggiungi una nuova colonna alla tabella di origine. A seguito di questo passaggio, lo stato della replica diventa
Load/Replication blocked
.Nel sistema SLT, reimposta lo stato di replica utilizzando la transazione
LTRC
. Per ulteriori informazioni da SAP su come reimpostare lo stato di replica, vedi Nota SAP 2204955 - Le tabelle SLT sono nello stato "Load /Replication blocked".Aggiungi, aggiorna o elimina una voce nella tabella di origine.
Convalida il risultato della replica in BigQuery.
Eliminare una colonna da una tabella di origine
Per eliminare una colonna esistente da una tabella di origine:
Nel sistema SLT, sospendi la replica utilizzando la transazione
LTRC
.Elimina una colonna dalla tabella di origine. A seguito di questo passaggio, gli attivatori SLT esistenti vengono eliminati o modificati in uno stato incoerente.
Per la replica CDC tramite Pub/Sub, elimina manualmente la colonna dallo schema Pub/Sub di destinazione creando una nuova revisione. Per ulteriori informazioni sui passaggi per eliminare una colonna da uno schema esistente, consulta la sezione Modificare uno schema nella documentazione di Pub/Sub.
In BigQuery, elimina la colonna dalla tabella BigQuery di destinazione. Per ulteriori informazioni sui passaggi per eliminare una colonna da una tabella esistente, consulta la documentazione di BigQuery.
Nel sistema SLT, riprendi la replica utilizzando la transazione
LTRC
.Nel sistema SLT, ricrea gli attivatori SLT. Per ulteriori informazioni da SAP su come ricreare i trigger SLT, consulta la nota SAP 2254376 - SLT trigger(s) in an inconsistent state.
Se lo stato di replica è
Load /Replication blocked
, reimposta lo stato di replica utilizzando la transazioneLTRC
. Per ulteriori informazioni da SAP su come reimpostare lo stato di replica, consulta la nota SAP 2204955 - Le tabelle SLT sono nello stato "Caricamento /Replica bloccata".Cancella i log, se presenti.
Aggiungi, aggiorna o elimina una voce nella tabella di origine.
Convalida il risultato della replica in BigQuery.
Modificare il tipo di dati di una colonna esistente
Quando modifichi il tipo di dati di una colonna esistente nella tabella di origine SAP, devi seguire passaggi specifici a seconda che tu stia modificando il tipo di dati in un tipo di dati compatibile o non compatibile con la tabella BigQuery di destinazione.
Un tipo di dati è compatibile con il tipo di dati nella tabella BigQuery di destinazione quando il tipo di dati esistente e il nuovo tipo di dati di una colonna esistente vengono mappati allo stesso tipo di dati nella tabella BigQuery di destinazione e, di conseguenza, nello schema Avro di Pub/Sub.
Ad esempio, se il tipo di dati di una colonna viene modificato da INT1
a INT2
in una tabella di origine, entrambi questi tipi di dati SAP sono considerati compatibili perché vengono mappati al tipo di dati INTEGER
in BigQuery e corrisponderebbero al tipo int
nello schema Avro di Pub/Sub.
BigQuery Connector per SAP gestisce questa mappatura internamente. Compatibilità significa che il tipo BigQuery e Pub/Sub sottostante non deve essere modificato. Per ulteriori informazioni, consulta la sezione Compatibilità dello schema.
Per ulteriori informazioni sul mapping dei tipi di dati in BigQuery Connector per SAP, vedi Mapping dei tipi di dati.
Modifica il tipo di dati impostandolo su un tipo di dati compatibile.
Per modificare il tipo di dati di una colonna esistente in un tipo di dati compatibile:
Modifica il tipo di dati in un tipo di dati compatibile nel sistema di origine. A seguito di questo passaggio, gli attivatori SLT esistenti vengono eliminati o modificati in uno stato incoerente.
Nel sistema SLT, ricrea gli attivatori SLT. Per ulteriori informazioni da SAP su come ricreare i trigger SLT, consulta la nota SAP 2254376 - SLT trigger(s) in an inconsistent state.
Se lo stato di replica è
Load /Replication blocked
, reimposta lo stato di replica utilizzando la transazioneLTRC
. Per ulteriori informazioni da SAP su come reimpostare lo stato di replica, consulta la nota SAP 2204955 - Le tabelle SLT sono nello stato "Caricamento /Replica bloccati".Cancella i log, se presenti.
Aggiungi, aggiorna o elimina una voce nella tabella di origine.
Convalida il risultato della replica in BigQuery.
Modificare il tipo di dati in un tipo di dati non compatibile
Per modificare il tipo di dati di una colonna esistente in un tipo di dati non compatibile:
- Nel sistema SLT, interrompi la replica utilizzando la transazione
LTRC
. - Per la replica CDC tramite Pub/Sub, in Pub/Sub, elimina lo schema di destinazione, la sottoscrizione BigQuery e l'argomento Pub/Sub.
- In BigQuery, elimina la tabella di destinazione.
- Modifica il tipo di dati nel sistema di origine.
- Nel sistema SLT, avvia la replica utilizzando la transazione
LTRC
.
Per ulteriori informazioni sulle modifiche alla struttura della tabella, consulta BigQuery Connector per SAP: gestisci le modifiche alla struttura della tabella come un professionista.
Gestire lo schema Pub/Sub per le modifiche alla struttura della tabella
Quando la struttura della tabella cambia, per la replica CDC tramite Pub/Sub, anche lo schema Pub/Sub intermedio viene aggiornato per riflettere le modifiche alla struttura della tabella. Il risultato è una nuova revisione dello schema.
Pub/Sub mantiene una cronologia di queste revisioni, che utilizza poi per interpretare correttamente i messaggi. Pub/Sub consente un massimo di 20 revisioni dello schema per argomento. Il superamento di questo limite può causare errori e impedire ulteriori aggiornamenti dello schema.
Quando viene raggiunto il limite di 20 revisioni dello schema, il sistema SAP SLT riceve messaggi di errore che indicano che non è possibile creare nuove revisioni dello schema. In questo caso, ricevi i seguenti errori:
Log SAP: errori nei log SLT, relativi alle operazioni Pub/Sub, ad esempio:
/GOOG/MSG : 429 - You have exceeded your revisions per schema quota (schema = SCHEMA_NAME)
Cannot create more schema revisions
Stato della replica: lo stato della replica per le tabelle interessate potrebbe cambiare in "Caricamento/Replica bloccati".
Errori Pub/Sub: errori lato Pub/Sub, che indicano che lo schema non può essere aggiornato.
Quando noti questi errori, puoi procedere nel seguente modo:
- Analizza ed elimina le revisioni dello schema precedenti: se le revisioni dello schema precedenti non sono più necessarie, eliminale utilizzando la console Google Cloud o gcloud CLI. Per saperne di più, vedi Eliminare una revisione dello schema.
Crea un nuovo schema: quando l'eliminazione delle vecchie revisioni dello schema non è un'opzione, puoi creare un nuovo schema Pub/Sub. Per creare un nuovo schema Pub/Sub, segui questi passaggi:
- Nel sistema SLT, interrompi la replica utilizzando la transazione
LTRC
. - Negli attributi della tabella, nel campo Schema Pub/Sub, aggiorna il nuovo nome dello schema.
- Nel sistema SLT, avvia la replica utilizzando la transazione
LTRC
. - Il connettore crea automaticamente un nuovo schema in base alla definizione della tabella di origine.
- Una volta verificata la replica, puoi eliminare il vecchio schema.
- Nel sistema SLT, interrompi la replica utilizzando la transazione
Uscite del miglioramento
BigQuery Connector per SAP fornisce diversi punti di miglioramento nel codice in cui uno sviluppatore ABAP può inserire codice per aggiungere funzionalità personalizzate.
La tabella seguente elenca le funzioni supportate dai punti di miglioramento, i metodi e la classe che contiene il punto di miglioramento.
Funzione | Classe | Metodo | Spot | Opzione |
---|---|---|---|---|
Aggiorna la mappatura di un campo, ad esempio il nome e il tipo di dati del campo esterno. | /GOOG/CL_IUUC_REPL_RUNTIME |
CREATE_FLD_MAPPINGS |
/GOOG/ES_IUUC_REPL_RUNTIME |
/GOOG/UPDATE_FIELD_MAPPING |
Aggiorna la mappatura per la tabella dei campi aggiungendo o rimuovendo campi. | /GOOG/CL_IUUC_REPL_RUNTIME |
CREATE_FLD_MAPPINGS |
/GOOG/ES_IUUC_REPL_RUNTIME |
/GOOG/UPDATE_FIELD_MAPPINGS |
Modifica il valore di un campo di origine prima che venga convertito in un campo di destinazione. | /GOOG/CL_IUUC_REPL_RUNTIME_BQ |
FILL_TARGET_RECORDS |
/GOOG/ES_IUUC_REPL_RUNTIME_BQ |
/GOOG/CHANGE_SOURCE_FIELD |
Dopo che un campo di origine viene convertito in un campo di destinazione nella tabella di destinazione, modifica il valore del campo di destinazione. | /GOOG/CL_IUUC_REPL_RUNTIME_BQ |
FILL_TARGET_RECORDS |
/GOOG/ES_IUUC_REPL_RUNTIME_BQ |
/GOOG/FILL_TARGET_FIELD |
Aggiungi un campo alla tabella di destinazione che non esiste nella tabella di origine durante la conversione da tabella di origine a tabella di destinazione. | /GOOG/CL_IUUC_REPL_RUNTIME_BQ |
FILL_TARGET_RECORDS |
/GOOG/ES_IUUC_REPL_RUNTIME_BQ |
/GOOG/FILL_EXTRA_FIELD |
Prepara un campo dello schema BigQuery prima di creare la tabella BigQuery. | /GOOG/CL_GCP_CLIENT_BQ |
PREP_BQ_TABLE_SCHEMA |
/GOOG/ES_GCP_CLIENT_BQ |
/GOOG/PREPARE_SCHEMA_FIELD |
In caso di errori HTTP generati sul lato server Pub/Sub, per risolvere il problema, puoi raccogliere i dati di logging dopo le chiamate HTTP all'API Pub/Sub. | /GOOG/CL_GCP_CLIENT_PUBSUB_SLT |
PUBLISH_DATA_CHUNKS |
/GOOG/ES_GCP_CLIENT_BQCPS_SLT |
/GOOG/LOG_INSERT_ERROR |
In caso di errori HTTP lato server BigQuery, per risolvere il problema, puoi raccogliere i dati di logging dopo le chiamate HTTP all'API BigQuery. | /GOOG/CL_GCP_CLIENT_BQ_SLT |
INSERT_TABLEDATA |
/GOOG/ES_GCP_CLIENT_BQ_SLT |
/GOOG/LOG_INSERT_ERROR |
In caso di errori HTTP generati sul lato client SAP, per risolvere il problema, puoi raccogliere i dati di logging. | /GOOG/CL_GCP_HTTP_CLIENT |
RECEIVE_HTTP_RESPONSE |
/GOOG/ES_GCP_HTTP_CLIENT |
/GOOG/RECEIVE_HTTP_RESPONSE |
In caso di errori HTTP lato server BigQuery, per risolvere il problema, puoi raccogliere i dati di logging dopo le chiamate HTTP all'API BigQuery. | /GOOG/CL_GCP_CLIENT_BQ_SLT |
INSERT_TABLEDATA |
/GOOG/ES_GCP_CLIENT_BQ_SLT |
/GOOG/LOG_RETURN_STATUS |
Impostazioni avanzate
Se vuoi, puoi modificare le impostazioni avanzate per BigQuery Connector for SAP. Google Cloud consiglia di modificare i parametri delle impostazioni avanzate solo dopo un'analisi completa e dell'impatto dei nuovi valori sul rendimento. È tua responsabilità assicurarti che le nuove impostazioni avanzate per BigQuery Connector per SAP non causino errori e problemi di prestazioni.
Le impostazioni avanzate per BigQuery Connector per SAP vengono applicate a livello di sistema e sono comuni a tutte le chiavi di trasferimento collettivo. Se i parametri delle impostazioni avanzate non vengono modificati, BigQuery Connector per SAP funziona con le impostazioni predefinite.
Per modificare i parametri delle impostazioni avanzate:
Nella GUI di SAP, inserisci la transazione
/GOOG/SLT_SETTINGS
preceduta da/n
:/n/GOOG/SLT_SETTINGS
Nel menu a discesa Tabella delle impostazioni nella schermata di avvio della transazione
/GOOG/SLT_SETTINGS
, seleziona Parametri.Fai clic sull'icona Esegui. Viene visualizzata la schermata Manutenzione impostazioni BigQuery - Parametri.
Fai clic sull'icona Inserisci riga.
Nella riga visualizzata, specifica le seguenti impostazioni:
- Nel campo Nome parametro, inserisci il nome del parametro. La descrizione del parametro viene compilata automaticamente.
Nel campo Valore parametro, inserisci un valore.
Per informazioni sui parametri delle impostazioni avanzate, consulta Parametri delle impostazioni avanzate.
Fai clic su Salva.
Le impostazioni avanzate vengono memorizzate come record nella tabella di configurazione
/GOOG/BQ_PARAM
e i campi Modificato da, Modificato il e Modificato alle vengono compilati automaticamente.
Parametri delle impostazioni avanzate
La tabella seguente mostra i parametri delle impostazioni avanzate per BigQuery Connector per SAP.
Nome parametro | Descrizione | Valore predefinito | Valore valido |
---|---|---|---|
CHUNK_SIZE_DEF |
Questa è la dimensione predefinita dei blocchi supportata da BigQuery Connector per SAP. Se nelle impostazioni non viene mantenuta una dimensione del blocco, viene utilizzata la dimensione predefinita del blocco. Utilizza questo parametro solo con la replica dei dati di streaming in BigQuery. |
10.000 | Il valore deve rientrare nei limiti di quota di BigQuery. |
PERC_REDUC_DEF |
La riduzione percentuale delle dimensioni del blocco. Se la dimensione dinamica dei blocchi è abilitata, la dimensione dei blocchi viene ridotta di questa percentuale finché non viene raggiunta una dimensione ideale dei blocchi e i dati nel blocco vengono trasferiti a BigQuery correttamente. |
50 | Il valore deve essere compreso tra 1 e 99. |
CMD_EXEC_TRIES |
Per i sistemi SAP che non vengono eseguiti su Google Cloud, se il
comando del sistema operativo creato nella transazione SM69
non riesce a recuperare un token di accesso da Google Cloud, questo
è il numero di tentativi di recupero del token eseguiti da BigQuery Connector per SAP.
|
5 | Il valore minimo che puoi assegnare a questo parametro è
1 . Per facilitare almeno un nuovo tentativo, imposta il valore
2 . Il valore massimo di questo parametro deve essere impostato dopo
aver analizzato l'impatto che i nuovi tentativi di recupero dei token possono avere sulle
prestazioni della replica.
|
CMD_SECS_DEFLT |
Se hai attivato la memorizzazione nella cache dei token, questa è la durata in secondi dopo la quale il token memorizzato nella cache scade. | 3500 | Il valore deve essere compreso tra 1 e 3599. |