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.

[jmy0123445]

Auch OT
@jobo
Zunächst mal: die Sätze hätte ich auch schreiben können. Bin aber Dienstleister. Ich kann den Kunden auf diese Probleme hinweisen, was ich getan habe. Aber es ist nicht meine Entscheidung.

Zitat:

Ohne Schadenfreude: rechnet sich sowas? Monetär? Qualitativ? Uptime? Responsetime?

Frag mal das Management, was aktuell so ziemlich alles was vorhanden ist, in die Cloud legt.
Im speziellen Fall: falls die Applikation langsamer wird, schlucken das in der Regel die Subs. Der "eigentliche" Kunde (product owner) nutzt das Produkt nur, um Daten nachzuschauen und engineered damit nicht mehr.
Die (gesamt-)Kosten kann ich nicht beurteilen. Das aktuelle Rechenzentrum ist alt und wird halt geschlossen. man braucht keinerelei eigene Hardware mehr, keine eigene IT mehr usw. Letztlich kann ich das nicht beurteilen

Zitat:

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.

Großer internationaler Konzern. Es wird alles nur noch ausschließlich monetär beurteilt. Und im IT Bereich spart man halt. Ob es dann woanders mehr kostet ist doch dem Entscheider egal. Andere Kostenstelle. Er hat die Kosten in seinem Bereich erfolgreich gesenkt. Hier sind ganz viele lokale (gute) IT-ler nicht mehr da, die waren sicherlich teuer. Ganzes Rechenzentrum entsorgt. Da kommt was zusammen.
Der Rest wird dann in Projekten versteckt. Wenn dann die Anlage vielleicht statt 100.000.000 EURO 1.000.000 EUR mehr verschlingt, weil die Tools alle bescheiden sind: whoe cares. Problem des Projektes.
Es ist ein gesellschaftliches Problem. Es wird nur noch ausschließlich auf Kosten geschaut. Hauptsache mein Budget/Projekt/Arbeitspaket ist perfekt. Aber hier könnte ich ganze Romane drüber verfassen. Hat sich auch sehr gewandelt in den letzten 25 Jahren. Neue Entwicklungsprojekte habe ich quasi gar nicht mehr in meinem Umfeld. Also da, wo man wirklich mal was wirklich! Neues macht/erfindet. Immer nur abgekupfert und weiterentwickelt. Aber die Kaufleute haben gewonnen, auch wenn das alles seine Berechtigung hat. Durch das Homeoffice wird das Ganze noch befeuert werden.

[jmy0123445]

Ein kleines Update.

Aktuell bin ich noch nicht sicher. Ich habe im Applikationsverzeichnis den neuesten 32 bit Oracle Treiber abgelegt - das war vorher auch schon der Fall. Wir haben aber nie eine lokale sqlnet.ora zusammen mit dem Instant Client verwendet.
Dieses haben wir jetzt ergänzt. die sqlnet.ora sieht aktuell jetzt folgendermassen aus:
DISABLE_OOB=ON
SQLNET.INBOUND_CONNECT_TIMEOUT=120
SQLNET.OUTBOUND_CONNECT_TIMEOUT=120
SQLNET.SEND_TIMEOUT=120
SQLNET.RECV_TIMEOUT=120
TCP.CONNECT_TIMEOUT=120

Der Parameter DISABLE_OOB=ON hat eine deutliche Verbesserung gebracht. Auch wenn ich es mir nicht aktuell erklären kann, kommen seit der Ergänzug des DISABLE_OOB und den Timeout Parametern keine Fehlermeldungen mehr. Wobei sich die Timeout Parameter noch gar nicht erklären (da in Sekunden).
Ich werde das nochmal aus anderen Netzwerken probieren.

Aktuell ist es nur eine Zwischenstand.

[jmy0123445]

Hallo,

nur noch mal eine kurze Info. In der Tesdatenbankumgebung scheint alles jetzt mit den genannten Parametern zu arbeiten, genau wie im Post zuvor beschrieben.
Es wird jetzt eine Produktivumgebung erzeugt, hier werden wir nochmal alle Funktionen des Programms im Detail testen, sofern das bei dem Monolithen möglich ist .
Der Test in der Produktivumgebung wird in Summe ein paar Wochen in Anspruch nehmen. Sollten sich noch Updates ergeben, werde ich die an dieser Stelle ergänzen. Ansonsten sehe ich zum jetzigen Zeitpunkt das Thema als gelöst an.