Betriebsanleitung für BigQuery-Connector für SAP

In dieser Anleitung wird beschrieben, wie SAP LT Replication Server-Administratoren, SAP-Data-Engineers oder andere Personen operative Aufgaben wie die Leistungsoptimierung und Versionsaktualisierungen für Version 2.5 (aktuell) von BigQuery-Connector für SAP ausführen.

Replikationsleistung optimieren

Die Replikationsleistung kann von mehreren Faktoren beeinflusst werden. Die spezifischen Faktoren können sich von Installation zu Installation unterscheiden und sich im Laufe der Zeit ändern.

In den folgenden Abschnitten wird erläutert, wie Sie einige gängige Faktoren optimieren, die sich auf die Leistung auswirken können.

Weitere Informationen zur Replikationsleistung bei BigQuery-Connector für SAP finden Sie unter Leistungsplanung.

Leistungsoptionen für Tabellen festlegen

In SAP LT Replication Server können Sie Replikationsoptionen für jede Tabelle angeben, die sich auf die Leistung auswirkt.

Insbesondere die Replikationsleistung für große Tabellen, die mehr Zeit und Ressourcen für die Replikation erfordern, kann von der Angabe von Bereichen und der Erhöhung der maximalen Anzahl paralleler Replikationsjobs, die für die Tabelle verwendet werden können, profitieren.

Beispiele für häufig groß werdende Tabellen sind MSEG, ACDOCA und MATDOC.

Wenn Sie parallele Replikationsjobs für große Tabellen angeben, müssen Sie die Anzahl der für eine bestimmte Tabelle zulässigen parallelen Jobs mit der Gesamtzahl der parallelen Jobs abstimmen, die in der Massenübertragungskonfiguration zulässig ist. Ihre Organisation kann auch die Anzahl der parallelen Replikationsjobs begrenzen, die Sie für einen bestimmten Server angeben können.

So legen Sie Leistungsoptionen für eine Tabelle fest:

  1. Geben Sie in der SAP-GUI die SAP-Transaktion LTRS ein.

  2. Geben Sie auf dem Bildschirm Erweiterte Replikationseinstellungen die ID der Massenübertragungseinstellungen für die Tabelle an.

  3. Klicken Sie in der Ordnerhierarchie Erweiterte Replikationseinstellungen auf den Ordner Leistungsoptionen, um die Tabellen anzuzeigen, für die Leistungsoptionen definiert sind.

  4. Wenn die gewünschte Tabelle nicht aufgeführt ist, klicken Sie mit der rechten Maustaste auf den Ordner Leistungsoptionen und wählen Sie Tabelle hinzufügen aus.

  5. Geben Sie einen Namen für die Tabelle an.

  6. Geben Sie nach Bedarf die folgenden Optionen an:

    • Unter Allgemeine Leistungsoptionen:
      • Anzahl der parallelen Jobs, um die maximale Anzahl paralleler Replikationsjobs festzulegen, die für die Tabelle verwendet werden können.
      • Sequenznummer, um die Replikation dieser Tabelle im Vergleich zu anderen Tabellenreplikationen zu priorisieren.
    • Unter Optionen für anfängliches Laden:
      • Wählen Sie für Lesetyp die Option Lesetyp 1 Bereichsberechnung aus, wenn Ihre Tabelle nicht zu groß ist. Weitere Informationen finden Sie unter Leistung und erweiterte LTRS-Replikationseinstellungen.
      • Geben Sie unter Paketgröße in Byte die Größe der Datensatzbereiche an, die an SAP LT Replication Server gesendet werden.
      • Wenn Sie einen Lesetyp auswählen, der Bereiche verwendet, definieren Sie die entsprechenden Bereiche.
    • Unter Replikationsoption:
      • Geben Sie für Bereiche für Logging-Tabelle die Option Keine Bereiche an, um die zuverlässigste Option zu verwenden.
      • Wenn Sie Bereiche für manuell angeben auswählen, definieren Sie die entsprechenden Bereiche.

  7. Klicken Sie auf Speichern.

Baseline-Leistungsbenchmark

Damit Sie die Replikationsleistung besser bewerten können, enthält dieser Abschnitt Baseline-Leistungszahlen, die in Google Cloud-Testsystemen beobachtet wurden.

Aufgrund der vielen verschiedenen Faktoren, die sich auf die Leistung auswirken, variieren Ihre Leistungszahlen wahrscheinlich.

Wenn Ihre SAP-Systeme beispielsweise nicht in Google Cloud ausgeführt werden, sind die Last- und Replikationsraten aufgrund von Netzwerklatenz und dem mit Zugriffstokens verbundenen Overhead möglicherweise langsamer als die Baseline-Raten. Wenn Ihre Quelltabelle weniger Spalten enthält oder Sie SAP LT Replication Server auf einem eigenen Server in einer eigenständigen Architektur installieren, sind Ihre Raten möglicherweise schneller, da SAP LT Replication Server nicht mit den Quellsystem um Ressourcen konkurrieren muss.

Beobachtete Baseline-Leistungszahlen

Die folgenden Leistungszahlen stellen die Baseline-Leistung dar, die von Google Cloud für jeden Quellsystemtyp während der Tests beobachtet wurde. In jedem Testsystem wurde SAP LT Replication Server in dem SAP-Quellsystem in einer eingebetteten Architektur auf Compute Engine-VMs installiert. Das SAP-Quellsystem wurde in derselben Google Cloud-Region wie das BigQuery-Ziel-Dataset ausgeführt.

Informationen zur Konfiguration der Testsysteme finden Sie unter Systemkonfiguration für Baseline-Leistungstests.

Klicken Sie auf den Typ Ihres Quellsystems, um die Leistungszahlen anzuzeigen:

S/4HANA

  • Tabelle: ACDOCA
    • 343 Millionen Datensätze
    • 477 Spalten
  • Anfänglicher Ladevorgang
    • Laderate: durchschnittlich 350 Millionen Datensätze pro Stunde
    • Ladedauer: durchschnittlich 59 Minuten
  • Replikation
    • Änderungsrate der Quelltabelle: durchschnittlich 50 Millionen Datensätze pro Stunde
    • Maximale Replikationsrate: durchschnittlich 50 Millionen Datensätze pro Stunde

ECC

  • Tabelle: MSEG
    • 203 Millionen Datensätze
    • 188 Spalten
  • Anfänglicher Ladevorgang
    • Laderate: durchschnittlich 385 Millionen Datensätze pro Stunde
    • Ladedauer: durchschnittlich 32 Minuten
  • Replikation
    • Änderungsrate der Quelltabelle: durchschnittlich 50 Millionen Datensätze pro Stunde
    • Maximale Replikationsrate: durchschnittlich 69 Millionen Datensätze pro Stunde

Die obigen Leistungszahlen sind die von den Google Cloud-Testern beobachteten Baselines.

Die beobachtete Leistung war in Testsystemen mit den folgenden Attributen besser:

  • SAP LT Replication Server wurde auf einer eigenen VM in einer eigenständigen Architektur installiert.
    • Bei S/4HANA-Systemen wurde festgestellt, dass eine eigenständige Architektur aufgrund der unabhängigen Skalierung der SAP LT Replication Server-Prozesse eine um etwa 42 % schnellere anfängliche Laderate als eine eingebettete Architektur hat.
    • Bei ECC-Systemen wurde festgestellt, dass eine eigenständige Architektur aufgrund der unabhängigen Skalierung der SAP LT Replication Server-Prozesse eine um etwa 10 % schnellere anfängliche Laderate als eine eingebettete Architektur hat.
  • Die Quelltabelle enthielt weniger Spalten.
  • Die Gesamtbytegröße der Datensätze war kleiner.

Informationen zu den Systemattributen, die Sie zur Leistungsverbesserung ändern können, finden Sie unter:

Systemkonfiguration für Baseline-Leistungstests

Die in diesem Abschnitt beschriebenen Testsysteme haben die Baseline-Leistungszahlen erzeugt, die im vorherigen Abschnitt Beobachtete Baseline-Leistungszahlen aufgeführt sind.

Die Testsysteme, einschließlich SAP-Quellsystem, SAP LT Replication Server und BigQuery-Dataset, wurden alle auf Compute Engine-VMs in derselben Google Cloud-Region ausgeführt.

In jedem System wurden die Server und die Arbeitslast dafür eingerichtet, eine höhere Arbeitslast und ein höheres Replikationsvolumen zu simulieren, als Sie in vielen realen Installationen finden werden.

Klicken Sie auf den Typ Ihres Quellsystems, um die Testsystemattribute aufzurufen:

S/4HANA

  • Installationsarchitektur von LT Replication Server:
    • Eingebettete Architektur
  • Quellsystemserver:
    • Zwei Anwendungsserver, jeweils auf einem N2-basierten benutzerdefinierten Maschinentyp von Compute Engine mit den folgenden Spezifikationen:
      • vCPUs: 60
      • Arbeitsspeicher: 324 GB
      • CPU-Plattform: Intel Cascade Lake
    • Ein SAP HANA-Server auf einer Compute Engine-VM m1-ultramem-80 mit den folgenden Spezifikationen:
      • vCPUs: 80
      • Arbeitsspeicher: 1.900 GB
      • CPU-Plattform: Intel Broadwell
  • Software-Versionen:
    • S/4HANA 1909
    • SAP LT Replication Server: S/4CORE 104 SP00
  • Tabellengröße:
    • Tabellenname: ACDOCA, allgemeine Positionsdaten von Ledger-Journal-Datensätzen
    • Anzahl der Datensätze: 343 Millionen
    • Spaltenanzahl: 477
  • Arbeitsprozesse auf jedem Anwendungsserver:
    • 60 Dialogprozesse
    • 220 Hintergrundprozesse
  • Ladeeinstellungen in SAP LT Replication Server:
    • Jobs: 99
    • Lesetyp: 1 Bereich
    • Berechnung: Automatische Bereiche
  • Replikationseinstellungen:
    • Jobs: 99
    • Schlüsselfelder zur Berechnung von Bereichen für die Logging-Tabelle verwenden
    • 128 Bereiche

