Kommunikationsproblem zwischen Delphiprog. und Oracle-DB

[nahpets]

wir haben ein Kommunikationsproblem zwischen Delphiprogrammen und Oracledatenbanken:

Delphi: 2007 Professional (Win 32) - vereinzelt auch Delphi 7

Oracle (UFT8):

PRODUCT|VERSION|STATUS
NLSRTL |11.1.0.6.0|Production
Oracle Database 11g Enterprise Edition |11.1.0.6.0|64bit Production
PL/SQL |11.1.0.6.0|Production
TNS for Linux: |11.1.0.6.0|Production

Der Zugriff aus Delphi auf die Datenbank erfolgt über die ODAC-Komponenten von Core Lab, Version: 6.20.0.11.

Auf Rechnern, auf denen die Programme ausgeführt werden, ist kein Oracleclient erforderlich.
Das Problem tritt auf einigen Rechnern mit und ohne Client auf, auf der Mehrzahl der Rechner tritt es nicht auf, leider aber auch auf dem Produktionssystem.

Alle Rechner laufen unter Windows XP, allerdings mit unterschiedlichem Stand in Bezug auf die Servicepacks und Updates. Eine Systematik, ob bestimmte Stände des Betriebssystems für das Auftreten des Problemes ursächlich sein könnten, ist nicht erkennbar. SP3 geht, SP2 geht nicht oder umgekehrt, ist kein mögliches Ausschlußkriterium, bei allen Ständen gibt es Rechner, mit auftretendem Problem bzw. ohne dieses Problem. Unterschiede in den Ländereinstellungen... konnten wir nicht erkennen. Einige Rechner sind keine physikalischen Rechner, sondern laufen als VMWare (alle auf einem VMWare-Server), auch hier konnten wir keine Systematik in Bezug auf das Auftreten, bzw. Nichtauftreten des Problemes feststellen.

Nun zu dem Problem:

Die Programme führen mehr oder weniger aufwändige SQL-Abfragen aus, erarbeiten die Ergebnisse und schreiben die Daten mittels der TOraLoader-Komponente bzw. mittels der TOraQuery in die Datenbank.

Auf Seite des Datenbankservers kann man sehen, dass die Abfragen vom Programm an die Datenbank geschickt wurden und die Datenbank die Ergebnisse bereitstellt und darauf wartet, dass der Client sie abholt. An dieser Stelle bleibt der Client stehen, hat keine CPU-Last und holt auch keine Daten. Dieser Zustand bleibt unverändert, bis man das Delphiprogramm per Taskmanager abbricht.

Einige Programme können dahingehend gesteuert werden, dass man ihnen per Eingabe einen Teilbereich (über die technischen Schlüssel) der Datenmenge angibt, der vom Programm bearbeitet werden soll. Hier kann es nun passieren, dass ein Teilbereich abgearbeitet wird, bei einem anderen Teilbereich die oben beschriebene Situation eintritt. Durch weitere Einschränkung der Teilbereiche lässt sich das Problem auf einige Datensätze reduzieren, die einzeln angesteuert das Problem verursachen. Bei vielen Million Datensätzen kann man hier aber unmöglich alle "Problemfälle" per "Try and Error" ermitteln. Die bisher manuell ermittelten Problemfällen lassen keinerlei Besonderheiten erkennen. Das Problem betrifft die unterschiedlichsten Datenbanktabellen, so dass man auf Datenbankseite auch kein einzelnes "Problemkind" ausfindig machen kann.

Hat jemand eine Idee, woran dieses Verhalten liegen kann oder wie man sich der Ursache nähern kann?

PS.: Habe leider nur bis Freitag Zeit, das Problem zu lösen

[Bernhard Geyer]

Schalt mal dein D7 das Memory-Leak-Reporting an. Unter D7 verwende mal FastMM mit aktivierten Reporting und schau mal ob evtl. dein Programm bei DB-Verbindungen/Datenaktionen speicherlücken hat.

[nahpets]

Hallo,

mehr wird nicht gefunden:

---------------------------
Unexpected Memory Leak
---------------------------
An unexpected memory leak has occurred. The unexpected small block leaks are:

13 - 20 bytes: Unknown x 7

Dies scheint aber bei allen problematischen Programmen identisch zu sein.

[ULIK]

Hast Du schon mal geschaut, ob vieleicht DB seitig irgendwelche Locks produziert werden?

Uli

[nahpets]

Hallo,

keine Locks, kein garnichts, das wundert uns ja so. Und immer nur von bestimmten Rechner Locks, von anderen aber nie? Es ist irgendwie absolut seltsam.

[ULIK]

Hm, wenn der Client hängen bleibt, könnt ihr die Daten dann noch

• per SQL
• per seperaten Delphi Programm mit ODAC

