THEMA:

Hallo,

wir setzen in unserem hause Flowheater ein um Daten von MS-Excel 2010 Tabellen zu einem MS SQL-Server zu exportieren.

Seit wir eine Migration von Windows Server 2003 auf Windows Server 2008 und damit verbunden auch ein Programmupdate des MS SQL-Servers auf SQL-Server 2008 R2 vollzogen haben, haben wir massive Performanceprobleme bei der Verarbeitung der Flowheater Jobs über die FHBatch.exe. Jobs die vorher max 15min liefen, laufen jetzt ca 3 Stunden. Haben Sie von einem solchen Problem bereits gehört oder haben sie eine Empfehlung für uns, was wir eventuell an den Einstellungen des FH-Jobs verändern können um wieder eine schnellere Verarbeitung der Daten erzielen zu können?

Mit freundlichen Grüßen
C. Weidmann
Anfrage per Email erhalten

Hallo Herr Weidmann,

das könnte mehrere Ursachen haben. Zur weiteren Analyse müssten wir vorab einige Punkte ausschließen.

1. Wird die gleiche FlowHeater Version verwendet?


2. Wurde die betroffene Import/Export Definition evtl. verändert. Z.B. Sollen Daten jetzt auch aktualisiert werden? Wenn früher lediglich ein INSERT durchgeführt wurde, würde das die längere Laufzeit erklären.


3. Wurde auf dem Windows Server 2008 die gleiche Office/Excel Version installiert?

Evtl. liegt es daran, dass Office/Excel nicht sauber installiert ist. Bitte versuchen Sie mal einen Excel Export in eine Textdatei durchzuführen. Läuft dieser ebenfalls langsam, ist Office/Excel nicht sauber installiert, hier hilft meistens eine Reparatur Installation.

Ansonsten könnte ich mir noch vorstellen, dass bei der Migration auf SQL Server 2008 R2 irgendwelche Indexe nicht sauber migriert wurden oder aber korrupt sind. Hier könnte helfen die Indexe neu Aufzubauen.

Hallo Herr Stark,

danke für Ihre schnelle Hilfe.

zu Ihren Fragen:

1. Um Auszuschließen, dass die Fehler von einer veralteten FlowHeater Version kommen, haben wir bereits auf Version 3.3.4 geupdated
2. Die betroffenen Definitionen wurden nur dahin gehend verändert, dass die Pfade zu den Dateien und zum SQL Server angepasst wurden
3. Es wurde die gleiche Office Version (MS Office 2010) installiert

Leider können wir Office nur in der durch unser Rechenzentrum vor- und freigegebenen Version installieren. Die eigentliche Installation und Reinstallation wird dabei auch durch das RZ per Auftrag in der immer gleichen Konfiguration durchgeführt. Hätten Sie hier evtl. einen genaueren Hinweis an welche Stelle sich eine Fehlerhafte Installation auswirken könnte?

Die Indexe auf dem SQL-Server werde ich neu anlegen und Ihnen dann hier nochmal Rückmeldung geben.

Mit freundlichen Grüßen
C. Weidmann

Hallo Herr Weidmann,

wenn was im Argen liegt dann mit den COM Registrierungen, die während des Setups durchgeführt werden. Diese werden mit bei einer Reparaturinstallation (über das normale Setup oder die Systemsteuerung) wieder gerade gebogen. Wie das Ihr RZ durchführen kann?

Die Reparaturinstallation sollte das letzte Mittel sein. Bevor Sie das tun prüfen Sie bitte ob Excel im Zusammenhang mit dem FlowHeater allgemeinen langsam läuft. Hierzu einfach mal die bestehende Definition unter einem neuen speichern und den Adapter auf der WRITE Seite auf Textfile Adapter ändern. Exportieren Sie zum Test das Excel Arbeitsblatt in eine einfache CSV Textdatei. Dann am besten das gleiche auch mal auf einem anderen Rechner durchführen. Wenn es hier große Unterschiede gibt stimmt was nicht mit der Excel Installation.

Ein Punkt ist mit noch eingefallen. Prüfen Sie mal folgenden Forumsbeitrag: Excel und Access Adapter ungewöhnlich langsam

Hallo Herr Stark,

Probleme mit der Excel Installation würde ich fast ausschließen, der Effekt tritt bei der Verarbeitung auf mehreren verschiedene Maschinen mit jeweils eigenen Office- und FlowHeater Installationen auf. Ich werde Ihren Vorschlag mit der Verarbeitung Excel zu Excel trotzdem noch prüfen um ganz sicher zu gehen.

Die Indexe auf dem SQL-Server habe ich überprüft, da ist mir nichts ungewöhnliches aufgefallen. Ich habe jedoch sicherheitshalber überall eine Reparatur durchgefürt -> Leider keine Verbesserung.

