ORA-03106: fatal two-task communication protocol error bei größeren Datenmengen

Guten Tag, 

ich habe bei größeren Datenmengen Probleme mit dem Oracle-Adapter auf der READ-Seite. Die Definition überträgt jede Nacht Stammdaten in eine Archivdatenbank (SQL Server). Es werden über einen Zeitstempel nur veränderte Datensätze übertragen. Die Aufgabe läuft stabil und performant ab.

Aufgrund neuer Attribute im Quellsystem müssen nun alle Datensätze aktualisiert werden. Bei größeren Datenmengen bricht die Definition mit Fehler ORA-03106: fatal two-task communication protocol error ab. 
Insgesamt müssen ca. 10 Mio. Datensätze aktualisiert werden - beim Aufsetzen der Archiv-DB ist das auch schon ohne Probleme erfolgt. 

Aufgrund der Abbrüche habe ich bereits versucht, die Aktualisierung in Batches durchzuführen, eingeschränkt über das Anlagedatum der Datensätze. Batches von 300.000 Zeilen funktionieren ohne Probleme. Allerdings gibt es keine geeigneten Attribute, um alle Batches in dieser Größe zu halten. Sie sind bis zu 2 Mio. Datensätze groß.

Auffällig ist bisher, dass die Verarbeitung oft erst kurz vor dem erwarteten Ende abbricht. 

Haben Sie eine Idee, was diesen Fehler auslösen kann? Mich irritiert, dass der Fehler erst bei einer erhöhten Datenmenge auftritt, was in der Vergangenheit mit derselben Definition nicht zu Problemen geführt hat. 

Viele Grüße
Niko Stein 

Hallo Herr Stein,

bei der Analyse bin ich auf eine evtl. Erklärung gekommen. Verwenden Sie in der Definition den SQL Heater , Lookup Heater oder aber .NET Script Heater um damit weitere Werte aus evtl. anderen Tabellen von der READ Seite der Oracle Datenbank abzufragen?

Dann ist das Problem, dass der Oracle Adapter in diesem Fall eine Datenbank Transaction über die Gesamte Laufzeit aufspannt. Leider kann das mit der aktuellen Version auf der READ Seite nicht geändert werden.

In der aktuellen Beta Version wurde das Transaktionsverhalten dahingehend geändert, dass das Datenbank Transaktionsverhalten auch auf der READ Seite geändert werden kann.

Die aktuelle Beta Version können Sie über folgenden Link herunterladen: Download Beta Version

Hier bitte mal folgenden Einstellungen, siehe Screenshot unten, verwenden. Falls Sie nur lesend zugreifen also keine Updates, etc. auf der READ Seite verwenden können Sie die Transaktionen auch komplett deaktivieren.

 
 

Hallo Herr Stark, 

ich nutze in der Tat den SQL-Heater, das lässt sich aber vermeiden, da dieser lediglich für Logging-Zwecke genutzt wurde. Nach Entfernen des Heaters stoße ich aber auf ein neues Problem. 
Der Server-Manager stürzt leider mitten im Prozess ab und wirft "System.OutOfMemoryException." (entnommen aus der Log-Datei).

Die Datenmenge ist definitiv nicht unerheblich mit ca. 10 Mio. Datensätzen. Mich irritiert der Absturz mit dieser Exception allerdings, da ich in anderen Prozessen bereits in einem vorbereitenden Prozessschritt diese Datenmenge in den In-Memory-Adapter eingelesen habe, um hieraus via Lookup-Heater Informationen in eine Definition einfließen zu lassen. Direkt im Read-Adapter war das aufgrund unterschiedlicher Quell-DBs nicht möglich. 

Gibt es noch andere Auslöser für diese Exception, die ich prüfen kann? Ehe ich die Definition nun verändere, das Problem aber an ganz anderer Stelle verursacht wird, hoffe ich auf einen Tipp von Ihrer Seite. Zumindest nach meiner bisherigen Erfahrung ist Flowheater eigentlich in der Lage, diese Datenmengen zu verarbeiten. 

Danke und Gruß
Niko Stein 

Hallo Herr Stein,

die Datenmenge sollte eigentlich nicht das Problem sein. Zur weiteren Analyse bräuchte ich bitte noch ein paar Informationen.

1. Unter welcher Architektur (32/64 Bit) wird die Definition ausgeführt.
2. Evtl. die erstellte Definition oder aber eine Beschreibung was genau in den einzelnen Verarbeitungsschritten gemacht wird inkl. der Datenmengen.
3. Die Exception aus dem Logfile plus einige Zeilen vorher um zu sehen was genau den Fehler verursacht hat.
4. Stürzt wirklich der FlowHeater Server komplett ab und muss anschließend neu gestartet werden oder wurde nur die Aufgabe als Fehlerhaft markiert?
5. Wie sehen die Einstellungen bzgl. Datenbank Transaktion Handling auf der WRITE ( SQL Server Adapter ) Seite aus? Hier bitte ebenfalls den AutoCommit mal auf 100.000 einstellen.

Hallo Herr Stark, 

zu Ihren Fragen: 
1. 64 Bit
2. Verarbeitungsschritt 1 setzt nur einen Parameter (Uhrzeit Prozessbeginn). In Verarbeitungsschritt 2 wird der gesamte Artikelstamm ausgelesen und 1:1 in die Zieltabelle übertragen. Sind ca. 10 Mio. Datensätze. Es müssen alle aktualisiert werden. Einteilung in Batches wäre möglich, allerdings können immer noch Batches mit 2 Mio. Datensätzen vorliegen. 
3. vorher lief ein Prozess, der alle 5 Minuten gestartet wird. Ich hatte heute aus Versehen den Prozess nicht deaktiviert, daher wurde er wieder gestartet. Als ich den Prozess beenden wollte, erfolgte auch ein Abbruch inkl. Absturz des Server Managers. 