ECC

  • Installationsarchitektur von LT Replication Server:
    • Eingebettete Architektur
  • Quellsystemserver:
    • Zwei Anwendungsserver auf jeweils einer n2-highmem-48 Compute Engine-VM mit den folgenden Spezifikationen:
      • vCPUs: 60
      • Arbeitsspeicher: 348 GB
      • CPU-Plattform: Intel Cascade Lake
  • Software-Versionen:
    • SAP NetWeaver: 7.0 EHP2
    • SAP LT Replication Server: DMIS 2011_1_700 SP17
  • Tabellengröße:
    • Tabelle: MSEG, Dokumente zur Materialinventarverwaltung
    • Anzahl der Datensätze: 203 Millionen
    • Spaltenanzahl: 188
  • Arbeitsprozesse auf jedem Anwendungsserver:
    • 60 Dialogprozesse
    • 100 Hintergrundprozesse
  • Ladeeinstellungen in SAP LT Replication Server:
    • Jobs: 99
    • Lesetyp: 5 Sender
    • Warteschlange: Manuelle Bereiche
  • Replikationseinstellungen:
    • Jobs: 99
    • Bereiche für Logging-Tabelle: Bereiche mithilfe von Schlüsselfeldern berechnen
    • Anzahl der Bereiche: 128

Dynamische Blockgröße

Wenn Fehler auftreten, weil die Bytegröße der Blöcke die maximale Bytegröße für HTTP-Anfragen überschreitet, die von BigQuery akzeptiert wird, müssen Sie die Bytegröße manuell reduzieren, indem Sie die Blockgröße verringern. Mit der dynamischen Blockgröße können Sie die Blockgröße automatisch reduzieren und einen Replikationsversuch in BigQuery wiederholen, wenn die Bytegröße eines Blocks die maximale Bytegröße für HTTP-Anfragen überschreitet, die von BigQuery akzeptiert wird. Mit der dynamischen Blockgröße können Sie die meisten Replikationsfehler verhindern, die auftreten, wenn die Bytegröße einer Anfrage überschritten wird. Sie können nur dann einen Fehler erhalten, wenn die Blockgröße 1 erreicht, die Bytegröße jedoch größer als das BigQuery-Limit für die Anzahl von Byte in jeder HTTP-Anfrage bleibt.

Sie aktivieren die dynamische Blockgröße in der Massenübertragungskonfiguration für eine Tabelle mit der Transaktion /GOOG/SLT_SETTINGS. Die dynamische Blockgröße ist eine optionale Einstellung. Informationen zum Aktivieren der dynamischen Blockgröße finden Sie hier:

Wenn die dynamische Blockgröße aktiviert ist, verbleibt die maximale Blockgröße, die BigQuery-Connector für SAP zulässt, innerhalb der BigQuery-Kontingentlimits von 50.000 Einträgen.

Weitere Informationen zur Blockgröße finden Sie unter Teilgröße und Blockgröße.

Funktionsweise der dynamischen Blockgröße

Bei einer dynamischen Blockgröße reduziert BigQuery-Connector für SAP die Blockgröße und versucht noch einmal das Senden der Daten, wenn die HTTP-Anfrage mit der ursprünglichen Blockgröße das BigQuery-Limit für die Bytegröße überschreitet. BigQuery-Connector für SAP reduziert die Blockgröße und versucht noch einmal, die Daten an BigQuery zu senden, bis die Daten für einen bestimmten Block erfolgreich übertragen wurden oder bis die Blockgröße 1 erreicht.

Die endgültige reduzierte Blockgröße, für die die Datenübertragung erfolgreich war, wird dann als Blockgröße für alle verbleibenden Blöcke dieses Teils verwendet. Sie finden die endgültige reduzierte Blockgröße, die für jeden Teil erfolgreich war, in den SAP LT Replication Server-Anwendungslogs als Informationseintrag:

Dynamic chunking triggered. Chunk size reduced from INITIAL_CHUNK_SIZE_VALUE to FINAL_REDUCED_CHUNK_SIZE_VALUE

Für die nachfolgenden Teile und alle nachfolgenden Replikationen sendet BigQuery-Connector für SAP Daten mit der in Transaktion /GOOG/SLT_SETTINGS konfigurierten Blockgröße an BigQuery und reduziert die Blockgröße weiter, wenn die dynamische Blockaufteilung ausgelöst wird.

Standardmäßig wird die Blockgröße nach jedem Wiederholungsversuch um 50 % reduziert. Wenn Sie die Blockgröße um einen niedrigeren oder höheren Prozentsatz reduzieren möchten, ändern Sie die Parameter in den erweiterten Einstellungen.

Betrachten wir ein Beispiel dafür, wie die Blockgröße im Replikationsprozess bestimmt wird, wenn die dynamische Blockgröße für eine Tabelle aktiviert ist. In diesem Beispiel ist die SAP LT Replication Server-Teilgröße größer als die Blockgröße von BigQuery-Connector für SAP und die Blockgröße von 10.000 Datensätzen ist in der Transaktion /GOOG/SLT_SETTINGS definiert. BigQuery-Connector für SAP repliziert einen Teil so nach BigQuery:

  1. Wenn die Replikation für einen Teil beginnt, der 20.000 Datensätze enthält, beträgt die Blockgröße für den ersten Block 10.000 Einträge. Wenn die Bytegröße für die HTTP-Anfrage jedoch größer als 10 MB ist, reduziert BigQuery-Connector für SAP die Blockgröße um 50 % und die neue Blockgröße beträgt 5.000 Datensätze.

  2. BigQuery-Connector für SAP versucht, die Blockgröße von 5.000 Datensätzen zu senden. Wenn die Bytegröße für HTTP-Anfragen jedoch immer noch größer als 10 MB ist, reduziert BigQuery-Connector für SAP die Blockgröße weiter um 50 % und die neue Blockgröße beträgt 2.500 Datensätze.

  3. BigQuery-Connector für SAP versucht, die Blockgröße von 2.500 Datensätzen zu senden. Wenn die Bytegröße für die HTTP-Anfrage für diesen Block jetzt kleiner als 10 MB ist, ist die Replikation erfolgreich und die Daten werden in BigQuery eingefügt.

  4. Die Blockgröße für alle nachfolgenden Blöcke wird zu 2.500 Datensätzen, solange die Bytegröße für jede HTTP-Anfrage kleiner als 10 MB ist. Wenn die Bytegröße der HTTP-Anfrage für einen nachfolgenden Block 10 MB überschreitet, reduziert BigQuery-Connector für SAP die Blockgröße noch einmal und versucht, die Daten an BigQuery zu senden, bis die Daten für einen bestimmten Block erfolgreich übertragen wurden. Die reduzierte Blockgröße wird nur für den aktuellen Teil der aktuellen Replikation verwendet.

Leistung mit dynamischer Blockgröße

Die dynamische Blockgröße kann sich auf die Leistung der Replikation in BigQuery auswirken. Für jeden Block berechnet BigQuery-Connector für SAP die Anzahl der Datensätze in einem Block und prüft die Bytegröße der HTTP-Anfragen. Wenn die Bytegröße größer als 10 MB ist, reduziert BigQuery-Connector für SAP die Blockgröße und versucht, die Daten an BigQuery zu senden, wodurch die Gesamtreplikationszeit erhöht wird.

Verwenden Sie die dynamische Blockgröße nur in bestimmten Situationen, wenn die Anfragegröße selbst nach der Konfiguration einer idealen Blockgröße für einige Datensätze möglicherweise das HTTP-Anfragelimit von BigQuery überschreitet und Sie keinen Fehler aufgrund der Blockgröße erhalten möchten. Beispiel:

  • Quelltabellen, die eine große Varianz in Bezug auf die dünne Besetzung der Daten in den Feldern aufweisen (bei einigen Datensätzen werden weniger Felder genutzt, während bei einigen Datensätzen viele Felder genutzt werden).
  • Quelltabellen, die lange Textfelder wie EDID4-SDATA, VARI-CLUSTID und REPOSRC-DATA enthalten.

Sie können die dynamische Blockgröße auch während der Testphase verwenden, um eine ideale Blockgröße für eine Tabelle zu ermitteln, um Sie in Ihrem SAP-Produktionssystem zu definieren.

Weitere Informationen zum Konfigurieren der Blockgröße hier:

  • Wenn SAP LT Replication Server auf einer Compute Engine-VM ausgeführt wird, finden Sie weitere Informationen unter Tabellenattribute angeben.
  • Wenn SAP LT Replication Server auf einem Host außerhalb von Google Cloud ausgeführt wird, finden Sie weitere Informationen unter Tabellenattribute angeben.

Einstellungen für die Massenübertragung in die Produktion transportieren

