Version 4 unbrauchbar langsam (Oracle Adapter)

Bisher verwendeten wir V4 x64 Alpha 8.
Ohne irgendeine Nachricht wurde dies zur Demo-Version, obwohl unsere Lizenz installiert war, schlecht.
Nachdem ich diese nun gemerkt habe, habe ich sofort V4 x64 final installiert.
Meine Oracle Verbindungen verarbeiten nun ca 1 Satz pro 15 Sekunden, schlecht.
Mit alpha 8 waren die selben FHs noch performant.

Nachdem ich nun 3.5.4 wieder installiert habe, alle Jobs angepasst und alle FH Files modifiziert habe, läuft es mit FH V3 wieder normal. Da ist defintiv was faul an V4.

Zu früh gefreut, immer noch demo-Mode obwohl Lizenz in V4 und V3 eingespielt ist.
Jede Definition nochmal neu Abspeichern?
Das ist alles nicht sehr produktions-gerecht. grrr.

Hallo Herr Worch,

es wurden drei Kleinigkeiten im Oracle Adapter von der Alpha bzw. Beta Version zur finalen V4 geändert.

1. Bessere Datentyp Erkennung beim Auslesen der Schema Informationen


2. Beim Exportieren Unterstützung von gleichnamigen Feldnamen wenn mehrere Tabellen per JOINS verknüpft sind


3. Aktualisierte Third Party Datenbank Treiber für den Zugriff auf Oracle Datenbanken

Ich will jetzt nicht ausschließen, dass es evtl. an Punkt 3 liegt aber meine Messungen die ich eben durchgeführt habe sehen soweit gut aus. Für eine weitere Analyse bräuchte ich etwas mehr Informationen.

1. Geht es um Daten Import, Export oder sind beide Richtungen betroffen?


2. Welchen Verbindungstyp verwenden Sie: Oracle TNS Names oder Direktverbindung?


3. Läuft die Verarbeitung im Designer sowie über das Batch Modul gleich langsam oder gibt es Unterschiede?


4. Welche Oracle Datenbank Version setzen Sie ein?


5. Wie viele Datensätze sollen/werden Verarbeitet?


6. Ist der Export/Import von Anfang an langsam oder schaukelt sich das Ganze mit der Zeit auf?

Hallo Herr Stark
Hier ein Video welches das Verhalten dokumentiert:
http://1drv.ms/1ODcsRA
Im Video ist zu sehen, wie 3.54 alle 57 Sätze in 4 Sekunden verarbeitet und dann V4
auf 5 Sätze limitiert über eine Minute dauert.

Ob Batch oder interaktiv ändert nichts.
Anzahl Records hat keinen Einfluss, jeder Schreibvorgang scheint 15 Sekunden zu dauern.
Oracle Database 11g Release 11.2.0.4.0 - 64bit Production
Ich gleiche eine Tabelle zwischen zwei Schemas auf dem selben Oracle Server ab.

Alle Verbindungen direkt, identische FHs.

Hier noch ein anderes Beispiel, dass sich auch etwas anders verhält:
http://1drv.ms/1NjPGuT
Zuerst mit 3.54 welches die Anzahl auf 50 limitiert (in der registrieten Version!, dass sollten
Sie wirklich überdenken) und verarbeitet alles 'sofort'.
Danach die V4 wie in Zeitlupe, aber beim 'Fitter', nicht beim Schreiben, und nicht ganz so schlimm.

Gleicher Setup wie zuvor, und diesmal auch 1:1 identische FHs

Hallo Herr Worch,

vielen Dank für die Videos, waren sehr hilfreich.

Die Verzögerung tritt im Fitter während der Transformation auf und nicht beim Lesen/Schreiben über den Oracle Adapter . Im Video ist zu erkennen, dass Sie einen weiteren Layer angelegt haben. Ist hier ein SQL Heater / oder Lookup Heater im Einsatz der evtl. eine weitere Verbindung zur Oracle Datenbank aufbaut um Daten für eine Bedingung , Filter etc. abzurufen?

Könnten Sie evtl. die betroffene Definition posten oder mir per Email zukommen lassen?

Um sicherzugehen, ob nicht doch die neueren Oracle Datenbanktreiber dafür verantwortlich sind wäre folgender Test hilfreich für eine weitere Analyse. Bitte kopieren Sie aus dem V3 BIN Ordern alle Dervart.XXXX.dlls über die DLLs im V4 BIN Ordner. Anschließend starten Sie die Version 4 und führen die Definition erneut aus. Wenn es hiermit schneller geht sind die neueren Treiber dafür verantwortlich. Dann muss ich auf den Hersteller zugehen.

Zu Ihrer Frage bzgl. Limitierung der Datensätze in der Registrierten Version. Diese Limitierung wurde in Version 3 eingebaut, in Version 4 ist das so nicht mehr vorhanden. Wenn Sie die betroffene Definition einmalig mit der registrierten Version 3 speichern kann diese Definition wieder normal ohne Limitierung verwendet werden.

Hallo Herr Worch,

das Problem wurde mit Version 4.0.0.2 behoben. Die Problematik hat nicht der Oracle Adapter verursacht sondern eine fehlerhafte Verarbeitung im „Memory Modus“. Der „Massdata Modus“ war/ist davon nicht betroffen.

Vielen Dank für Ihre Unterstützung bei der Fehlersuche