Leistungssteigerung für parallele Verarbeitung

Dieser Anhang beschreibt die Leistungssteigerung, die beim Ausführen des Programms Interner Konvertierungsprozess (tccri7203m000) bei paralleler Verarbeitung erforderlich sein kann.

Die Ist-Leistung von Interner Konvertierungsprozess (tccri7203m000) ist von einer Reihe von Faktoren abhängig, wie z. B. der Anzahl der verfügbaren CPUs oder den Einstellungen von Anwendungsprogramm- und Datenbank-Servern. Die in den Tabellen enthaltene Datenmenge ist ein weiterer wichtiger Faktor. Im Allgemeinen enthalten die folgenden Tabellen große Datenmengen:

  • Integrationsbuchungen (tfgld482)
  • Abgleichdaten (tfgld495)
  • Journalisierte Buchungen (tfgld106)
  • AiU- und Bestandsbuchungen (JSC) (ticst300)
  • AiU- und Bestandsbuchungen (PCS) (tipcs300)
  • VK-Auftragshistorie (tdsls450, tdsls451, and tdsls456)

In LN FP5 und späteren Releases ist eine Funktion zur Aktualisierung der Tabellen direkt in RDBMS verfügbar. Diese Funktion ist in Porting-Set 8.7a.03. und späteren Versionen enthalten.

Aktualisierungen direkt in RDBMS sind effizienter als Aktualisierungen durch die B-Shell. Der Unterschied besteht darin, dass die gesamte Buchung an RDBMS übergeben wird. Diese Aktualisierungsart ist auf Tabellen oder Daten begrenzt, die keine Neuberechnung der Beträge in Hauswährung und/oder Wechselkurse erfordern. Dies kann zutreffen, wenn zum Beispiel die Hauswährungsbeträge einer Berichtswährung zu Beträgen in Landeswährung werden. Ein anderes Beispiel ist die Umgruppierung der Hauswährungsbeträge. Dies kann zutreffen, wenn Berichtswährungen gelöscht werden oder wenn in Logistiktabellen das Währungssystem in ein Standardwährungssystem geändert wird.

Das Programm Interner Konvertierungsprozess (tccri7203m000) überprüft, ob Aktualisierungen direkt in RDBMS angewendet werden können. Dieses Programm verwendet herkömmliche (langsamere) Aktualisierungen, wenn die direkte Aktualisierung in RDBMS nicht zulässig ist.

Ob Sie RDBMS-Aktualisierungen durchführen können, wird durch Folgendes bestimmt:

  • Im Programm Wechselkurse für interne Konvertierung (tccri7100m000) muss der Wert im Feld In Basiswährung angeben mit dem entsprechenden Feld im Programm Wechselkurse (tcmcs0108m000) übereinstimmen. Zum Beispiel können in EURO-Firmen die Wechselkurse von EUR (lokal) zu buchungsbezogen Währungen bestehen bleiben, wenn sich die Einstellung In Basiswährung angeben während der Konvertierung nicht ändert.

    Hinweis: Dies gilt für alle Wechselkursarten im Programm Wechselkurse (tcmcs0108m000).

  • Technische Grenzwerte

    Diese Grenzwerte gelten wie folgt:

    • Der DB-Treiber muss ein Level-2-Treiber sein.

    • Die folgenden Tabellen werden weder geprüft noch gespiegelt.

      tfgld495, tfgld482, tdsls451 und tdsls456

  • Es muss Version 8.7a.03 oder später aus dem Porting-Set verwendet werden. Das TIV-Level des Porting-Set muss 1744 oder später sein. Sie können diese Nummer überprüfen, indem Sie $BSE/bin/bshell6.2 –V in der Befehlszeile ausführen (in Windows %BSE\bin\ntbshell –V).

Wenn die Währungsinitialisierung im Programm Interner Konvertierungsprozess (tccri7203m000) gestartet wird, wird dieses Programm auf das Konvertierungscluster und entsprechende Firmen zugreifen, und anschließend festlegen, welche Konvertierungsart erforderlich ist. Wenn Aktualisierungen direkt in RDBMS ausgeführt werden können, werden einige Daten in den Tabellen für interne Konvertierung nach Cluster-Firmen (tccri725) und Aktualisierungsgruppen der Tabellen für interne Konvertierung (tccri726) generiert.

Hinweis

Aktualisierungsgruppen der Tabellen für interne Konvertierung (tccri726) werden nur für Posten der Integrationsbuchung (tfgld482) im Programm Tabellen für interne Konvertierung nach Cluster-Firmen (tccri7125m000) generiert.