Wenn Sie Massenübertragungseinstellungen in die Produktion übertragen möchten, exportieren Sie zuerst die Einstellungen aus einem Entwicklungssystem und importieren sie diese dann in das Produktionssystem.

Sie können optional drei separate Teile der Einstellungen einer Massenübertragung in die Produktion importieren:

  • Die erweiterten Replikationseinstellungen, auf die über die Transaktion LTRS zugegriffen werden kann.
  • Die Clientschlüsseleinstellungen aus der Tabelle /GOOG/CLIENT_KEY, auf die über die Transaktion SM30 zugegriffen werden kann.
  • BigQuery Connector für SAP – die Einstellungen für die Massenübertragung, auf die mit der Transaktion /GOOG/SLT_SETTINGS zugegriffen werden kann.

Massenübertragungseinstellungen aus einem Entwicklungssystem exportieren

Exportieren Sie im SAP LT Replication Server-Entwicklungssystem jeden Teil der Massenübertragungseinstellungen:

  1. Exportieren Sie die erweiterten Replikationseinstellungen:

    1. Führen Sie die Transaktion LTRS aus.
    2. Wählen Sie die Massenübertragungsdatensätze aus, die Sie in die Produktion übertragen.
    3. Wählen Sie im Drop-down-Menü Datei die Option Alle Einstellungen exportieren aus.
    4. Wählen Sie im Dialogfeld Exporteinstellungen ein Ziel aus und klicken Sie auf Speichern. Die Einstellungen werden in einer komprimierten Datei im CSV-Format auf Ihrer lokalen Workstation gespeichert.

  2. Exportieren Sie die BigQuery-Connector für SAP-Übertragung-Massenübertragungseinstellungen:

    1. Führen Sie die Transaktion /GOOG/SLT_SETTINGS aus:

      /n/GOOG/SLT_SETTINGS

    2. Wählen Sie im Feld Einstellungstabelle die Option Massenübertragung aus.

    3. Wählen Sie die Massenübertragungsdatensätze aus, die Sie in die Produktion übertragen.

    4. Klicken Sie auf Massentransfer übertragen.

    5. Geben Sie in die Eingabeaufforderung für Workbench-Anfrage die Nummer der Übertragungsanfrage ein und klicken Sie auf Weiter. Für jeden ausgewählten Massenübertragungsdatensatz sind die Einstellungen aus den folgenden benutzerdefinierten Konfigurationstabellen in der Übertragung enthalten:

      • /GOOG/BQ_MASTR
      • /GOOG/BQ_TABLE
      • /GOOG/BQ_FIELD

    Die Einstellungen für die Massenübertragung werden in einer Übertragungsanfrage gespeichert.

  3. Exportieren Sie die Einstellungen für den Clientschlüssel, indem Sie den Inhalt der Tabelle /GOOG/CLIENT_KEY manuell in die Übertragungsanfrage aufnehmen.

  4. Speichern Sie die Dateien auf Ihrer lokalen Workstation.

Massenübertragungseinstellungen in ein Produktionssystem importieren

Importieren Sie in das SAP LT Replication Server-Produktionssystem alle Teile der Massenübertragungseinstellungen:

  1. Erstellen Sie eine SAP LT Replication Server-Replikationskonfiguration für die Massenübertragungseinstellungen.

  2. Importieren Sie die erweiterten Replikationseinstellungen:

    1. Führen Sie die Transaktion LTRS aus.
    2. Wählen Sie die im ersten Schritt erstellte Massenübertragung aus.
    3. Wählen Sie im Drop-down-Menü Datei die Option Alle Einstellungen importieren aus.
    4. Wählen Sie im Dialogfeld Datei auswählen die komprimierte Datei von Ihrer lokalen Workstation aus und klicken Sie auf Öffnen. Die Einstellungen werden als Einstellungen für die Massenübertragung importiert.

  3. Importieren Sie die Übertragungsanfrage, die die Massenübertragungseinstellungen enthält.

  4. Führen Sie die Transaktion SM30 aus.

  5. Aktualisieren Sie die Clientschlüsseleinstellungen nach Bedarf für die Produktionsumgebung.

  6. Führen Sie die Transaktion /GOOG/SLT_SETTINGS aus:

    /n/GOOG/SLT_SETTINGS

  7. Prüfen Sie, ob im Bildschirm Massenübertragungen die Massenübertragungen angezeigt werden.

  8. Ersetzen Sie in der Spalte Massenübertragungs-ID die Massenübertragungs-ID aus dem Entwicklungssystem durch die Massenübertragungs-ID aus der Replikationskonfiguration, die Sie im ersten Schritt erstellt haben.

  9. Aktualisieren Sie in den nachfolgenden Einstellungsbildschirmen für Tabellen und Felder weitere Werte für die Zuordnung von Tabellen und Feldern, die für die Produktionsumgebung erforderlich sind.

  10. Starten Sie einen anfänglichen Ladevorgang oder eine Replikation, um die Konfiguration zu testen. Weitere Informationen zum Starten eines anfänglichen Ladevorgangs oder einer Replikation finden Sie unter:

    • Wenn SAP LT Replication Server auf einer Compute Engine-VM ausgeführt wird, finden Sie weitere Informationen unter Replikation testen.
    • Wenn SAP LT Replication Server auf einem Host außerhalb von Google Cloud ausgeführt wird, finden Sie weitere Informationen unter Replikation testen.

BigQuery-Connector für SAP aktualisieren

Google Cloud stellt neue Releases von BigQuery-Connector für SAP als SAP-Transporte bereit.

SAP-Administratoren können BigQuery Connector für SAP so aktualisieren:

  1. Deaktivieren Sie die Konfiguration in SAP LT Replication Server.
  2. Importieren Sie die neue SAP-Transport-Anfrage.
  3. Nachdem Sie die erfolgreiche Import- und Objektaktivierung validiert haben, aktivieren Sie die Konfiguration in SAP LT Replication Server.

gcloud CLI aktualisieren

Sie müssen Google Cloud-CLI auf dem SAP LT Replication Server-Host aktualisieren.

Weitere Informationen zum Verwalten der gcloud-Befehlszeile finden Sie unter Komponenten der gcloud CLI verwalten.

Monitoring

Sie können mehrere verschiedene Punkte entlang des Datenpfads von der SAP-Datenquelle zur BigQuery-Zieltabelle überwachen, darunter:

  • Infrastruktur – Netzwerk, Hardware und Betriebssystem
  • SAP-Datenbankebene
  • SAP-Anwendungsebene
  • BigQuery-Connector für SAP
  • BigQuery

Ihre Monitoring-Optionen an jeder dieser Stellen werden in den folgenden Unterabschnitten erläutert.

Infrastruktur überwachen

In Google Cloud können Sie den Ops-Agent auf Ihren Host-VMs für erweitertes Monitoring und Logging installieren. Der Ops-Agent sendet die Daten an Cloud Monitoring in der Google Cloud Console.

Weitere Informationen finden Sie unter:

Für Systeme, die nicht in Google Cloud ausgeführt werden, können Sie auch Serverinformationen abrufen, indem Sie SAP-Transaktionen ausführen, z. B. die Transaktion ST06.

Datenbankebene überwachen

Verwenden Sie SAP-Standardtransaktionscodes, um den Zustand der Datenbank zu überwachen.

Der Transaktionscode DBACOCKPIT ist die gängigste Transaktion zur Überwachung der Datenbank. Diese Transaktion bietet außerdem detaillierte Logs, die Sie zur Fehlerbehebung verwenden können.

Für SAP HANA können Sie SAP HANA Studio für SAP HANA-Vorgänge verwenden. Sie können SAP HANA Studio auf jedem Frontend-Computer installieren.

Prüfen Sie bei der Behebung von Leistungs- oder anderen Problemen Folgendes in der Quelldatenbank:

  • Teure SQL-Anweisungen
  • Sperren
  • Ladeverlauf
  • Indexe
  • Verfahren

Anwendungsebene überwachen

Sie können Tools für SAP-Monitoring- und -Fehlerbehebung für Anwendungen verwenden, um BigQuery-Connector für SAP zu überwachen und Fehler zu beheben, da es auf Anwendungsebene ausgeführt wird.

SAP-Monitoring und -Fehlerbehebung für Anwendungen können in folgende Kategorien unterteilt werden:

  • Standardmäßiges SAP-Monitoring- und standardmäßige SAP-Fehlerbehebung
  • BigQuery-Connector für SAP-Monitoring und -Fehlerbehebung

Für größere Umgebungen können Sie SAP Solution Manager als zentrales Monitoring-Tool verwenden.

Sie können die SAP-Transaktionscodes in der folgenden Liste verwenden, um Probleme in einzelnen SAP-Anwendungssystemen zu überwachen und zu diagnostizieren:

  • SLT-Konfigurationsstatus: LTRC
  • SLT-Fehler und -Logs: LTRO und SLG1
  • Internet Communication Manager (HTTP- und HTTPS-Aufrufe): SMICM
  • Sicherheit und Zertifikate: STRUST
  • SAP-Transporte: STMS
  • RFC-Verbindungen: SM59
  • Betriebssystembefehl: SM69
  • Paketprüfung: SE80
  • Autorisierungsprüfungen: SU53
  • Hintergrundjobs: SM37
  • Systemlogs: SM21

BigQuery überwachen