2024-02-20 10:25:00.645401 [Info] (Worker 5) : Start new process : C:\Program Files\FlowHeater Server V4\Versions\x64\4.3.5\FHBatch.exe "\\fileserver\FrickeDaten\WF Wilhelm Fricke\Logistik\Logistikcontrolling\Logistik DB\Flowheater Definitionen\Leitstaende\offene_positionen.fhd" - ServiceUser=svc_flowheater
2024-02-20 10:25:03.817494 [Info] (Worker 5) : Do Task: LS_offene_pos -> END - 3,187724 seconds
2024-02-20 10:28:29.233921 [Info] (ListenerNamedPipe) : Terminate task [Korrektur artikel - 01b95bfb-7fc7-4f5f-bfa8-48700c2b3547], User = FRICKE\P04623, ProcessID = 780
2024-02-20 10:28:29.343148 [Error] (Worker 6) : Task [Korrektur artikel],  Step [Deltaload]: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Text.StringBuilder.ToString()
   at FlowHeater.Server.FHService.ThreadWorker(Object data)
2024-02-20 10:32:14.775323 [Start] : Server Start

von Vortag: 
2024-02-19 14:30:04.143250 [Info] (Worker 4) : Do Task: LS_offene_pos -> END - 3,2587457 seconds
2024-02-19 14:34:28.319864 [Info] (ThreadMaintenance) : HealthCheck
2024-02-19 14:34:39.219423 [Error] (Worker 6) : Task [Korrektur artikel],  Step [Deltaload]: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Text.StringBuilder.ToString()
   at FlowHeater.Server.FHService.ThreadWorker(Object data)
2024-02-19 14:35:01.071928 [Info] (Worker 5) : Do Task: LS_offene_pos -> START
2024-02-19 14:35:01.087432 [Info] (Worker 5) : Start new process : C:\Program Files\FlowHeater Server V4\Versions\x64\4.3.5\FHBatch.exe "\\fileserver\FrickeDaten\WF Wilhelm Fricke\Logistik\Logistikcontrolling\Logistik DB\Flowheater Definitionen\Leitstaende\offene_positionen.fhd" - ServiceUser=svc_flowheater
2024-02-19 15:00:34.265040 [Start] : Server Start
2024-02-19 15:00:34.265040 [Start] : Service configuration at start time

4. Server stürzt ab, Neustart ist nötig, siehe Infos aus Logfile
5. Autocommit habe ich nun aktiviert. Ich teste das mal sukzessive mit kleineren Datenmengen - wobei diese ja vorher auch funktioniert haben. Einstellungen anbei. Timeout Einstellungen sind verändert, da ich hiermit in einer anderen Definition aufgrund hoher Datenmenge Probleme hatte. Da hatte es geholfen.  


Danke und viele Grüße
Niko

Eine Ergänzung: Auto Commit konnte das Problem nicht lösen. 500.000 Datensätze laufen durch, bei 1.500.000 Datensätzen stürzt die Anwendung wieder ab/hängt sich auf. Wenn ich dann im Server Manager versuche, etwas anzuklicken, kommt folgende Fehlermeldung - die vermutlich aber nicht Verursacher des Absturzes, sondern Symptom ist?
See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
   at FlowHeater.Server.Forms.frmHistory.LoadHistory()
   at FlowHeater.Server.Forms.frmHistory.FrmHistory_Load(Object sender, EventArgs e)
   at System.EventHandler.Invoke(Object sender, EventArgs e)
   at System.Windows.Forms.Form.OnLoad(EventArgs e)
   at System.Windows.Forms.Form.OnCreateControl()
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl()
   at System.Windows.Forms.Control.WmShowWindow(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Form.WmShowWindow(Message& m)
   at FlowHeater.Core.BaseWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Ein Nachtrag zu Verarbeitungsschritt 2: Hier wird über einen NET-Heater noch ein individuelles Logfile fortgeschrieben. Das hat allerdings auch bei dem letzten Prozess mit 1.500.000 Datensätzen noch funktioniert und einen Eintrag im Logfile erstellt. Den Heater nutze ich mit dem exakt selben Code in jeder Definition - letztlich ja auch bei der erfolgreich gelaufenen zuvor. Insofern kann ich mir nicht vorstellen, dass es daran liegt, wobei das das einzige ist, was nach der erfolgreichen Übertragung der Daten innerhalb der Definition noch passiert...

Vielleicht haben Sie ja eine Idee.

Danke und Gruß
Niko Stein 

Hallo Herr Stein,

nach intensiver Analyse wird das Problem dadurch verursacht, wenn im ausgefürhten Server Task Konsolenausgaben generiert werden die 2 GB übersteigen.

Sie können das Problem umgehen indem Sie versuchen so wenig wie möglich Logausgaben zu generieren. z.B. auf dem Reiter „Erweitert“ das „Erweiterte Logging“ deaktivieren, etc.

Alternativ dazu wurde der Fehler in der aktuelle Beta Version gefixt. Die aktuelle Beta Version können Sie über folgenden Link herunterladen: Download Beta Version