Das Feld "Massen-Aktualisierungen" wird im Programm Tabellen für interne Konvertierung nach Cluster-Firmen (tccri7125m000) ausgewählt, wenn eine Tabelle direkt in RDBMS mit Interner Konvertierungsprozess (tccri7203m000) aktualisiert wird.

Die Tabelle Integrationsbuchungen (tfgld482) darf Buchungen enthalten, die zu mehreren kaufmännischen Firmen gehören. Diejenigen Integrationsbuchungen, die mit Aktualisierungen direkt in RDBMS verarbeitet werden können, werden in Aktualisierungsgruppen zusammengefasst. Buchungen in einer Aktualisierungsgruppe können in einer RDBMS-Aktualisierung konvertiert werden. Wenn Integrationsbuchungen (tfgld482) ohne direkte Aktualisierungen in RDBMS konvertiert werden müssen, kann die Tabellenkonvertierung dennoch aufgeteilt werden. Auf diese Weise wird die herkömmliche Aktualisierung der Tabelle mit parallelen Prozessen verarbeitet.

Abgleichdaten (tfgld495) dürfen nur aufgeteilt werden, wenn direkte Aktualisierungen in RDBMS nicht angewendet werden können. Dies ist zum Beispiel der Fall, wenn eine Neuberechnung der Beträge in Hauswährung oder Wechselkurse erforderlich ist.

Hinweis
  • Wenn die Konvertierung von Abgleichdaten (tfgld495) aufgeteilt wird, wird die Tabelle nicht durch Aktualisierungen direkt in RDBMS aktualisiert.
  • Die Tabelle "Journalisierte Buchungen" (tfgld106) kann mit parallelen Prozessen konvertiert werden. Aktualisierungen direkt in RDBMS werden nicht unterstützt.

Beispiel für Leistungssteigerungen

Dieses Beispiel bezieht sich auf Konvertierungsaufgaben, die ohne Aktualisierungen direkt in RDBMS durchgeführt werden und in Tabellen für interne Konvertierung nach Cluster-Firmen (tccri7125m000) aufgeteilt werden können.

Eine interne Konvertierung mit paralleler Verarbeitung darf Aktualisierungen mit und ohne Aktualisierungen direkt in RDBMS enthalten, abhängig von den Währungseinstellungen pro Firma.

Angenommen, es müssen Daten von drei Firmen unter Verwendung von neun parallelen B-Shells konvertiert werden. In der Abbildung wird diese Situation durch unterschiedliche Farben für die drei Firmen angezeigt.

Die in Aufgabe 1.1 konvertierte Tabelle ist sehr groß. Es werden gleichzeitig drei andere große Tabellen konvertiert (2.1, 2.2 und 3.1). Wenn die große Konvertierung in Aufgabe 1.1 aufgeteilt werden kann, können Sie sechs B-Shells für die Verarbeitung der Aufgabe 1.1 verwenden, während drei B-Shells die Aufgaben 2.1, 2.2 und 3.1 verarbeiten. Nach der Aufteilung der Aufgabe 1.1 werden die sechs größeren Aufgaben, die diese Aufgabe verarbeiten, vor den kleineren (lilafarbigen) Aufgaben bearbeitet.

Der gleiche Ansatz kann verwendet werden, um zum Beispiel die Konvertierung von Tabelle 2.3 und 2.4 aufzuteilen. Wenn Tabelle 2.3 parallel von zwei B-Shells verarbeitet wird, und Tabelle 2.4 von drei B-Shells parallel verarbeitet wird, ist noch genug Kapazität für die verbleibenden parallelen B-Shells vorhanden, um die kleineren (grünfarbigen) Aufgaben gleichzeitig zu verarbeiten.

Nach der Aufteilung der Aufgaben sieht die Last für die parallelen Prozesse ausgeglichener aus.

Die Gesamtverarbeitungszeit wurde von 28 auf 17 Zeiteinheiten reduziert.

Interner Konvertierungsprozess (tccri7203m000): Konvertierungssimulation im Vergleich zur echten Konvertierung

Im Simulationsmodus werden die Datenbankbuchungen der Aktualisierungen, die direkt in RDBMS verarbeitet werden, getestet. Diese Art von Aktualisierungen kann im Rahmen der Konvertierung von "Abgleichdaten" (tfgld495), "Integrationsbuchungen" (tfgld482), "Historie VK-Auftragspositionen" (tdsls451) und "Historie aktuelle Lieferpositionen VK-Auftrag" (tdsls456) verwendet werden. Buchungen werden im Simulationsmodus rückgängig gemacht. Dies kann erheblich länger dauern als die tatsächliche Buchung in einer echten Konvertierung.

