Oracle ORA-12637 XE7/FireDAC

[jmy0123445]

Hallo,

1.Vorpann
erstmal nach sehr langer Zeit ein fröhliches 'Hallo' in die Runde. Und danke an alle Aktiven als stiller Mitleser. In den letzten Jahren gab es nur wenig Probleme mit unseren DELPHI Applikationen. Einige unserer Projekte laufen nun seit Beginn von DELPHI 32 Bit. Also feiern jetzt silberne Hochzeit. Die Applikationen könnten mich glatt noch in die Rente begleiten, was ich damals nie gedacht hätte. Vor allem bei der zwischenzeitlichen Entwicklung von DELPHI.

2. Systemumgebung

Aktuelle Konfiguration
* Betriebssystem Window 10 20H2 (nativ und Remotedesktop)
* Entwicklungsumgebung DELPHI XE7 mit FireDAC
* Oracle Datenbank 12C, in Rechenzentrum gehostet und über Zscaler v3.1.x erreichbar

Zukünftige Konfiguration (nativ und Remotedesktop)
* Betriebssystem Window 10 20H2
* Entwicklungsumgebung DELPHI XE7 mit FireDAC
* Amazon RDS for Oracle (AWS), Amazon Cloud und über ZScaler v3.1.x erreichbar

Wir haben eine recht komplexe Datenbankanwendung unterwegs, die aktuell mit einer Oracle Datenbank 12c R2 arbeitet. Die Anwendung hat nun besagte 25 Jahre auf dem Buckel. Die Client Anwendung greift über FireDAC auf die Oracle Datenbank zu. Entwicklungsumgebung ist Delphi XE7. Eine Aktualisierung auf die neuen DELPHI Versionen will der Kunde aktuell nicht durchführen, auch wenn es mir lieber wäre. Allerdings gibt es ein paar Komponenten, die wir immer wieder anpassen müssen, da der Vendor nicht mehr existiert. das kann manchmal aufwändig sein, vor allem auf Grund des Testings.
Die Anwendung lief bis 2015 unter Windows XP. Der Datenbankzugriff erfolgte über die BDE. Im Rahmen einer Windows 7/10 Umstellung wurde die Anwendung angepasst und die BDE durch FireDAC ersetzt. Auch wenn nicht alles optimal geworden ist, so hat damals die Umstellung erstaunlich gut geklappt. Auch wenn viele Strukturen historisch gewachsen sind und man es heute nicht mehr so implementieren würde.933

3- Problem
Die Datenbank Oracle 12C R2 soll in die Cloud migriert werden. Dies hat soweit funktioniert. Zugriff über DBeaver und Oracle SQL Developer scheinen sauber ohne Fehlermeldung zu funktionieren. Mit einer älteren ZScaler Version (3.0.x) kam es auch dort zu den unten beschriebenen Fehlern.
Unsere Datenbankanwendung erzeugt beim Starten so ca. jedes 10. mal den Fehler ORA-28547. Dann startet die Anwendung gar nicht. Damit könnten wir leben, ist aber auch unschön.
Deutlich häufiger tritt aber der Fehler ORA-12637 - packet received failed auf. Er scheint zunächst keinerlei Auswirkungen zu haben, in seltenen Fällen stürzt das Programm aber ab. Meine Debugging Möglichkeiten sind aktuell begrenzt (IT Einschränkungen).

Meine Frage:
Ist dieser Fehler ORA-12637 bei jemandem schon mal aufgetreten?
Gibt es da vielleicht Möglichkeiten, im Connection String Timeout Werte zu setzen?
Gibt es da möglicherweise Möglichkeiten. dies in den FireDAC Komponenten zu erledigen?
Habt ihr da vielleicht Empfehlungen oder andere sachdienliche Hinweise?
Ist der Fehler vielleicht

Ich stehe mit den verantwortlichen bei Amazon und dem datenbankteam in direktem Kontakt (direkter Kontakt, nicht irgendwelche telefonischer Support, es sind die Personen, die auch die Migration durchgeführt haben), ebenso mit der verantwortlichen IT. Aber auch da komme ich nicht wirklich weiter. Bei Embarcadero habe ich auch schon angefragt, bisher aber noch nichts gehört.

Mein Bauchgefühl ist, dass die Kommunikation über den ZScaler manchmal verzögert abläuft, so dass Antworten vom Datenbankserver stark verzögert werden und im Client quasi ein Timeout erezeugen. Unter ZScaler 3.0.x war eine Kommunikation gar nicht möglich, auch nicht mit dem SQL Developer. Aktuell ist es mir nicht möglich, die Anwendung zu debuggen bzw. eine spezielle Version mit mehr Debug Meldungen zu erzeugen. Da die Datenbankzugriffe auf Grund der alten Sourcen teilweise sehr verteilt sind, wäre es auch schwierig, da einen Fehler exakt zu bestimmen.

Ich danke euch für die Unterstützung. Sourcen kann ich aktuell nicht beisteuern, da ich nicht weiß, wo und wann der Fehler auftritt. Er tritt immer unvermittelt auf und nicht bei bestimmten Operationen oder Funktionen.

Sorry für den vielen Text. Sollte ich anderweitig eine Problemlösung finden, werde ich die hier auf jeden Fall weitergeben.

Gruß
Martin

[jmy0123445]

Noch eine kleine Ergänzung:

habt ihr mit diesen Werten in der sqlnet.ora bei diesem Fehler Erfolge erzielen können?
SQLNET.INBOUND_CONNECT_TIMEOUT
SQLNET.OUTBOUND_CONNECT_TIMEOUT
SQLNET.SEND_TIMEOUT
SQLNET.RECV_TIMEOUT
TCP.CONNECT_TIMEOUT

[jobo]