abrufen (wenn's von der Transaktion her möglich ist)?

[nahpets]

Hallo,

Zitat von ULIK:

Hm, wenn der Client hängen bleibt, könnt ihr die Daten dann noch

• per SQL
• per seperaten Delphi Programm mit ODAC

abrufen (wenn's von der Transaktion her möglich ist)?

Ja, wenn das Programm auf Rechner X hängt, kann ich (wenn's auch nicht sinnvoll ist) es auf Rechner Y starten und es erledigt seine Aufgabe in Sekundenschnelle.
Die Transaktionsklammern sind so, dass ich auf anderen Rechnern ggfls. "veraltete" Daten erhalte, bis eben ein Programm seine Aufgabe mit Commit abgeschlossen hat.

[Alex O.]

Hallo!
als Tipp:

• gibts auf den Clients vielleicht eine Exception oder einen Oracle-Error?
• Wird die Exception vielleicht irgendwie verschluckt (Try/Except)?
• kontrolliere mal das Oracle-Trace-File (auf dem DB-Server unter [Oracle-Home]\diag\rdbms\[Instanzname]\trace, oder so ähnlich), das nennt sich Alert.Log - dort sollten ev. Oracle-Fehler auch aufgezeichnet werden

[ULIK]

Den DB Monitor von DevArt hast Du schon aktiv geschaltet? Ansonsten fällt mir eigentlich nur noch RemoteDebugging ein (auf euren Delphi-Rechnern könnt ihr das Problem nicht nachvollzeihen, richtig?). Halt, noch was: habt ihr MadExcept eingehängt? Wenn ja, dann stellt doch mal dort ein, daß er alles über 60 Sekunden Inaktivität als Freeze erkennen soll. Dann solltet ihr am Bugreport sehen, wo genau er hängen bleibt.

[nahpets]

Hallo,

Zitat von Alex O.:

gibts auf den Clients vielleicht eine Exception oder einen Oracle-Error?

Wird die Exception vielleicht irgendwie verschluckt (Try/Except)?

kontrolliere mal das Oracle-Trace-File (auf dem DB-Server unter [Oracle-Home]\diag\rdbms\[Instanzname]\trace, oder so ähnlich), das nennt sich Alert.Log - dort sollten ev. Oracle-Fehler auch aufgezeichnet werden

zu 1.: Nein, weder Exceptions noch Oracle-Error, was an Fehlern auftritt wird grundsätzlich in eine Logdatei des Programmes geschrieben, zusätzlich schreiben wir auch den Verarbeitungsfortschritt. Das Letzte, was wir sehen, ist: Führe SQL xyz aus (xyz steht für das vollständige Statement mit sämtlichen Parametern). Danach steht das Programm. Auf der Datenbank sehen wir, dass das Statement dort angekommen ist und ausgeführt wurde. Wenn wir das richtig interpretieren, steht die Ergebnismenge zur Abholung bereit.
zu 2.: Habe da jetzt schon mehrere dutzend Male drüber geschaut, meiner Meinung nach wird keine Exception verschluckt. Try-Except-Blöcke sehen eigentlich immer so aus: Im Except wird der Fehler gefangen, protokolliert, ggfls. aufgeräumt und dann die Exception per Raise weitergereicht.
zu 3.: Werde schauen, ob ich da mal an die Maschine darf mit 'nem Admin, der weiß wo die Files liegen. Von der "Baustelle" habe ich fast keine Ahnung. Gesagt, getan: Zum fraglichen Programm sind dort keine Einträge zu finden

Zitat von ULIK:

Den DB Monitor von DevArt hast Du schon aktiv geschaltet? Ansonsten fällt mir eigentlich nur noch RemoteDebugging ein (auf euren Delphi-Rechnern könnt ihr das Problem nicht nachvollzeihen, richtig?). Halt, noch was: habt ihr MadExcept eingehängt? Wenn ja, dann stellt doch mal dort ein, daß er alles über 60 Sekunden Inaktivität als Freeze erkennen soll. Dann solltet ihr am Bugreport sehen, wo genau er hängen bleibt.

"DB Monitor von DevArt" habe ich ebensowenig zur Verfügung wie MadExcept. Da müsste ich erstmal durch die Hierarchien und um Erlaubnis bitten, für 'nen Externen leider nicht so ganz einfach
Und wie das so ist: Auf Entwicklungsrechnern haben wir das Problem nicht.

Remotedebuggen wäre mal noch 'nen Versuch wert. Brauche auch dazu den Admin vom Produktivsystem, damit der den Job mal startet und ich dann draufschauen darf.

Noch eine neue "Erkenntnis": Das Programm bleibt nur beim Start gegen bestimmte Datenbanken hängen, aber nicht gegen alle. Haben eben nochmal ausprobiert: Gegen Datenbank X geht's, gegen Datenbank Y nicht. Die Datenbanken sind identisch (laut Admin), da sie voneinander "geklont" wurden. Auch der Datenbestand müsste noch (weitgehend) identisch sein. Die Datenbanken befinden sich jedoch auf unterschiedlichen Servern. Vom Entwicklungsrechner läuft das Programm gegen beide Datenbanken problemlos mit annähernd identischer Laufzeit und identischer Datenmenge.