Datenbankfehler bei DbSeek()

Zugriff, Engines, Konvertierung. Von ADS über DBF bis zu SQL.

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Datenbankfehler bei DbSeek()

Beitrag von Jan »

Moin,

nach der Serverumstellung bei meinem Kunden hatten wir da enorme Probleme mit Betriebssystemfehlern beim DbSeek() Erstmal war natürlich ich schuld, falsche Programmierung. dann stellte sich aber heraus, das der ESXi durch heftige Umstrukturierungen etc. dermaßen am Limit lief, das der enorm hohe Latenzen hatte. Der wurde neu durchgestartet, und plötzlich waren alle Fehler weg. Soweit so schön.

Seit ein paar Tagen kommt dieser Fehler aber wieder. Sehr sporadisch zwar nur, etwa 2-3x am Tag. Was aber mindestens 2-3x zu viel ist ... Meine Rückfrage bei den Admins ergab, das die Latenzen auf dem ESXi bei maximal sauberen 50 ms liegen. Aber sporadisch auch mal auf bis zu 250 ms hochziehen. Nur als kurzer Peak, nicht dauerhaft.

Da auf Grund der früheren Erfahrungen vermute, das genau diese Latenzen die Ursache für die Probleme sind: Wie bekomme ich FOXCDX dazu, etwas mehr zu warten beim DbSeek()? Es gibt da die Einstellung FOXDBE_LIFETIME, aber die betrifft nach meinem Verständnis etwas anderes.

Hat jemand eine Idee? Oder wie ich das sonst irgendwie lösen kann?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von brandelh »

du könntest genau den Fehler der kommt in der Situation abfangen und einige Male wiederholen bevor du ihn durchlässt.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von brandelh »

Entweder global in der XppError.PRG oder lokal z.B. indem du dbSeek() mit NetSeek() ersetzt und in der Funktion eine lokale Fehlerbehandlung einführst.

Bei der CDXDBE (Indexteil wird von dbseek benutzt) gibt es aber auch diese Parameter, die meiner Meinung nach dafür da sind das zu tun was du möchtest:

DBE_LOCKMODE => LOCKING_STANDARD muss auch beim LESEN locken, eventuell ist das andere Verfahren für dich besser
CDXDBE_LOCKRETRY => Wiederholungsversuche
CDXDBE_LOCKDELAY => Wartezeit zwischen Wiederholversuchen
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von Jan »

Hallo Hubert,

ja, an sowas hatte ich auch schon gedacht. Ich benutze in einem anderen Programm ein myDbSeek(), das eine Sequenze-Schleife drin hat (da gab es immer die tollen 8889-Fehler). Aber ich hatte gehofft, das es eine einfachere Möglichkeit geben könnte. Wie ein einfacher Eintrag in die dbesys.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von brandelh »

Jan hat geschrieben:Aber ich hatte gehofft, das es eine einfachere Möglichkeit geben könnte. Wie ein einfacher Eintrag in die dbesys.
hast du das gelesen: CDXDBE :!:

DBE_LOCKMODE => LOCKING_STANDARD muss auch beim LESEN locken, eventuell ist das andere Verfahren für dich besser
CDXDBE_LOCKRETRY => Wiederholungsversuche
CDXDBE_LOCKDELAY => Wartezeit zwischen Wiederholversuchen
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von Jan »

Hallo Hubert,

wir haben LOCKING_EXTENDED eingestellt. Und ich hab gerade mal nachgesehen: DBFDBE_LIFETIME steht auf 0

CDXDBE_LOCKRETRY und CDXDBE_LOCKDELAY kannte ich jetzt noch nicht. Dürfte hier aber auch nicht helfen, da die Fehlermeldung beim Seek() kommt. Das nun wirklich kein Locking versucht.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von brandelh »

HALLO JAN !!!

und woher weist du das wieder ????

Bei LOCKING EXTENDED sollte die Indexdatei nur beim Schreiben gelocked sein, aber gerade bei SEEK darf der Indexbaum keinesfalls geändert werden solange SEEK aktiv ist.
Mit der Standardeinstellung wird die Indexdatei IMMER beim LESEN (== SUCHEN ... wie sollte es sonst gehen) gesperrt, einen Versuch wäre es doch wert oder ?

KEINESFALLS hat die FOXDBE etwas mit DBSEEK() am Hut, denn die wird erst angesprochen, sobald der Satz gefunden wurde !
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von Jan »

Hmm ...

Das würde aber bedeuten, das wenn ein Rechner im Netz permanent und ununterbrochen Seek()s sendet, niemand sonst irgendwas speichern kann? Weil der Seek()-Rechner permanent alles blockiert?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von brandelh »