Mit Cloud Monitoring können Sie BigQuery-Messwerte aufrufen und Diagramme und Benachrichtigungen erstellen. Jeder Messwert hat einen Ressourcentyp, entweder bigquery_dataset, bigquery_project oder global, sowie einen Satz von Labels.

Verwenden Sie die Ressourcentypen und -labels, um Abfragen in Monitoring Query Language (MQL) zu erstellen.

Mithilfe der Labels können Sie jeden Messwert gruppieren oder filtern.

Weitere Informationen zu Monitoring finden Sie in der Dokumentation zu Cloud Monitoring.

Lastsimulationstool

Dieser Abschnitt bietet einen Überblick über das Lastsimulationstool und darüber, was Sie damit tun können.

Das Lastsimulationstool ist ein Unterstützungstool für BigQuery-Connector für SAP, mit dem Sie die Replikation von SAP-Daten in BigQuery simulieren können. Das Tool ist Teil des Transports, den Google Cloud für BigQuery-Connector für SAP bereitstellt. Sie verwenden das Lastsimulationstool, um Quell-SAP-Daten in BigQuery zu replizieren, indem Sie das Business Add In (BAdI) von BigQuery-Connector für SAP direkt aufrufen. Da das Lastsimulationstool kein zugrunde liegendes SLT-Framework verwendet, sind die SLT-Trigger nicht betroffen. Verwenden Sie das Lastsimulationstool nicht für die Datenreplikation in Produktionsumgebungen.

Das Lastsimulationstool bietet einen Bericht, den Sie analysieren können, um die Replikationsleistung zu bewerten, potenzielle Probleme zu identifizieren, die Ursache von Problemen zu verstehen und sie vor der tatsächlichen Replikation von SAP-Daten in BigQuery mit BigQuery-Connector für SAP zu beheben.

Im Folgenden sind einige gängige Anwendungsfälle aufgeführt, in denen Sie das Lastsimulationstool verwenden können:

  • Reproduzieren und beheben Sie Probleme mit der Netzwerkverbindung, der Autorisierung und der Authentifizierung.
  • Generieren Sie erweiterte Logs der BigQuery API-Aufrufe zur Fehlerbehebung.
  • Wenn Sie Hilfe bei der Fehlerbehebung von Cloud Customer Care benötigen, führen Sie das Lastsimulationstool aus und stellen Sie dem Customer Care-Team Logs bereit.
  • Bestimmen Sie die Leistungsmesswerte, indem Sie die für jeden Schritt im Replikationsprozess benötigte Zeit angeben.
  • Bestimmen Sie für SAP LT Replication Server in einer eingebetteten Architektur eine optimale Blockgröße für die SAP-Tabellen.

Verwenden Sie mit dem Lastsimulationstool eine Beispielkonfiguration für die Massenübertragung, die Sie mit der benutzerdefinierten Transaktion /GOOG/SLT_SETTINGS erstellen. Verwenden Sie für die Ausführung des Lastsimulationstools nicht Ihr Produktions-Dataset und Ihre Produktions-BigQuery-Tabellen.

Wenn sich Ihr SAP LT Replication Server in einer eingebetteten Architektur befindet, führen Sie das Lastsimulationstool mit den SAP-Standardtabellen wie MARA und T001 aus.

Wenn sich Ihr SAP LT Replication Server in einer eigenständigen Architektur befindet, führen Sie das Lastsimulationstool mit der Beispieltabelle /GOOG/TEST_REPL aus, die Google Cloud mit dem BigQuery-Connector für SAP bereitstellt. Das Lastsimulationstool unterstützt nicht das Lesen von Quelltabellen aus einem Remote-System.

Weitere Informationen zu den Architekturen für SAP-Datenquellen in Google Cloud finden Sie unter Installationsarchitektur.

Vorbereitung

Prüfen Sie vor dem Ausführen des Lastsimulationstools, ob die folgenden Voraussetzungen erfüllt sind:

Lastsimulationstool ausführen

Gehen Sie so vor, um das Lastsimulationstool auszuführen:

  1. Geben Sie in der SAP-GUI die Transaktion /GOOG/LOAD_SIMULATE ein, der /n vorangestellt ist:

    /n/GOOG/LOAD_SIMULATE

  2. Klicken Sie auf das Symbol Ausführen. Der Bildschirm SLT-Lastsimulation wird angezeigt.

  3. Achten Sie darauf, dass in den Verarbeitungsoptionen die Option Simulation ausführen ausgewählt ist.

  4. Geben Sie im Abschnitt Auswahloptionen die folgenden Spezifikationen ein:

    • Wählen Sie im Drop-down-Menü im Feld Google Cloud Partner die Option BigQuery aus.

    • Geben Sie im Feld Massenübertragungsschlüssel den Massenübertragungsschlüssel für die Massenübertragungskonfiguration ein.

      Verwenden Sie mit dem Lastsimulationstool eine Beispielkonfiguration für die Massenübertragung. Verwenden Sie nicht Ihr Produktions-Dataset und Ihre Produktions-BigQuery-Tabellen.

    • Geben Sie im Feld Tabellenname den Namen der SAP-Quelltabelle ein, die Sie in der Beispielkonfiguration für die Massenübertragung angegeben haben.

    • Geben Sie optional im Feld Wo-Bedingung eine Bedingung für die Datenauswahl aus der Quelltabelle ein.

      Dabei sind maximal 255 Zeichen erlaubt. Wenn Sie beispielsweise das Lastsimulationstool für die SAP-Tabelle MARA ausführen und eine Materialnummer aus einem bestimmten Bereich auswählen müssen, geben Sie unter Wo-Bedingung einen Wert wie MATNR GE '000000000400000001' AND MATNR LE '000000000600000001' an.

    • Geben Sie im Feld Zyklusanzahl die Anzahl der Verarbeitungszyklen ein, die das Lastsimulationstool ausführt.

      Dies ist hilfreich, wenn Sie vergleichen möchten, wie der Simulationsbericht in mehreren Zyklen erscheint. Der Wert muss größer als 1 sein.

    • Geben Sie im Feld Anzahl der Datensätze pro Zyklus die Anzahl der Datensätze ein, die Sie in jedem Verarbeitungszyklus an BigQuery senden möchten. Der Wert muss größer als 1 sein.

    • Geben Sie im Feld Teilgröße die Anzahl der Datensätze innerhalb der Datensatzanzahl pro Zyklus ein, die SAP LT Replication Server in jedem Teil an BAdI von BigQuery-Connector für SAP sendet.

    • Wählen Sie je nach Bedarf ein oder mehrere Flags aus:

      • Exakte Datensatzanzahl: Gibt an, dass in jedem Verarbeitungszyklus genau die gleiche Anzahl von Datensätzen gesendet wird, die im Feld Datensatzanzahl pro Zyklus angegeben ist. Wenn die Tabelle nicht genügend Datensätze hat, dupliziert das Lastsimulationstool die vorhandenen Datensätze, um die erforderliche Anzahl zu erreichen. Die Datensätze werden nur dupliziert, um Daten in BigQuery einzufügen, nicht aber in die Quelltabelle.

      • SLT-Zielstruktur verwenden: Verwendet die Struktur der SLT-Logging-Tabelle, um die Quelltabellenfelder abzurufen. Wenn dieses Flag nicht festgelegt ist, werden Felder direkt aus der Quelltabelle gelesen, um die Zielstruktur zu generieren. Weitere Informationen zum Datenfluss von SAP LT Replication Server finden Sie unter Detaillierte Architekturansicht des Datenflusses.

      • Detailliertes Log: Gibt an, dass die Logeinträge für alle definierten Methoden in BigQuery-Connector für SAP erstellt werden. Wenn dieses Flag nicht festgelegt ist, werden nur wichtige Methoden protokolliert.

      • Vorherige Ergebnisse löschen: Löscht zuvor erstellte Logdatensätze für dieselbe Massenübertragung und dieselbe SAP-Tabelle. Wenn das Flag nicht festgelegt ist, werden die Logs an die vorherigen Ergebnisse angehängt.

  5. Klicken Sie auf das Symbol Ausführen, um das Lastsimulationstool auszuführen.

  6. Wählen Sie nach Abschluss der Lastsimulation im Abschnitt Verarbeitungsoptionen das Optionsfeld Bericht anzeigen aus.

  7. Geben Sie im Abschnitt Auswahloptionen die folgenden Spezifikationen ein:

    • Wählen Sie im Drop-down-Menü im Feld Google Cloud Partner die Option BigQuery aus.
    • Geben Sie im Feld Massenübertragungsschlüssel den Massenübertragungsschlüssel der Beispielkonfiguration für die Massenübertragung ein.
    • Geben Sie im Feld Tabellenname den Namen der SAP-Quelltabelle ein.
    • Wenn Sie den Bericht nach dem Ausführungsdatum der Lastsimulation aufrufen möchten, geben Sie einen Zeitraum im Feld Berichtsdatum an.
    • Wenn Sie den zuletzt ausgeführten Bericht zusammen mit dem aktuellen Bericht aufrufen möchten, wählen Sie das Flag Nur letzte Ausführung aus.

  8. Klicken Sie zum Anzeigen des Berichts auf das Symbol Ausführen.

In der folgenden Tabelle werden die im Simulationsbericht angezeigten Spalten beschrieben:

Name Beschreibung
Übertragungsschlüssel Der Massenübertragungsschlüssel für die Massenübertragungskonfiguration.
SAP-Tabelle Der Name der SAP-Tabelle, die nach BigQuery repliziert wird.
Zeitstempel für Ausführungsstart Der Zeitpunkt, zu dem die Ausführung für eine Methode von BigQuery-Connector für SAP gestartet wurde.
Zeitstempel für Abschluss Der Zeitpunkt, zu dem die Ausführung für eine Methode von BigQuery-Connector für SAP abgeschlossen wurde.
Jobnummer Eindeutige Jobnummer für jede abgeschlossene Ausführung, die bei jeder Ausführung des Lastsimulationstools automatisch generiert wird.
Zyklusnummer Die Sequenznummer des Verarbeitungszyklus, in dem der Bericht generiert wurde. Die in der Simulationseingabe angegebene Datensatzanzahl pro Zyklus wird für jeden Zyklus an BigQuery übertragen.
Teilnummer Die Sequenznummer des Teils. Die in der Simulationseingabe angegebene Datensatzanzahl pro Zyklus wird anhand der angegebenen Teilgröße aufgeteilt. Das BAdI von BigQuery-Connector für SAP wird für jeden Teil aufgerufen.
Kursname Der Klassenname der Methode von BigQuery-Connector für SAP.
Name der Methode Der Name der Methode von BigQuery-Connector für SAP. Die von BigQuery-Connector für SAP aufgerufenen Methoden werden in einer Sequenz protokolliert. Wenn in der Simulationseingabe das Flag Detailliertes Log ausgewählt ist, werden alle Methoden protokolliert, andernfalls nur die wichtigen Methoden.
Nach Methode aufgerufen Die letzte Methode, die die aktuelle Methode von BigQuery-Connector für SAP aufgerufen hat.
Dauer Die Gesamtzeit, die für die Ausführung einer Methode von BigQuery-Connector für SAP benötigt wird.
Datensatzanzahl Die Anzahl der Datensätze, die an eine Methode von BigQuery-Connector für SAP übergeben werden. Dies wird nur für Methoden angezeigt, an die Datensätze übergeben werden.
URI-Methode Der Name der HTTP-Methode, falls die ABAP-Methode einen BigQuery API-Aufruf durchführt.
URI-String Die HTTP-URL, falls die ABAP-Methode einen BigQuery API-Aufruf durchführt.
Tokenquelle Die Quelle des Authentifizierungstokens, das vom Lastsimulationstool verwendet wird. Dies gilt nur, wenn das Token-Caching in der Tabelle /GOOG/CLIENT_KEY aktiviert ist. Die möglichen Werte sind:
  • A: Statischer Attributwert aus einem bestimmten Prozess.
  • M: Gemeinsamer Arbeitsspeicherwert aus dem Arbeitsspeicher, der von mehreren Prozessen gemeinsam genutzt wird.
  • L: Neuer Wert mit Arbeitsspeichersperre. Wenn eine Arbeitsspeichersperre vorhanden ist und das im Cache gespeicherte Token nicht gelesen werden kann, wird ein neues Token generiert.
  • N: Neuer Wert ohne Arbeitsspeichersperre. Wenn ein Token abläuft oder nicht im Arbeitsspeicher gefunden wird, wird ein neues Token generiert.
Ablaufzeit Die Ablaufzeit des Authentifizierungstokens.
Dies gilt nur, wenn das Token-Caching in der Tabelle /GOOG/CLIENT_KEY aktiviert ist.
Tokenwert Wert des Authentifizierungstokens, mit dem das Lastsimulationstool auf BigQuery zugreift.
Rückgabecode Der Rückgabecode der Methodenausführung. Die möglichen Werte sind:
Fehlertext Der Fehlertext, falls vorhanden.
Fehlerbeschreibung Detaillierte Informationen zum Fehler.
Nutzlastgröße Die Größe der HTTP-Nutzlast an die BigQuery Insert API. Wenn bei der Ausführung der Methode ein Fehler auftritt und die Nutzlast größer als 10 MB ist, können Sie die Blockgröße anpassen, um die Nutzlastgröße zu reduzieren.
Informationstext Jede relevante Informationsnachricht, die vom BAdI von BigQuery-Connector für SAP angezeigt wird. Wenn beispielsweise eine dynamische Blockaufteilung ausgelöst wird, wird die folgende Informationsnachricht angezeigt: Dynamic chunking triggered. Chunk size reduced from INITIAL_CHUNK_SIZE_VALUE to FINAL_REDUCED_CHUNK_SIZE_VALUE.
Status Status der Methodenausführung. Wenn eine Methodenausführung fehlschlägt, finden Sie Informationen zur Behebung des Problems im Leitfaden zur Fehlerbehebung für BigQuery-Connector für SAP.

Lastsimulationstool planen

Sie können das Lastsimulationstool so planen, dass es automatisch als Hintergrundjob auf dem SAP LT Replication Server ausgeführt wird. Verwenden Sie dazu den Programmnamen /GOOG/R_LOAD_SIMULATION. Weitere Informationen von SAP über das Planen von Hintergrundjobs finden Sie unter Hintergrundjobs planen.

Replikationsvalidierung

Wenn Sie beim Erstellen der BigQuery-Zieltabelle mit der Transaktion /GOOG/SLT_SETTINGS das Flag für zusätzliche Felder auswählen, werden dem Tabellenschema mit jedem Datensatz, der die Replikation ausgelöst hat, und mit einem Zeitstempel, der angibt, zu welchem Zeitpunkt SAP LT Replication Server den Teil enthält, der den Datensatz enthielt, Spalten zum Speichern der Art der Änderung hinzugefügt.

Sie können die Änderungstypen und den Zeitstempel verwenden, um die folgenden Arten von Datensatzzahlen abzufragen:

  • Die Anzahl der Datensätze, die während eines anfänglichen Ladevorgangs in eine BigQuery-Tabelle geladen werden
  • Die Anzahl der Datensätze, die an einem bestimmten Tag in eine BigQuery-Tabelle repliziert werden
  • Die Gesamtzahl der eindeutigen Datensätze in einer BigQuery-Tabelle

Um diese Anzahlen zu erhalten, können Sie die BigQuery-Tabelle direkt abfragen. Dazu senden Sie SQL-Abfragen in der Google Cloud Console oder führen das Tool zur Replikationsvalidierung aus. Dieses Tool generiert Berichte, in denen die Anzahl der BigQuery-Datensätze mit SAP LT Replication Server-Statistiken oder der Anzahl der Datensätze aus der Quelltabelle verglichen werden.

Eine Übersicht über das Flag der zusätzlichen Felder finden Sie unter Zusätzliche Felder für Datensatzänderungen und Anzahlabfragen.

Wie Sie das Flag für zusätzliche Felder angeben, erfahren Sie unter:

SQL-Abfragen für Datensatzanzahl

Auf der BigQuery-Seite SQL-Editor in der Google Cloud Console können Sie SQL-Abfragen ausführen, um die Anzahl der Datensätze in Ihren BigQuery-Tabellen zu prüfen.

Anschließend können Sie die Anzahl der BigQuery-Einträge mit der Anzahl in der Quelltabelle oder in den Statistiken des SAP LT Replication Servers vergleichen.

Anzahl der Datensätze abfragen, die im anfänglichen Lademodus eingefügt wurden

Wenn ein BigQuery-Tabellenschema die optionale Spalte operation_flag enthält, enthalten Datensätze, die im anfänglichen Lademodus in die Tabelle eingefügt werden, das Vorgangs-Flag L.

Führen Sie die folgende Abfrage aus, um die Anzahl der Datensätze zu erhalten, die während eines anfänglichen Ladevorgangs von BigQuery empfangen wurden:

SELECT COUNT(*)
  FROM
      `PROJECT.DATASET.TABLE`
  WHERE operation_flag = 'L'

Anzahl der im Replikationsmodus eingefügten Datensätze abfragen

Wenn ein BigQuery-Tabellenschema die optionale Spalte operation_flag enthält, enthalten Datensätze, die im Replikationsmodus in die Tabelle eingefügt werden, eines der folgenden Vorgangs-Flags:

  • I: Der Datensatz wurde in die Quelltabelle eingefügt.
  • D: Der Datensatz wurde aus der Quelltabelle gelöscht.
  • U: Der Datensatz wurde in der Quelltabelle aktualisiert.

Führen Sie die folgende Abfrage aus, um die Anzahl der Datensätze zu ermitteln, die BigQuery im Replikationsmodus empfangen hat:

SELECT COUNT(*)
  FROM
      `PROJECT.DATASET.TABLE`
  WHERE operation_flag = 'I' | 'D' | 'U'

Gesamtzahl der Datensätze in einer BigQuery-Tabelle abfragen

Wenn ein BigQuery-Tabellenschema die optionale Spalte recordstamp enthält, enthält das entsprechende recordstamp-Feld jedes Datensatzes, der in die Tabelle eingefügt wird, einen Zeitstempel, der angibt, wann der Datensatz von SAP LT Replication Server an BigQuery gesendet wurde.

Um die Gesamtzahl der Datensätze in einer BigQuery-Tabelle zu ermitteln, die Sie mit der Gesamtzahl der Datensätze in einer Quelltabelle vergleichen können, können Sie mit den Feldern recordstamp und is_deleted eindeutige Datensätze in der BigQuery-Tabelle zählen, die nicht aus der Quelltabelle gelöscht wurden.