Die Thematik mit der Zertifikatsprüfung werde ich mir auch noch anschauen. Ich gebe Ihnen dann nochmal gesondert Rückmeldung.

Mit freundlichen Grüßen
C. Weidmann

Hallo Herr Weidmann,

läuft der neue SQL Server ansonsten performant oder hat sich das Verhalten im Allgemeinen verschlechtert, wenn auch sonst nur minimal?

Falls die gleiche Hardware verwendet wurde könnte es evtl. sein, dass der Server nun an seine Leistungsgrenzen gekommen ist und vermehrt Daten auslagern muss, das würde die längere Laufzeit erklären.

Auf der anderen Seite könnte evtl. ein Festplattenausfall (Raid) ebenfalls die Leistung des SQL Servers verschlechtern.

Es könnte durchaus sein, dass Sie in Ihrer Anwendung davon nichts merken, da hier evtl. nur minimal Daten gelesen/geschrieben werden. Bei der FlowHeater Verarbeitung werden permanent Daten geschrieben und der Effekt macht sich bemerkbar.

Hallo Herr Stark,

ansonsten läuft der Server performant, das Problem tritt eigentlich auch nur bei großen FlowHeater Jobs auf. Hier als Beispiel zwei Verarbeitungslogs:

Verarbeitung zeitlich i.O.:

FlowHeater (R) Batch Modul: Version 3.3.4
Start: 19.08.2014 17:30:22

Rows Read : 1287
Rows Fitter : 1287
Rows Write : 1287 Warnings : 13

Inserts : 1287
Updates : 0

End: 19.08.2014 17:30:29

Verarbeitung zeitlich nicht i.O.:

FlowHeater (R) Batch Modul: Version 3.3.4
Start: 19.08.2014 18:30:19

Rows Read : 225386
Rows Fitter : 225386
Rows Write : 225386 Warnings : 9

Inserts : 223357
Updates : 2029

End: 19.08.2014 20:43:52

Wenn man das Verhältnis von Verarbeitungsdauer zu Datensätzen des ersten Jobs auf den zweiten umrechnet, dürfte die Verarbeitung eigentlich nur ~20min dauern. Beide Jobs sind von der Verarbeitungsart her gleich eingestellt -> erst löschen, dann Tabelle neu schreiben.

In Richtung Serverhardware haben wir bereits etwas geforscht. Der Server kommt bei der Verarbeitung des großen Jobs tatsächlich bei der Prozessorlast an seine Grenze. Die Hardware wurde getauscht ist aber im Vergleich zum alten Windows Server 2003 System deutlich leistungsfähiger. einen Festplattendefekt können wir ausschließen, da wir diese Sachen engmaschig überwachen.

Mit freundlichen Grüßen
C. Weidmann

Hallo Herr Weidmann,

evtl. liegt das am unterschiedlichen Transaktionsverhalten der unterschiedlichen SQL Server Versionen? Hier hatte ich bisher noch keine Unterschiede feststellen können bzw. wurde auch noch nichts dergleichen hier gemeldet.

Wenn ich mir Ihren Ablauf ansehe, denke ich können wir hier noch einiges optimieren. Wenn Sie eh immer vorher die Daten löschen ist es denke ich nicht erforderlich eine Transaktion während des Importes zu verwenden, sowie sollten Sie bei der großen Datenmenge die gelöscht werden soll „TRUNCATE TABLE“ anstelle von „DELETE FROM“ verwenden. Im Screenshot sehen Sie wie das im SQL Server Adapter eingestellt werden kann.



Dann könnte evtl. der Import Vorgang so umgestellt werden, dass keine Updates durchgeführt werden, nur Inserts. Bei dem Massenimport werden zwar 2029 Updates durchgeführt, evtl. wäre es aber möglich während des Import Vorgangs mit dem Filter Heater und der Option auf Duplikate filtern dieser vorher zu filtern?

Hallo Herr Stark,

danke für die hilfreichen Optimierungsvorschläge! Ich habe den in meiner letzten Antwort aufgeführten, problematischen Job entsprechend umgebaut und werde morgen früh prüfen, wie sich die Verarbeitung jetzt verhält.

Mit freundlichen Grüßen
C. Weidmann

Hallo Herr Stark,

mit den Optimierungen haben wir eine signifikante Verbesserung bei den Verarbeitungszeiten erreicht. Der Job, der bisher ~2 Stunden lief, läuft jetzt nur noch 5min:

Start: 22.08.2014 18:30:22
Rows Read : 257628
Rows Fitter : 257628
Rows Write : 255598 Warnings : 6

Inserts : 255598
Updates : 0

End: 22.08.2014 18:35:58

Vielen Dank für Ihre Hilfe!

Mit freundlichen Grüßen
C. Weidmann