Mysteriöses Problem [ERLEDIGT]

Advantage Database Server

Moderator: Moderatoren

Antworten
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Mysteriöses Problem [ERLEDIGT]

Beitrag von UliTs »

Hallo allerseits.

Am Freitag wollte ich bei einem Kunden eine größere Programm- und Datenbankänderung einspielen.
Zunächst habe ich dafür die aktuellen Daten in eine Testumgebung dupliziert. Die Testumgebung verwendet den gleichen ADS wie die echte Umgebung. Das Konvertieren der Daten auf die neue Struktur hat inklusive Trigger und referentielle Integritäten wunderbar geklappt! Dann habe ich den normalen Arbeitsablauf inklusive Ändern der Testdaten simuliert. Dabei kam es reproduzierbar zu Fehlern in der Kommunikation mit dem ADS bis hin zum Absturz des ADS. Da der ADS auch für die echte Umgebung eingesetzt wurde, kam es dadurch auch da zum sofortigen Stillstand. Das ist für die Firma (und damit erst recht für mich) so ziemlich das Schlimmste, was passieren kann (zu toppen nur noch durch Zerstörung der Daten). Positiv war, dass man den ADS innerhalb weniger Sekunden wieder neu starten konnte!
Während der Programmierphase hatte ich zwar auf meinem Entwicklungs-Rechner auch hin- und wieder beim Testen Probleme, dass die Verbindung zum auf meinem Rechner installierten ADS während des Programmablaufs verloren ging, aber der ADS hat sich nie "aufgehängt".
--
Hier ein paar Hinweise zur Umgebung: eingesetzt wird ein Linux-ADS, Version 10.1. Prinzipiell gibt es ein Data Dictionary mit ADT-Tabellen und historisch bedingt noch weitere DBF-Tabellen (die in den nächsten 12 Monaten möglichst alle in das Data Dictionary integriert werden sollen). Ich glaube, die Probleme hängen nicht mit den DBF-Tabellen zusammen. Der Zugriff auf die ADT-Tabellen erfolgt durch:
- intensiven Einsatz von Transaktionen
- Verwendung von SQL-Update/Insert-Befehlen zur Datenänderung
- Verwendung von OpenTable/Post/-Befehlen zur Datenänderung
- Protokollierung von Datenänderungen in einer "Protokoll.adt"-Tabelle durch Trigger aber auch manuell durch Verwendung von Post()-Befehlen.
--
Zum Glück lief anschließend das Programm auch auf meinem Entwicklungsrechner nicht mehr rund, so dass ich sinnvoll experimentieren konnte. Ich habe anschließend die Änderung der Protokoll-Tabelle vollständig auf SQL-Insert/Update Befehle umgeändert. Danach lief das wieder einwandfrei auf meinem Entwicklungsrechner :) .
--
Verständlicherweise ist das Vertrauen des Kunden in den ADS durch die Vorfälle ordentlich erschüttert worden und er möchte wissen, wie es zum Absturz des ADS kommen konnte :? .
--
Gibt es bekannte Probleme/Konstellationen, durch die es zum Absturz des ADS kommen kann?
Ist es sinnvoll, möglichst auf Post()-Befehle zu verzichten und Änderungen ausschließlich durch SQL-Insert/Update/Delete Befehle durchzuführen. Läuft dann der ADS viel stabiler?
--

Uli
Zuletzt geändert von UliTs am Do, 28. Nov 2013 13:56, insgesamt 1-mal geändert.
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
nightcrawler
1000 working lines a day
1000 working lines a day
Beiträge: 650
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72184 Weitingen
Hat sich bedankt: 3 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von nightcrawler »

dem ADS ist es egal, ob die Datenänderungen über SQL oder ISAM kommen - intern wird eh alles nach ISAM übersetzt. Das Problem des Absturzes lässt sich hier in der NG nicht klären - ich würde dazu einen Supportfall aufmachen. Das wichtigste ist erst einmal, die error logs zu studieren - welcher Fehler hat zum Absturz geführt, was lief unmittelbar davor ab. Als zweites dann eine Analyse der DUMP-Dateien (Speicherabbild, kann nur die Enwicklung mit passendem MAP-File), falls der ADS beim Absturz einen Dump geschrieben hat. Dieser zweite Schritt bedingt das Hinzuziehen des Supports - sonst bekommt man diese Dump-Datei nicht zu den Entwicklern.
Meine Erfahrung aus 13,5 Jahren ADS (incl langer Zeit im Support): ein Absturz hat zu 99% der Fälle mit der Server-Plattform zu tun (Betriebsystem, Dateisystem, Hardwarefehler, ...) und ist daher nur in ganz wenigen Fällen auf einer anderen Maschine nachvollziehbar. Ein Dump zeigt aber genau die Stelle, an welcher es passiert ist und dan kann man Rückschlüsse ziehen.
--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von UliTs »