Wenn die Quelltabelle aktiv aktualisiert wird oder die Replikation beim Abfragen der Datensätze aktiv ist, stimmt die Anzahl der Datensätze in den Quell- und Zieltabellen möglicherweise nicht genau überein.

Führen Sie die folgende Abfrage aus, um die aktuelle Anzahl der eindeutigen Datensätze in der BigQuery-Zieltabelle abzurufen:

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

Replikationsvalidierungstool

Dieser Abschnitt bietet einen Überblick über das Tool zur Replikationsvalidierung und was Sie damit tun können.

Das Replication Validation-Tool generiert Berichte, die die Anzahl der Datensätze in der BigQuery-Tabelle mit Statistiken aus SAP LT Replication Server und der Anzahl der Datensätze in der Quelltabelle vergleichen. Wenn die Anzahl nicht genau übereinstimmt, kennzeichnet das Tool den Bericht mit einem roten Kreis.

Wenn Sie die Datensätze in BigQuery zählen möchten, verwendet das Tool die SQL-Abfragen, die im vorherigen Abschnitt SQL-Abfragen für Datensatzzahlen angezeigt werden.

Führen Sie das Replikations-Validierungstool regelmäßig aus, um zu prüfen, ob SAP LT Replication Server und BigQuery-Connector für SAP Datensätze wie erwartet in BigQuery replizieren.

Um das Replikations-Validierungstool auszuführen, geben Sie die benutzerdefinierte Transaktion /GOOG/REPLIC_VALID mit vorangehendem /n in der SAP-GUI ein. Eine detaillierte Anleitung finden Sie unter:

Berichte zur Replikationsprüfung

Mit dem Tool zur Replikationsvalidierung können Sie die folgenden Validierungsberichte erstellen:

  • Anzahl der anfänglichen Ladevorgänge: Ein Vergleich der Anzahl der Datensätze, die von SAP LT Replication Server im Lademodus gesendet wurden, und der Anzahl der Datensätze, die in BigQuery geladen wurden
  • Replikationszahlen: Vergleich der Anzahl der Datensätze, die von SAP LT Replication Server im Replikationsmodus gesendet wurden, sowie die Anzahl der Datensätze, die an einem bestimmten Tag in BigQuery eingefügt wurden.
  • Aktuelle Anzahlen: Ein Zeitpunkt zu einem Vergleich der Anzahl der Datensätze in der Quelltabelle und der Anzahl der eindeutigen Datensätze in BigQuery

Sie können jeden Bericht einzeln generieren oder durch Ausführen von Alle Prüfungen beim Ausführen des Tools alle drei Berichte in einer einzigen Ausführung generieren.

Berichte zur Replikationsvalidierung anzeigen

Nachdem Sie einen Bericht erstellt haben, können Sie den Bericht anzeigen, indem Sie auf der Benutzeroberfläche des Replikations-Validierungstools im Abschnitt Verarbeitungsoptionen das Optionsfeld Bericht anzeigen auswählen.

Die Informationen, die das Replikationsvalidierungstool in den einzelnen Berichten anzeigt, unterscheiden sich geringfügig je nach Art des Berichts.

Alle Berichte enthalten die folgenden Arten von Informationen:

  • Anzahl der Quelldatensätze aus den SAP LT Replication Server-Statistiken und der Quelltabelle
  • Anzahl der Zieldatensätze aus der BigQuery-Zieltabelle
  • Jeder Unterschied zwischen den beiden Zählungen Die Differenz wird durch Subtrahieren der BigQuery-Anzahl von den Quelldatensatzzahlen berechnet. Ein positiver Wert weist auf ein wahrscheinliches Problem hin, da er nahelegt, dass nicht alle Quelldatensätze ihn in BigQuery übertragen.
  • Die Differenz in der Anzahl als Prozentsatz der Anzahl der Quelldatensätze.
  • Ein visueller Indikator dafür, ob die Anzahl der Quellen und des Ziels gleich oder unterschiedlich sind

Ungleiche Datensatzanzahl

Das Replikationsvalidierungstool enthält ein Statusfeld mit jedem angezeigten Bericht.

Ein grünes Quadrat im Statusfeld bedeutet, dass die Anzahl der Quelleinträge mit der Anzahl der Zieldatensätze in BigQuery übereinstimmt.

Ein roter Kreis im Statusfeld bedeutet, dass die Anzahl der Datensätze nicht gleich ist.

Eine ungleiche Datensatzanzahl weist nicht immer auf ein Problem hin. Folgende Indikatoren deuten auf ein mögliches Problem hin:

  • Bei einem Bericht über die aktuelle Anzahl wird bei einem ungleichen Wert immer ein Problem angezeigt.

  • Bei einem Bericht zum anfängliches Laden oder Replikationsanzahlen weist ein positiver Wert auf ein wahrscheinliches Problem hin.

    Ein relativ niedriger negativer Wert ist kein Problem. Die Anzahl in einer BigQuery-Zieltabelle kann aufgrund von Ereignissen wie vorübergehenden Unterbrechung der Verbindungen, die dazu führen, dass SAP LT Replication Server Daten noch einmal sendet, etwas höher sein als die Anzahl der Quelldatensätze.

Führen Sie den Bericht noch einmal aus, wenn eine ungleiche Anzahl angezeigt wird, um sicherzustellen, dass er nicht durch ein vorübergehendes Problem verursacht wurde. Aufgrund der Replikationsverarbeitung zum Zeitpunkt, zu dem das Tool den Bericht generiert hat, kann es zu einer ungleichen Datensatzanzahl kommen.

Bei einer sehr großen Quelltabelle oder einer Tabelle, in der in SAP LT Replication Server für anfänglichen Ladevorgang oder Replikation Filter festgelegt sind, kann das Tool zur Replikationsprüfung möglicherweise nicht alle erforderlichen Datensätze zählen, die für eine gleichmäßige Anzahl erforderlich sind.

Validierungsprüfungen planen

Mit dem SAP-Hintergrundjob-Feature können Sie das Tool zur Replikationsprüfung automatisch in Intervallen ausführen lassen.

BigQuery-Feldzuordnung in einer CSV-Datei bearbeiten

In den folgenden Abschnitten wird beschrieben, wie Sie die Standardfeldzuordnung exportieren, sodass Data Engineers oder BigQuery-Administratoren die Zielfeldwerte bearbeiten können, ohne Zugriff auf SAP LT Replication Server zu benötigen.

Tabelle oder Textdatei mit den Standardfeldzuordnungen erstellen

So erstellen Sie eine CSV-Datei zur Bearbeitung außerhalb von SAP LT Replication Server:

  1. Führen Sie die Transaktion /GOOG/SLT_SETTINGS aus.

  2. Geben Sie auf dem Bildschirm SLT-Einstellungen warten die folgenden Werte ein:

    • Geben Sie im Feld Einstellungstabelle die Option Felder an.
    • Geben Sie im Feld Massenübertragungsschlüssel die ID der zu aktualisierenden Massenübertragung an.
    • Im Feld Tabellenname lassen Sie das Feld entweder leer, um mit allen Feldern aus allen Tabellen zu arbeiten, oder Sie geben einen Tabellennamen an, um mit einer bestimmten Tabelle zu arbeiten.
    • Lassen Sie alle anderen Felder leer.

  3. Klicken Sie auf das Symbol Ausführen. Der Bildschirm BigQuery-Einstellungen warten – Felder wird angezeigt.

  4. Blenden Sie im Bildschirm BigQuery-Einstellungen warten – Felder alle Spalten mit Ausnahme der in der folgenden Liste aufgeführten aus, indem Sie mit der rechten Maustaste auf die Spaltenüberschriften klicken und aus dem Drop-down-Menü Ausblenden wählen:

    • SAP-Tabellenname
    • SAP-Feldname
    • Externes Datenelement
    • Externer Feldname
    • Feldbeschreibung

  5. Klicken Sie, wenn alle fünf Spalten angezeigt werden, auf das Symbol Exportieren.

  6. Wählen Sie im Menü Exportieren eine der folgenden Optionen aus:

    • Tabelle
    • Lokale Datei. Für eine einfache Konvertierung des Dateiinhalts in das CSV-Format empfehlen wir, die Datei im Format Text mit Tabs zu speichern.

  7. Speichern Sie die Standardfeldzuordnungen, indem Sie auf das Häkchensymbol klicken.

Tabelle oder Textdatei ins CSV-Format konvertieren

Um bearbeitete Feldzuordnungen mithilfe der benutzerdefinierten Transaktion /GOOG/SLT_SETTINGS hochzuladen, müssen die Feldzuordnungen im CSV-Format vorliegen.

Wenn Sie eine Tabelle verwenden, speichern Sie die Tabelle als CSV-Datei, bevor Sie die Datei hochladen.

Wenn Sie eine lokale Datei in einem tabulatorgetrennten Format oder einem anderen Format verwenden, müssen Sie die Datei so ändern, dass sie dem CSV-Format entspricht.

Beispiel:

SAP Table,SAP Field Name,External Data Element,External Field Name,Field Description
SAP_TABLE_NAME,SAP_FIELD_NAME1,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME1,BIGQUERY_FIELD_DESCRIPTION1
SAP_TABLE_NAME,SAP_FIELD_NAME2,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME2,BIGQUERY_FIELD_DESCRIPTION2
SAP_TABLE_NAME,SAP_FIELD_NAME3,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME3,BIGQUERY_FIELD_DESCRIPTION3

