Performance Probleme

Hallo Herr Stark, 
ich benötige ihre Hilfe bei der Suche nach Performance-Problemen. Wir führen jede Nacht Deltaloads mit Flowheater durch und schreiben von einer Oracle DB in MS SQL Server. Dabei haben wir aktuell mit der Performance zu kämpfen. Um ein paar Zahlen zu nennen: Beispiel 1: 63959 Datensätzen Gesamt, 60051 Inserts, 3908 Updates. Laufzeit 5761 Sekunden, aktuell 365.000 Zeilen in der Ziel-Tabelle, 1 non clustered Index. (wa_aufpos, Referenz für mich)
Beispiel 2: 27528 Datensätzen Gesamt, 26757 Inserts, 771 Updates, Laufzeit 5647 Sekunden, aktuell 870.000 Zeilen in der Ziel-Tabelle, 1 non clustered Index (wa_pack)
Beispiel 3: fehlgeschlagene Übertragung von ca. 62.000 Datensätzen, heute Nacht nach 2h abgebrochen, aktuell ca. 630.000 Datensätze, 3 non clustered Index (wa_kommpos)
Beispiel 4: Testdefinition, 4.096 Datensätze Gesamt, nur Updates, läuft 7 Minuten 34 Sekunden. (wa_kommpos)Der Primary Key bildet in jeder Tabelle den Clustered Index. 
Nun habe ich in Absprache mit unserer IT Fall 3 als CSV Export über den MS Import Wizard importiert, was innerhalb einiger Sekunden abgeschlossen war. Spricht für mich gegen ein DB Problem.
Die Tabellen nutzen 2 SQL-Heater zum Füllen von Parametern sowie 2 Skript Heater zur Identifikation der Updates/Inserts + Übertragen in individuelles Log. Bei der Testdefinition aus Beispiel 4 habe ich diese entfernt und wie keine Performanceverbesserung festgestellt. Ausgeführt nur bei Start bzw. Ende der Definition, nicht pro Datensatz. Es finden keine weiteren Heater Anwendung.

Haben Sie noch Anhaltspunkte, was man prüfen könnte? Benötigen Sie noch andere Informationen? 
Viele Grüße
Niko Stein

 

Hallo Herr Stein,

Ihre Laufzeiten sind auf jeden Fall viel zu hoch

Performance Analysen sind aber immer sehr zeitaufwendig und es kann nicht pauschal gesagt werden woran es liegt. Auch ist eine 100%ige Analyse hier über das Forum nicht zu stemmen. Hier mal die Vorgehensweise.

1. Sie müssen erstmal sicherstellen, dass die Laufzeit nicht evtl. am Auslesen der Daten aus der Oracle Datenbank liegt! Hierzu wie in Ihrem Beispiel 4 das ganze mal über eine CSV Datei importieren. Dann auch gleich auch mal so importieren wie mit dem MS Import Wizard durchgeführt, Updates ggf. ausschließen! Soll heißen keine weiteren Umwandlungen Anreicherungen über den FlowHeater! Die Laufzeiten sollten ca. gleich sein, außer Sie verwenden BULK Inserts!
   
   
2. Als nächsten prüfen Sie anhand welcher Felder die Updates sowie auch die SQL Heater und die .NET Script Heater die Daten aus der Datenbank holen. Gibt es einen INDEX über diese Felder?
   
   
3. Zu Ihrem Beispiel 3 würde ich vermuten, dass hier irgendwo ein DEADLOCK aufgetreten ist. Laufen parallel noch weitere andere intensive Jobs die evtl. über Datenbank Transaktionen die Tabelle sperren?

Hallo Herr Stark, 

hier die Ergebnisse zu den einzelnen Punkten:
1.  Wenn ich das richtig verstanden habe, sollte ich den Import einmal statt Oracle --> SQL Server als CSV --> SQL Server über Flowheater laufen lassen. Das hat leider nichts verändert, sondern war eher noch langsamer. 45.000 Zeilen, nur Inserts, in 1h 45 min. Es hat auf die Zeit keine Auswirkungen, ob ich den Adapter als Nur Inserts und vorhandene Datensätze ignorieren oder auf Inserts + Updates einstelle.
Der Export der CSV aus der Oracle DB lief über den SQL Developer in 1 min 10 Sekunden durch, also inkl. Abspeichern. 