Ich habe mal im ads-Verzeichnis errorlogs nachgeschaut.
Da gibt es 12 Byte große Dateien mit Namen adsdump-2013*.dmp, die höchstwahrscheinlich bei den Crashs angelegt wurden.
Inhalt immer gleich:
  • 01 00 00 00 01 00 00 00 00 00 00 00
In der ads_err.adt habe ich nichts auffälliges gefunden.

Wo kann man einen Supportfall aufmachen?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
nightcrawler
1000 working lines a day
1000 working lines a day
Beiträge: 650
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72184 Weitingen
Hat sich bedankt: 3 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von nightcrawler »

--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von UliTs »

Ich habe jetzt doch noch in meiner Testumgebung wieder einen Fehler provozieren können:
  • ---------------------------
    Fehler!
    ---------------------------
    (6633) :The Advantage Database Server did not respond to a database request in a timely manner while using inter-process communications. Zusatz: Error 6633: The Advantage Database Server did not respond to a database request in a timely manner while using inter-process communications. axExecuteSQL
    ADSExecuteSQL within ACESQLStmt:Exec wrong!
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von UliTs »

Was mir dabei gerade noch aufgefallen ist:
Die Advantage Management Utility des ARC zeigt unter "Work Areas" current used=132, max used=134, configured=125 an.
Kann das zu Problemen führen?
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
Magic
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 343
Registriert: Mo, 11. Jul 2011 12:01

Re: Mysteriöses Problem

Beitrag von Magic »

Nach meiner eigenen Erfahrung ein ganz klares JA. Ob es auch für Dein Problem verantwortlich gemacht werden kann, ist nicht ganz so einfach zu sagen. Diese Zahlen sagen ja schon mal zumindest dass irgendetwas nicht in Ordnung ist.
Wir setzen den ADS schon seit mehreren Jahren ein (mittlerweile seit Jahrzehnten) und hatten keinerlei Probleme als wir nativ direkt nur aus Clipper, später Xbase auf den Server zugriffen. Im laufe der Zeit kamen immer mehr Anwendungen die auch über ODBC / OLEDB auf die ADS zugriffen. Seit dem haben wir in unregelmäßigen Zeitabständen (3-6 Monaten) eben auch solche Konstellationen. Wenn ich es früh genug merke starte ich den ADS einfach neu (entladen und laden der NLM reicht aus) und dann ist wider Ruhe. Merke ich es nicht, knallt es irgendwann mit irgendeiner Fehlermeldung, die nicht immer korrekt ist. Ab da geht dann erstmal nichts mehr, bis die NLM neu geladen wird. I.d.R. kündigt sich das an, wenn die Zahl der Users größer wird als die der Connections. Wer (welches Programm/Ereignis) nun für dieses "Durcheinander" tatsächlich verantwortlich ist lässt sich kaum nachvollziehen, da es seht schleichend aufgebaut wird.
Gruß,
Magic
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von UliTs »