das sind natürlich nur ms, aber JA, deshalb bringt es etwas das locking auf extended umzustellen, dann muss das System nicht mehr so viel die Indexdatei sperren.
Weil diese Operationen aber auch so häufig sind ist es besonders problematisch wenn hier etwas daneben geht (SMB2 settings etc.)
Gruß
Hubert
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von Herbert »

Hubert, da bin ich nicht deiner Meinung.
Der Schlüssel zeigt immer auf den richtigen Satz, egal ob nebenher etwas verändert wird oder nicht.
Das wäre ja katastrophal, wenn dem nie so gewesen wäre.
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenbankfehler bei DbSeek()

Beitrag von AUGE_OHR »

Herbert hat geschrieben:Hubert, da bin ich nicht deiner Meinung.
ich bin der Meinung von Hubert.

warum kann man, im Netzwerk, schon bei einem SKIP oder SEEK einen 8999 bekommen ... das hat was mit SMB zu tun !
es geht dabei NICHT um ein "File" locking sondern um das SMB locking wo man gar nichts mit DBESYS anstellen kann !
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von brandelh »

Herbert hat geschrieben:Hubert, da bin ich nicht deiner Meinung.
Der Schlüssel zeigt immer auf den richtigen Satz, egal ob nebenher etwas verändert wird oder nicht.
Das wäre ja katastrophal, wenn dem nie so gewesen wäre.
Hallo Herbert,

bei einem korrekten Index (ich meine die nutzen B-Tree) wird die Suche den korrekten Satz (intern vermutlich als Satznummer) finden.
Damit dieser korrekt bleibt :!: :!: :!: wird standardmäßig der Index komplett gesperrt (das habe ich aus einer Erklärung von Alaska zu dem neuen Locking Schalter für die Indexe).
Sobald hierbei etwas schief geht, ist man eben nicht mehr auf dem richtigen Satz ... und wenn das Netzwerk länger braucht als die DBE eingestellt hat ...

Aber du darfst gerne anderer Meinung sein ... ich habe ja nicht behauptet, dass dies genau die Lösung für JANs Problem ist.
Es ist aber - von der Beschreibung her - genau das was Jan wollte ... und man muß halt ausprobieren was geht und ob es besser wird.
Oder man jammert über die Fehler oder nimmt gleich einen "richtigen SQL Server" ...

Auf einem lokalen Rechner spielt das alles keine Rolle JEDE lokale Platte ist schnell genug um alles in der erwarteten Zeit zu erledigen.
Auch bei einem Citrix-Server bzw. nun Terminalserver mit EXE und DBF auf lokaler Festplatte dürfte das Problem nicht auftreten, da auch hier nur lokale Zugriffe stattfinden.

Tatsache ist aber, dass im Netzwerk mit zunehmender Komplexität die Probleme steigen und selbst in der Anleitung zu "SQLite" (das ich intern zur Fehlervermeidung nutzen wollte) steht,
dass kein Redirektor fehlerfrei ist und der gemeinsame gesharte Zugriff auf die SQLite Datei nicht empfohlen werden kann. Danach habe ich es gelassen ...

... und ja, früher war alles besser und wir hatten noch nie defekte Indexdateien :roll:
Gruß
Hubert
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von Herbert »

Ui, was löse ich da aus.
Das auch professionelle DB-Systeme sich kontrollieren müssen, versteht sich.
Hubert hat geschrieben: Tatsache ist aber, dass im Netzwerk mit zunehmender Komplexität die Probleme steigen und selbst in der Anleitung zu "SQLite" (das ich intern zur Fehlervermeidung nutzen wollte) steht, dass kein Redirektor fehlerfrei ist und der gemeinsame gesharte Zugriff auf die SQLite Datei nicht empfohlen werden kann. Danach habe ich es gelassen ...
Wenn aber SQ-Lite sich derart verhält, warum wurde dies dann von Alaska auserkoren? :confused2:

Ich habe mit meiner Aussage nicht direkt auf Jan's Problem Bezug genommen. Ich wollte antönen, dass es auch einen anderen Grund haben könnte.
Erreicht das DB-System den Seek vor einem Update-Befehl einer anderen Station, wird dieser zuerst abgearbeitet, anschliessend erfolgt der Update im Index (zusammen mit dem Anpassen der Daten in der Tabelle) - und umgekehrt. Da hat die lokale dbe nichts damit zu tun, wie Jimmy auch schreibt. Ausser einer zieht den Stecker. Aber ich sehe das wohl zu trivial.
Diverse Nebenprotokolle und Timer geben Dinge vor. Verpasst das System diese Zeiten, müsste ein Retry seitens des auftraggebenden Programms erfolgen. Oder nicht? Da wäre Alaska gefragt. Aber das sehe ich wohl wieder zu trivial.
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenbankfehler bei DbSeek()