CSV-Datei hochladen

So laden Sie eine bearbeitete CSV-Datei hoch:

  1. Führen Sie die Transaktion /GOOG/SLT_SETTINGS aus.

  2. Geben Sie auf dem Bildschirm SLT-Einstellungen warten die folgenden Werte ein:

    • Geben Sie im Feld Einstellungstabelle die Option Felder an.
    • Geben Sie im Feld Massenübertragungsschlüssel die ID der zu aktualisierenden Massenübertragung an.
    • Klicken Sie das Kästchen Aus Datei hochladen an.

  3. Klicken Sie auf das Symbol Ausführen. Das Dialogfeld Datei zum Hochladen auswählen wird geöffnet.

  4. Wählen Sie im Dialogfeld Datei zum Hochladen auswählen die CSV-Datei aus, die die bearbeiteten Feldwerte enthält.

  5. Klicken Sie auf Öffnen.

  6. Wenn Sie eine Sicherheitswarnung erhalten, klicken Sie auf Zulassen. Die Datei wird geladen und die geänderten Werte in der Datei werden in den entsprechenden Zeilen auf dem Bildschirm Wartung der BigQuery-Einstellungen – Felder angezeigt.

  7. Klicken Sie auf das Symbol Speichern.

  8. Vergleichen Sie die Werte in der CSV-Datei mit den Werten, die von SAP LT Replication Server angezeigt werden, um zu überprüfen, ob die Werte übernommen wurden.

Umgang mit Fehlern in den Quelldaten

Nachdem ein Datensatzblock von BigQuery-Connector für SAP empfangen wurde, prüft die BigQuery Streaming API auf Datenfehler, bevor Datensätze in die BigQuery-Tabelle eingefügt werden.

Sie können steuern, wie die BigQuery API und BigQuery-Connector für SAP reagieren, wenn Datenfehler gefunden werden. Geben Sie dazu die folgenden Flags in Massenübertragungseinstellungen an:

  • The Flag Skip Invalid Records (SKIP)
  • The Flag Break at First Error Flag (BREAK)

Das Flag SKIP

Wenn Sie das Flag SKIP angeben und die BigQuery API einen Datensatzblock empfängt und einen Datensatz mit einem Datenfehler findet, verwirft (oder überspringt) die BigQuery API den Datensatz mit dem Fehler und fügt die anderen Datensätze des Blocks in die BigQuery-Tabelle ein.

Wenn Sie das Flag SKIP nicht angeben und BigQuery einen Datensatz mit einem Datenfehler findet, verwirft BigQuery den gesamten Datensatzblock, ohne Datensätze in die BigQuery-Tabelle einzufügen. Das ist das Standardverhalten.

Die Angabe des Flags SKIP eignet sich am besten für Entwicklungs- und QA-Umgebungen und wird für Produktionsumgebungen nicht empfohlen.

Sie können das Flag SKIP in der Transaktion /GOOG/SLT_SETTINGS angeben, wenn Sie die Replikation konfigurieren. Die Spezifikation wird in der Konfigurationstabelle /GOOG/BQ_MASTR gespeichert.

Informationen zur Interaktion von SKIP-Spezifikationen mit BREAK-Spezifikationen finden Sie unter Matrixtabelle für SKIP- und BREAK-Interaktionen.

Das Flag BREAK

Wenn Sie das Flag BREAK angeben und BigQuery-Connector für SAP von der BigQuery API benachrichtigt wird, dass in einem Datensatz ein Datenfehler gefunden wurde, sendet BigQuery-Connector für SAP keine Datensätze mehr an BigQuery und beendet den Replikationsjob.

Wenn Sie das Flag BREAK nicht angeben und BigQuery-Connector für SAP von BigQuery benachrichtigt wird, dass in einem Datensatz ein Datenfehler gefunden wurde, sendet BigQuery-Connector für SAP den nächsten Datensatzblock an BigQuery und der Replikationsjob wird fortgesetzt. Das ist das Standardverhalten.

In Produktionsumgebungen wird empfohlen, das Flag BREAK anzugeben.

Sie können das Flag BREAK in der Transaktion //GOOG/SLT_SETTINGS angeben, wenn Sie die Replikation konfigurieren. Die Spezifikation wird in der Konfigurationstabelle /GOOG/BQ_MASTR gespeichert.

Informationen zur Interaktion von BREAK-Spezifikationen mit SKIP-Spezifikationen finden Sie unter Matrixtabelle für SKIP- und BREAK-Interaktionen.

Matrixtabelle für SKIP- und BREAK-Interaktionen

Sie können BigQuery-Connector für SAP so konfigurieren, dass Datenfehler folgendermaßen behandelt werden:

SKIP Flag BREAK Flag Verhalten
FALSE TRUE

BigQuery verwirft den aktuellen Datensatzblock, ohne Datensätze aus dem aktuellen Block in die BigQuery-Tabelle einzufügen.

BigQuery-Connector für SAP sendet keine weiteren Datensatzblöcke aus dem aktuellen Bereich und weist SAP LT Replication Server an, den Replikationsjob zu beenden.

Dabei handelt es sich um die empfohlene Einstellung.

FALSE FALSE

BigQuery verwirft den aktuellen Datensatzblock, ohne Datensätze aus dem aktuellen Block in die BigQuery-Tabelle einzufügen.

BigQuery-Connector für SAP sendet alle verbleibenden Datensatzblöcke aus dem aktuellen Bereich und ruft den nächsten Bereich ab. BigQuery-Connector für SAP weist SAP LT Replication Server nicht an, den Replikationsjob zu beenden.

Das ist die Standardeinstellung.

TRUE TRUE

BigQuery verwirft nur den Datensatz, der den Fehler enthält, und fügt den Rest der Datensätze im aktuellen Block in die BigQuery-Tabelle ein.

BigQuery-Connector für SAP sendet keine weiteren Datensatzblöcke aus dem aktuellen Bereich und weist SAP LT Replication Server an, den Replikationsjob zu beenden.

TRUE FALSE

BigQuery verwirft nur den Datensatz, der den Fehler enthält, und fügt den Rest der Datensätze im aktuellen Block in die BigQuery-Tabelle ein.

BigQuery-Connector für SAP sendet alle verbleibenden Datensatzblöcke aus dem aktuellen Bereich und ruft den nächsten Bereich ab. BigQuery-Connector für SAP weist SAP LT Replication Server nicht an, den Replikationsjob zu beenden.

Änderungen der Tabellenstruktur

In diesem Abschnitt wird erläutert, wie Sie die SAP-Quelltabellenstruktur ändern, für die eine vorhandene LTRC-Replikation ausgeführt wird.

Spalte zu einer Quelltabelle hinzufügen

So fügen Sie einer Quelltabelle eine neue Spalte hinzu:

  1. Fügen Sie der Quelltabelle eine neue Spalte hinzu. Infolge dieses Schritts ändert sich der Replikationsstatus in Load/Replication blocked.

  2. Setzen Sie in Ihrem SLT-System den Replikationsstatus mithilfe der Transaktion LTRC zurück. Weitere Informationen von SAP über das Zurücksetzen des Replikationsstatus finden Sie im SAP-Hinweis 2204955 – SLT-Tabellen befinden sich im Status "Load/Replication blocked".

  3. Fügen Sie einen Eintrag in der Quelltabelle hinzu oder aktualisieren oder löschen Sie einen.

  4. Validieren Sie das Replikationsergebnis in BigQuery.

Spalte aus einer Quelltabelle löschen

So löschen Sie eine vorhandene Spalte aus einer Quelltabelle:

  1. Deaktivieren Sie in Ihrem SLT-System die Replikation mit der Transaktion LTRC.

  2. Löschen Sie eine Spalte aus der Quelltabelle. Infolge dieses Schritts werden die vorhandenen SLT-Trigger entweder gelöscht oder in einen inkonsistenten Zustand geändert.

  3. Löschen Sie in BigQuery die Spalte aus der BigQuery-Zieltabelle. Weitere Informationen zum Löschen einer Spalte aus einer vorhandenen Tabelle finden Sie in der BigQuery-Dokumentation.

  4. Setzen Sie die Replikation in Ihrem SLT-System mit der Transaktion LTRC fort.

  5. Erstellen Sie in Ihrem SLT-System die SLT-Trigger neu. Weitere Informationen von SAP über das Neuerstellen von SLT-Triggern finden Sie im SAP-Hinweis 2254376 – SLT-Trigger in einem inkonsistenten Zustand.

  6. Wenn der Replikationsstatus Load /Replication blocked lautet, setzen Sie den Replikationsstatus mithilfe der Transaktion LTRC zurück. Weitere Informationen von SAP über das Zurücksetzen des Replikationsstatus finden Sie im SAP-Hinweis 2204955 – SLT-Tabellen befinden sich im Status "Load/Replication blocked".

  7. Löschen Sie gegebenenfalls die Logs.

  8. Fügen Sie einen Eintrag in der Quelltabelle hinzu oder aktualisieren oder löschen Sie einen.

  9. Validieren Sie das Replikationsergebnis in BigQuery.

Datentyp einer vorhandenen Spalte ändern

Wenn Sie den Datentyp einer vorhandenen Spalte in der SAP-Quelltabelle ändern, müssen Sie bestimmte Schritte ausführen, je nachdem, ob Sie den Datentyp in einen Datentyp ändern, der mit der BigQuery-Zieltabelle kompatibel oder nicht kompatibel ist.