Ich habe mal viel mit Oracle gearbeitet, zunächst ware es eine LAN Anwendung, später WAN über VPN. Nie einen solchen Fehler gehabt.

Ein schneller Blick ins Netz spricht vor allem von älteren System (kleiner als 12c), von HS Anwendungen (Heterogeous Services) u.ä.
Ist das bei Dir der Fall?

Welchen Oracle(!) Client verwendest Du? Der muss ja nicht zur DB passen?
Und wenn schon Migration, warum auf so ein altes System? Ich mein, ich wäre nicht mal auf die Idee gekommen, dass es noch im Angebot ist.
Habt Ihr Oracle Support? Wahrscheinlich nicht...

ZScaler kenne ich nicht, was macht der? Ist das Amazon? Oder Third Party? Oder Oracle selbst?

P.S.: Die beiden funktionierenden Anwendungen sind beide Java Anwendungen, die den Oracle Client Deines Programmes nicht nutzen. Das zeigt also (immerhin) dass die Konnektion grundsätzlich funktioniert. Und es zeigt vielleicht auch, dass nicht der Server, die Cloud (und der Scaler?) das Problem ist, sondern alles ab dem Oracle Client abwärts, vielleicht vor allem der.
Wenn Du es nicht weißt, prüfe auf jeden Fall die Client Version, prüfe ebenfalls eine aktuelle Version (so hoch wie geht).

[jmy0123445]

Danke dir. Oracle 32 Bit Clients habe ich von 11.x bis 19.6x 32 Bit alle durch. Die grundsätzliche Konnektivität ist gegeben.
Die Datenbank läuft als Oracle RDS (AWS), also in der Cloud. In unserem Fall unter RDS mit Oracle 19c, Version 19.0.0.09. Also keine alte Oracle Version. Die Migration wird auf Grund der Abschaltung des alten Rechenzentrums durchgeführt.

Die alte funktionierende Version Oracle 12C läuft in einem "normalen" Rechenzentrum, die neue Plattform dann halt bei Amazon (Kosten).
ZScaler ist quasi ein VPN (stimmt so nicht ganz). Welche ZScaler Funktionen unser Endkunde nutzt, ist mir nicht bekannt. Global player, ist nicht immer einfach an Infos zu kommen.

Zwischenzeitlich habe ich mit den Parametern gespielt
SQLNET.INBOUND_CONNECT_TIMEOUT
SQLNET.OUTBOUND_CONNECT_TIMEOUT
SQLNET.SEND_TIMEOUT
SQLNET.RECV_TIMEOUT
TCP.CONNECT_TIMEOUT
Da scheint es beser zu werden, aber das ist noch nicht belatsbar. Ich werde mich da nochmal mit dem Amzazon DB Team auseinandersetzen müssen, die haben auch Zugriff auf Oracle und den Support. Ist alles etwas schwierig, die Infos muss ich mit Indern, Amis, Deutschen usw. abklären, da vergeht immer Tag um Tag auf Grund der Zeitverschiebungen.
Ich kriege in den nächsten Tagen hoffentlich mehr Infos zusammen. Evtl. kann ich auch meine Entwicklungsumgebung live anbinden, dann wird es einfacher. Aber davor sind wie immer die Kosten


Embarcadero ist auch schon angefragt. Mal schauen wie lange da was dauert, bis Infos kommen. Auf jeden Fall vielen Dank für deine Infos.

gruß
martin

[Bernhard Geyer]

Welche Oracle-Client verwendet ihr?
Wenn ihr jetzt mit AWS eine 19er Oracle hat, dann sollte auch der Oracle Client (wir nutzen den instant Client, damit unsere Clients nicht durch den "Oracle-Client-Installer" nicht kaputt-"georacled" werden.

Auf Delphi-Seite kann man auch versucht von FireDac auf die DevArt-Kompnenten zu wechseln, um diese Fehlerquelle auszuschließen/minimieren.

[jmy0123445]

Hallo,

mit dem Client nutzen wir immer den Instant Client im Application Verzeichnis, um das "veroraclen" zu vermeiden . Aktuell nutzen wir den 19er 32 Bit Instant Client. Aber wie gesagt, habe ich auch mal so ziemlich alles zwischen 11 und 19 getestet.

Die DevArt sind aktuell keine Alternative. Führt hier zu weit, aber die BDE war damals überall im Code verteilt. Ich war schon froh, dass das mit FireDAC gut funktioniert hat. Ist auch keine kleine Anwendung. Da ist mal mit eben nichts getan. Die Migration verspricht zwar eine 100%ige Umsetzung. Aber wenn wir alles testen müssen, sind wir da schon ein paar Wochen weiter.

PS: schön zu hören, dass andere mit den Oracle Install Allüren auch gewisse Erfahrungen gesammelt haben

[jobo]

OT

Es ist auch schön zu hören, wie es in der Cloud so gehen kann.

Ohne Schadenfreude: rechnet sich sowas? Monetär? Qualitativ? Uptime? Responsetime?
Oracle ist ja nicht der Einzige, der super Gewinnzuwächse in der Cloud verzeichnet.
Und wenn man die Datenbank Datensatz für Datensatz verkauft, ist es ja auch kein Wunder.
Erinnert etwas an die Idee von Dr. Oetker, Backpulver in 5g Tüten zu verkaufen- nein, ich bin nicht neidisch. Und dann ist da noch der Plattformbetreiber, der die Hand aufhält.

Und das sind nur die Kosten, kein Support usw.. Wobei ich vermute, dass man "normalen" Oracle Support haben könnte, wenn man wollte und zahlte und das dann auch zu den heimischen Bürozeiten.

Warum tut man sich das an bei einem Altsystem? Bei einem neuen kann es ja bessere Gründe geben.