Beitrag von AUGE_OHR »

Herbert hat geschrieben:Wenn aber SQ-Lite sich derart verhält, warum wurde dies dann von Alaska auserkoren? :confused2:
erst in der "Pro" Version gibt es die ISAM Schnittstelle zu PostgreSQL als "richtigen" SQL Server.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von brandelh »

Herbert hat geschrieben:Ui, was löse ich da aus.
Das auch professionelle DB-Systeme sich kontrollieren müssen, versteht sich.
...
Ich habe mit meiner Aussage nicht direkt auf Jan's Problem Bezug genommen.
Ich wollte antönen, dass es auch einen anderen Grund haben könnte.
die gesharten DBF Dateien haben das gleiche Problem wie SQLite, nämlich dass die Hersteller der Betriebssysteme diese Zugriffsart als veraltet ansehen.
Daher wird weniger getestet und daher ist dieser "gesharte file" Zugriff so problematisch.
OB nun Alaska bei der SMB Problematik etwas falsch macht oder nicht kann ich nicht beurteilen (das sagt Jimmy), ich habe nur auf die Schalter hingewiesen, die bei der CDX anpassbar sind.
Persönlich halte ich es aber für besser eine eigene Funktion mit lokaler Fehlerbehandlung zu machen, die protokolliert dass ein solcher Fehler aufgetreten ist und erst nach einigen Versuchen einen echten Laufzeitfehler bringt.

In einer Situation habt Ihr aber Recht, dass es auch an der Daten-DBE (hier FOXDBE) liegen könnte, nämlich WENN der aktuelle Satz gesperrt war und DBSEEK() ODER DBSKIP() ODER ... einen Satzwechsel auslöst, muss auch die Daten DBE die Buffer leeren und neu einlesen.
Wenn der Fehler beim Buffer leeren / neu Einlesen auftritt, ist es egal was den Satzwechsel ausgelöst hat.

PS: für solche Protokolle habe ich gerne eine "set alternate to xyz ADDITIVE" benutzt.
Nun musste ich feststellen, dass dies keine gute Idee ist, da es durchaus wahrscheinlich ist, dass mehrere gleichzeitig das Probleme haben und auf die gemeinsame Datei zugreifen wollen.
Dafür ist die "set alternate" aber nicht ausgelegt. Mann sollte für jeden Rechner eine eigene vorsehen und exclusiv offen halten, aber bei Netzwerk Problemem kann dies dann auch wieder Fehler produzieren, denn wo liegt diese ? ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenbankfehler bei DbSeek()

Beitrag von brandelh »

AUGE_OHR hat geschrieben:
Herbert hat geschrieben:Wenn aber SQ-Lite sich derart verhält, warum wurde dies dann von Alaska auserkoren? :confused2:
erst in der "Pro" Version gibt es die ISAM Schnittstelle zu PostgreSQL als "richtigen" SQL Server.
Ich persönlich würde SQLexpress (ODBC => vom SQL-Server unabhängig) oder die API Schnittstelle von Hektor vorziehen, damit bleibt man unabhängig und auf Standard SQL ;-)
Gruß
Hubert
Sören
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 205
Registriert: Mo, 07. Aug 2006 10:18
Wohnort: Leipzig
Danksagung erhalten: 11 Mal

Re: Datenbankfehler bei DbSeek()

Beitrag von Sören »

Hallo Jan,
Jan hat geschrieben: DBFDBE_LIFETIME steht auf 0
Du arbeitest doch aber mit FOXCDX, oder?

Somit solltest Du folgendes einstellen:

Code: Alles auswählen

DbeInfo( COMPONENT_DATA, FOXDBE_LIFETIME, 0 )
Wenn Du nun FOXDBE_LIFETIME auf 0 setzt, ist es ganz wichtig, auch CDXDBE_LIFETIME auf 0 zu setzen:

Code: Alles auswählen

DbeInfo( COMPONENT_ORDER, CDXDBE_LIFETIME, 0 )
Solltest Du die LIFETIME der Data-Komponente auf 0 gesetzt, die der Order-Komponente jedoch auf
dem Default-Wert belassen haben, wirst Du sporadisch Betriebssystemfehler erhalten (das war bei mir so,
bis ich es bemerkt hatte).
Beste Grüße,
Sören
Antworten