Ein Datentyp ist mit dem Datentyp in der BigQuery-Zieltabelle kompatibel, wenn der vorhandene Datentyp und der neue Datentyp einer vorhandenen Spalte demselben Datentyp in der BigQuery-Zieltabelle zugeordnet sind. Wenn beispielsweise der Datentyp einer Spalte in einer Quelltabelle von INT1 in INT2 geändert wird, sind beide Datentypen mit dem Datentyp INTEGER in der BigQuery-Zieltabelle kompatibel.

Weitere Informationen zur Datentypzuordnung in BigQuery-Connector für SAP finden Sie unter Datentypzuordnung.

Datentyp in einen kompatiblen Datentyp ändern

So ändern Sie den Datentyp einer vorhandenen Spalte in einen kompatiblen Datentyp:

  1. Ändern Sie den Datentyp im Quellsystem in einen kompatiblen Datentyp. Infolge dieses Schritts werden die vorhandenen SLT-Trigger entweder gelöscht oder in einen inkonsistenten Zustand geändert.

  2. Erstellen Sie in Ihrem SLT-System die SLT-Trigger neu. Weitere Informationen von SAP über das Neuerstellen von SLT-Triggern finden Sie im SAP-Hinweis 2254376 – SLT-Trigger in einem inkonsistenten Zustand.

  3. Wenn der Replikationsstatus Load /Replication blocked lautet, setzen Sie den Replikationsstatus mithilfe der Transaktion LTRC zurück. Weitere Informationen von SAP über das Zurücksetzen des Replikationsstatus finden Sie im SAP-Hinweis 2204955 – SLT-Tabellen befinden sich im Status "Load/Replication blocked".

  4. Löschen Sie gegebenenfalls die Logs.

  5. Fügen Sie einen Eintrag in der Quelltabelle hinzu oder aktualisieren oder löschen Sie einen.

  6. Validieren Sie das Replikationsergebnis in BigQuery.

Datentyp in einen nicht kompatiblen Datentyp ändern

So ändern Sie den Datentyp einer vorhandenen Spalte in einen nicht kompatiblen Datentyp:

  1. Beenden Sie in Ihrem SLT-System die Replikation mit der Transaktion LTRC.
  2. Löschen Sie in BigQuery die Zieltabelle.
  3. Ändern Sie den Datentyp im Quellsystem.
  4. Starten Sie in Ihrem SLT-System die Replikation mit der Transaktion LTRC.

Optimierungspunkte

BigQuery-Connector für SAP bietet mehrere Optimierungspunkte in seinem Code, an denen ein ABAP-Entwickler Code einfügen kann, um benutzerdefinierte Features hinzuzufügen.

Die folgende Tabelle enthält die Funktionen, die von den Optimierungspunkten unterstützt werden, die Methoden sowie die Klasse, die den Optimierungspunkt enthält.

Funktion Klasse Methode Spot Option
Aktualisieren Sie die Zuordnung für ein Feld, z. B. den externen Feldnamen, den Datentyp usw. /GOOG/CL_IUUC_REPL_RUNTIME CREATE_FLD_MAPPINGS /GOOG/ES_IUUC_REPL_RUNTIME /GOOG/UPDATE_FIELD_MAPPING
Aktualisieren Sie die Zuordnung für die Feldtabelle, indem Sie Felder hinzufügen oder entfernen. /GOOG/CL_IUUC_REPL_RUNTIME CREATE_FLD_MAPPINGS /GOOG/ES_IUUC_REPL_RUNTIME /GOOG/UPDATE_FIELD_MAPPINGS
Ändern Sie den Wert eines Quellfelds, bevor das Feld in ein Zielfeld konvertiert wird. /GOOG/CL_IUUC_REPL_RUNTIME_BQ FILL_TARGET_RECORDS /GOOG/ES_IUUC_REPL_RUNTIME_BQ /GOOG/CHANGE_SOURCE_FIELD
Nachdem ein Quellfeld in ein Zielfeld in der Zieltabelle umgewandelt wurde, ändern Sie den Wert des Zielfelds. /GOOG/CL_IUUC_REPL_RUNTIME_BQ FILL_TARGET_RECORDS /GOOG/ES_IUUC_REPL_RUNTIME_BQ /GOOG/FILL_TARGET_FIELD
Fügen Sie der Zieltabelle während der Konvertierung von der Quell- zur Zieltabelle ein Feld hinzu, das nicht in der Quelltabelle vorhanden ist. /GOOG/CL_IUUC_REPL_RUNTIME_BQ FILL_TARGET_RECORDS /GOOG/ES_IUUC_REPL_RUNTIME_BQ /GOOG/FILL_EXTRA_FIELD
Bereiten Sie ein BigQuery-Schemafeld vor, bevor die BigQuery-Tabelle erstellt wird. /GOOG/CL_GCP_CLIENT_BQ PREP_BQ_TABLE_SCHEMA /GOOG/ES_GCP_CLIENT_BQ /GOOG/PREPARE_SCHEMA_FIELD
Erfassen Sie bei HTTP-Fehlern nach den HTTP-Aufrufen an die BigQuery API Logging-Daten, um das Problem zu beheben. /GOOG/CL_GCP_CLIENT_BQ_SLT INSERT_TABLEDATA /GOOG/ES_GCP_CLIENT_BQ_SLT /GOOG/LOG_INSERT_ERROR

Erweiterte Einstellungen

Optional können Sie die erweiterten Einstellungen für BigQuery-Connector für SAP ändern. Google Cloud empfiehlt, die Parameter der erweiterten Einstellungen nur nach einer umfassenden Analyse der Auswirkungen neuer Werte auf die Leistung zu ändern. Sie sind dafür verantwortlich, dass die neuen erweiterten Einstellungen für BigQuery-Connector für SAP keine Fehler und keine Leistungsprobleme verursachen.

Erweiterte Einstellungen für BigQuery-Connector für SAP werden auf Systemebene angewendet und gelten für alle Massenübertragungsschlüssel. Wenn die Parameter für die erweiterten Einstellungen nicht geändert werden, arbeitet BigQuery-Connector für SAP mit den Standardeinstellungen.

Führen Sie die folgenden Schritte aus, um die Parameter für die erweiterten Einstellungen zu ändern:

  1. Geben Sie in der SAP-GUI die Transaktion /GOOG/SLT_SETTINGS, der /n vorangestellt ist:

    /n/GOOG/SLT_SETTINGS

  2. Wählen Sie im Drop-down-Menü Einstellungentabelle im Startbildschirm für die Transaktion /GOOG/SLT_SETTINGS die Option Parameter aus.

  3. Klicken Sie auf das Symbol Ausführen. Der Bildschirm BigQuery-Einstellungen warten – Parameter wird angezeigt.

  4. Klicken Sie auf das Symbol Zeile einfügen.

  5. Geben Sie in der angezeigten Zeile die folgenden Einstellungen an:

    1. Geben Sie im Feld Parametername den Namen des Parameters ein. Die Parameterbeschreibung wird automatisch ausgefüllt.

    2. Geben Sie im Feld Parameterwert einen Wert ein.

      Informationen zu den Parametern für die erweiterten Einstellungen

  6. Klicken Sie auf Speichern.

    Ihre erweiterten Einstellungen werden als Datensatz in der Konfigurationstabelle /GOOG/BQ_PARAM gespeichert und die Felder Geändert von, Geändert am und Geändert um werden automatisch ausgefüllt.

Parameter für die erweiterten Einstellungen

Die folgende Tabelle zeigt die Parameter der erweiterten Einstellungen für BigQuery-Connector für SAP.

Parametername Beschreibung Standardwert Gültiger Wert
CHUNK_SIZE_DEF Dies ist die standardmäßige Blockgröße, die von BigQuery-Connector für SAP unterstützt wird.
Wenn in den Einstellungen keine Blockgröße festgelegt wird, wird die Standardblockgröße verwendet.		 10.000 Der Wert muss innerhalb der BigQuery-Kontingentlimits liegen.
PERC_REDUC_DEF Die prozentuale Reduzierung der Blockgröße.
Wenn die dynamische Blockgröße aktiviert ist, wird die Blockgröße um diesen Prozentsatz reduziert, bis eine ideale Blockgröße erreicht wurde und die Daten im Block erfolgreich an BigQuery übertragen wurden.		 50 Der Wert muss zwischen 1 und 99 liegen.
CMD_EXEC_TRIES Wenn bei SAP-Systemen, die nicht in Google Cloud ausgeführt werden, der Betriebssystembefehl, den Sie in der Transaktion SM69 erstellt haben, kein Zugriffstoken von Google Cloud abrufen kann, ist dies die Häufigkeit, mit der BigQuery-Connector für SAP den Tokenabruf wiederholt. 5 Der Mindestwert, den Sie diesem Parameter zuweisen können, ist 1. Legen Sie den Wert 2 fest, um mindestens einen Wiederholungsversuch zu ermöglichen. Der Höchstwert für diesen Parameter muss nach der Analyse der Auswirkungen festgelegt werden, die Wiederholungen des Tokenabrufs auf die Replikationsleistung haben können.
CMD_SECS_DEFLT Wenn Sie das Token-Caching aktiviert haben, ist dies die Dauer in Sekunden, nach der das im Cache gespeicherte Token abläuft. 3500 Der Wert muss zwischen 1 und 3599 liegen.