Magic hat geschrieben:...Wenn ich es früh genug merke starte ich den ADS einfach neu (entladen und laden der NLM reicht aus) und dann ist wider Ruhe...
Das ist hier leider nicht der Fall :-( . Wenn der ADS neu gestartet wird hängt er sich innerhalb 180 Sekunden bei Nutzung des neuen xBase-Programms sofort wieder auf.
Das Blöde ist, dass ich dies kaum testen kann, da hiervon jedes Mal auch die reale Umgebung betroffen ist angry9: .

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von brandelh »

Ich würde suchen ob Dateien offen bleiben ohne dass dies nötig bzw. gewünscht ist.

PS: habe ich das richtig verstanden, dass du lokal (Entwicklung) anders zugreifst als in Produktion (TCP/IP) ?
Falls das so ist, würde ich das ändern und immer über (TCP/IP) zugreifen ...
Gruß
Hubert
Benutzeravatar
nightcrawler
1000 working lines a day
1000 working lines a day
Beiträge: 650
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72184 Weitingen
Hat sich bedankt: 3 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von nightcrawler »

UliTs hat geschrieben:Ich habe jetzt doch noch in meiner Testumgebung wieder einen Fehler provozieren können:
  • ---------------------------
    Fehler!
    ---------------------------
    (6633) :The Advantage Database Server did not respond to a database request in a timely manner while using inter-process communications. Zusatz: Error 6633: The Advantage Database Server did not respond to a database request in a timely manner while using inter-process communications. axExecuteSQL
    ADSExecuteSQL within ACESQLStmt:Exec wrong!
Uli
Äh....das ist aber nicht gegen den Linux-Server und von daher wieder eine andere Konstellation. IPC geht nur, wenn Client und Server auf derselben Maschine gestartet sind. Passen denn die DLLs zueinander und zum Server?
--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de
Benutzeravatar
Magic
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 343
Registriert: Mo, 11. Jul 2011 12:01

Re: Mysteriöses Problem

Beitrag von Magic »

UliTs hat geschrieben:Das Blöde ist, dass ich dies kaum testen kann, da hiervon jedes Mal auch die reale Umgebung betroffen ist
Um derartiges zu testen habe ich einen zweiten ADS aufgesetzt. Eine entsprechende Entwicklerlizenz gab (gibt?) es direkt bei SysBase. Es bedeutet zwar mehr Aufwand, aber dann hat man die gewisse Ruhe wenn man solch einen Fall nachvollziehen will.
UliTs hat geschrieben:Wenn der ADS neu gestartet wird hängt er sich innerhalb 180 Sekunden bei Nutzung des neuen xBase-Programms sofort wieder auf.
Da kannst Du doch schon mal den ADS eigentlich außen vor lassen. Das Problem wird also eindeutlich vom Programm verursacht. Entweder schließt Du die Connection zum ADS bevor sie wieder benutzt wird, oder das Programm baut unheimlich viele Connections auf (evtl. bei jedem DB Zugriff?) und läuft dann quasi über (dafür würden Deine Zahlen von WorkAreas, etc. deuten). Ich würde eher auf letzteres tippen.
Gruß,
Magic
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von UliTs »

nightcrawler hat geschrieben:Äh....das ist aber nicht gegen den Linux-Server und von daher wieder eine andere Konstellation. IPC geht nur, wenn Client und Server auf derselben Maschine gestartet sind. Passen denn die DLLs zueinander und zum Server?
Nein, in meiner Testumgebung habe ich Windows XP auf meinem Rechner und auf diesem läuft sowohl das xBase-Programm als auch der ADS 10.1.

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von UliTs »

Magic hat geschrieben:Da kannst Du doch schon mal den ADS eigentlich außen vor lassen. Das Problem wird also eindeutlich vom Programm verursacht. Entweder schließt Du die Connection zum ADS bevor sie wieder benutzt wird, oder das Programm baut unheimlich viele Connections auf (evtl. bei jedem DB Zugriff?) und läuft dann quasi über (dafür würden Deine Zahlen von WorkAreas, etc. deuten). Ich würde eher auf letzteres tippen.
Da bin ich anderer Meinung. Ein Anwenderprogramm darf es nicht schaffen, den Datenbank-Server zum Absturz zu bringen. Ich prüfe in meiner Umgebung noch einmal nach, ob die Work Areas nicht sauber geschlossen werden. Da ich in der neuen Version SQL-Statements intensiv immer wieder ausführe ohne sie zwischendurch zu schließen, ist die Anzahl der Work Areas naturgemäß jetzt wesentlich höher.

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von UliTs »

Ich habe auf dem Server noch eine Fehlerdatei ads_log.txt gefunden:
  • Message: SEGV detectd. Writing snap dump and suspending Advantage daemon.
Das Schreiben der Dump-Datei schafft der ADS anscheinend dann nicht mehr.
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem

Beitrag von UliTs »

nightcrawler hat geschrieben:...Passen denn die DLLs zueinander und zum Server?
Im Juli kam eine Meldung das es einen neuen ARC (Data Architekten) gibt. Diesen hatte ich damals auch installiert. Zwei DLLs sind da neuer:
ace32.dll Version 10.10.0.49 (statt 10.10.0.6 bisher)
axcws32.dll ebenfalls Version 10.10.0.49 (statt 10.10.0.6 bisher)
Ich werde die bisherigen Versionen durch die Neuen ersetzen. Hoffentlich kann man das einfach machen...

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem [ERLEDIGT]

Beitrag von UliTs »

Letzten Freitag habe ich intensiv getestet und wahrscheinlich das Problem gefunden.
1) DLLs getauscht :)
2) ein mehrere 100kb großes Sql-Update-Statement durch eines mit Parametern ersetzt. :D
Danach tauchten keine Probleme mehr auf.

Weiß jemand, ob es eine Obergrenze für die Größe des SQL-Statements gibt?
Gibt es auch eine Obergrenze für die Größe eines Parameters?

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
nightcrawler
1000 working lines a day
1000 working lines a day
Beiträge: 650
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72184 Weitingen
Hat sich bedankt: 3 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

Re: Mysteriöses Problem [ERLEDIGT]

Beitrag von nightcrawler »

--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Mysteriöses Problem [ERLEDIGT]

Beitrag von UliTs »

Na ja...
Wie man es nimmt. Danach kann der Fehler nicht am großen SQL-Statement gelegen haben...
Vielleicht ist es doch ein Bug in der 10.1.

Uli

P.S. Die Online-Doku ist wirklich gut :!:
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Antworten