Bei dieser herkömmlichen Konvertierungslogik wird keine Aktualisierung der Tabellendaten während der Konvertierungssimulation ausgeführt. Beachten Sie, dass die Verarbeitung dieser Tabellen während der Konvertierungssimulation weniger Zeit beansprucht und die Verarbeitung in der echten Konvertierung hingegen länger dauert.
Hinweis

Während der Währungskonvertierung dürfen keine anderen Anwender oder Prozesse in den Firmen eines Konvertierungsclusters aktiv sein, auch wenn das Programm Interner Konvertierungsprozess (tccri7203m000) für eine Konvertierungssimulation ausgeführt wird.

Um Probleme mit Tabellensperren oder dem Lesen nicht festgeschriebener Transaktionen zu vermeiden, beachten Sie bitte Folgendes:
  • Aktualisierungen direkt in RDBMS sind meistens große Transaktionen, die zwar getestet, aber während der Konvertierungssimulation nicht festgeschrieben werden. Dies kann zu Tabellensperren bei Aktualisierungen von "Abgleichdaten" (tfgld495), "Integrationsbuchungen" (tfgld482), "Historie VK-Auftragspositionen" (tdsls451) und "Historie aktuelle Lieferpositionen VK-Auftrag" (tdsls456) führen.
  • SQL-Server: Der Datenbanktreiber verwendet standardmäßig die Isolationsebene "Read Uncommitted", um Shared Locks zu verhindern, sowie das Exclusive Lock zum Aktualisieren und Löschen. Daher ist es möglich, dass andere Anwender oder Prozesse während der Konvertierung(ssimulation) nicht festgeschriebene Transaktionen in "Abgleichdaten" (tfgld495), "Integrationsbuchungen" (tfgld482), "Historie VK-Auftragspositionen" (tdsls451) und "Historie aktuelle Lieferpositionen VK-Auftrag" (tdsls456) lesen können. Nähere Informationen finden Sie hier: Infor Enterprise Server Technical Reference Guide for SQL Server Database Driver (U8173US US).

Oracle-Einstellungen

Aktualisierungen direkt in RDBMS sind meistens große Transaktionen. Daher ist eine große Menge Undo-Tablespace erforderlich. LN wurde mit 32 GB Undo-Tablespace getestet. Wir empfehlen, dass Sie den Undo-Tablespace so konfigurieren, dass die Datendateien (data files) automatisch erweitert werden, zum Beispiel um 8 GB. Dies wird dazu beitragen, dass ORA-1555 (Snapshot too old) Fehler nicht auftreten. Beachten Sie die maximale Größe der Datendateien (data files).

Es ist schwer möglich, vorauszusagen, ob die Größe des Undo-Tablespace ausreichend ist. Wir empfehlen, dass Sie im Event-Viewer Log des LN nach ORA-1555 Fehlern suchen, während Interner Konvertierungsprozess (tccri7203m000) läuft.

Allgemein gilt, dass die Oracle-Databank richtig eingestellt sein muss, damit Abfragen performant durchgeführt werden.

LN wurde mit folgenden Einstellungen in der LN-Umgebung in der $BSE/lib/default/db_resource Datei getestet:

  • ora_init:0101000
  • ora_max_array_fetch:100
  • ora_max_array_insert:100
  • ora_alter_session: setzen Sie " _optim_peek_user_binds" auf false

Sie sollten in Betracht ziehen, die obigen Zeilen mittels der datenbankbasierten Stapelverarbeitung zur Konvertierung zusammenzuführen.

In einigen Implementierungen wurden Nicht-Standardwerte für versteckte Oracle-Parameter (die so genannten Unterstrich-Parameter) gesetzt. Diese Einstellungen können die Ausführungspläne der Abfragen beeinflussen. Prüfen Sie, ob Sie diese Parameter wieder zurücksetzen möchten. Dies kann erreicht werden, indem Sie sie in der Einstellung ora_alter_session der $BSE//lib/defaults/db_resource Datei hinzufügen.

SQL-Server-Einstellungen

Sie sollten darauf achten, das Logging (Protokollierung) der LN Datenbank während der Währungsinitialisierung auf "Einfach" zu setzen und nach Abschluss der Währungsinitialisierung eine komplette Datensicherung durchzuführen.

Aktivieren Sie Array Fetching in der Datei $BSE/lib/default/db_resource und stellen Sie die Fetchsize auf 100.

DB2 Einstellungen

Aktivieren Sie Array Fetching in der Datei $BSE/lib/default/db_resource und stellen Sie die Fetchsize auf 100.