2. Der Deltaload wird über das letzte Änderungsdatum eingeschränkt. Hierauf liegt kein Index. Die verwendeten SQL Heater fragen beide das maximale Änderungsdatum aus der Zieltabelle in der SQL Server DB ab. Einmal zu WRITE Start und einmal WRITE Ende, um die Range der übermittelten Datensätze zu erfassen. Der NET Heater liest über adapter.RowsInserted bzw Updated zum WRITE Ende die Daten aus. Der zweite NET Heater schmeisst die Parameter dann in Logfile. Allerdings verbesserte sich die Laufzeit ja auch ohne die Heater nicht wirklich...

3. Leider nein. Habe die Definition ohne Zeitbegrenzung nochmal laufen lassen, lief über 2h. Das sind leider die Zeiten mit denen wir gerade arbeiten...

Wie können wir denn zur Performanceanalye weitermachen? Ich verstehe absolut, dass das den Rahmen des Forums übersteigt. Allerdings fehlt mir bisher ein Anhaltspunkt, den ich auch unserer IT mitgeben kann.
Danke für Ihre Hilfe. 

Viele Grüße
Niko Stein

Hallo Herr Stark,ich konnte das Problem eingrenzen. Wenn ich im WRITE Adapter die Option Daten aktualisieren deaktiviere und somit nur Inserts erlaube, haben wir eine deutlich verbesserte Performance (ca. 1 min 20sek für 50.000 Datensätze statt zuvor eher 3h für vergleichbare Datenmengen in derselben Tabelle). Da Updates aber zwingend nötig sind, löst sich das Problem damit leider nicht für uns. Haben Sie eine Idee, was diesen Performanceeinbruch bei Upserts verursacht?
An mangelnder Kapazität des Servers, auf dem FH Server läuft, kann es nicht liegen, siehe Screenshot anbei. (8vCPU und 32GB RAM )

Viele Grüße
Niko Stein  

Hallo Herr Stein,

das hatte ich ja oben geschrieben, dass Sie mal nur INSERTS durchführen sollten so wie ja auch eigentlich auch über den „MS Import Wizard“!

Bei meinen Tests mit 50.000 Inserts inkl. Updates dauert der Import ca. eine Minute, siehe Screenshot.

Meine Vermutung geht nach Ihren Schilderungen in drei Richtungen.

1. Für das Update werden Felder verwendet worüber kein Index vorhanden ist?
   
   
2. Der verwendete Index ist kaputt? Evtl. mal neu Aufbauen lassen.
   
   
3. Auf der Tabelle ist ein Update Trigger eingerichtet der die Performance so runterzieht?

 
 

Hallo Herr Stark,

das war dann mein Fehler, da ich übersehen hatte, den entsprechenden Haken auch beim WRITE-Adapter zu entfernen. 

Kurze Rückfrage zu ihrer Vermutung 1: Habe ich mir angeschaut, in der Quell-Tabelle und der Ziel-Tabelle ist der Primary Key identisch und als Index vorhanden. Wenn in der Definition sowohl auf der Read als auch auf der Write Seite die Schlüssel-Symbole vor den richtigen Feldern stehen, sollte diese Vermutung doch ausgeschlossen werden können, oder?

Die weiteren Vermutungen kläre ich mit der IT-Abteilung. 

Danke und Gruß
Niko Stein
 

Hallo Herr Stein,

nein nicht ganz. Wenn Sie auf der WRITE Seite nach dem Einlesen des Tabellenschemas nichts geändert haben, dann spiegeln die Schlüsselsymbole automaisch den definierten Primary Key der Tabelle und es sollte passen.

Um ganz sicher zu sein lesen Sie bitte die Schemainformationen auf der WRITE Seite nochmal ein. Wenn Sie anschließend eine Meldung erhalten, dass sich die „Primary Key“ Einstellungen geändert haben müssen Sie Ihren INDEX prüfen!
 

Hallo Herr Stark, 
gute Nachrichten: Ich habe den Fehler gefunden. 
Der Haken bei "UNICODE verwenden" hat verhindert, dass der Index genutzt werden kann, da die Spalten der Zieltabelle vom Typ varchar sind. 
Flowheater funktioniert insofern wunderbar, ich bin begeistert. 

Danke Ihnen für die Hilfe!
Viele Grüße
Niko Stein