Inoffizielles deutsches Xbase-Forum

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

du könntest genau den Fehler der kommt in der Situation abfangen und einige Male wiederholen bevor du ihn durchlässt.

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

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

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

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

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 !

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

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.)

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.

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 !

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

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?

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.

Herbert hat geschrieben:Wenn aber SQ-Lite sich derart verhält, warum wurde dies dann von Alaska auserkoren?

erst in der "Pro" Version gibt es die ISAM Schnittstelle zu PostgreSQL als "richtigen" SQL Server.

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 ?

AUGE_OHR hat geschrieben:

Herbert hat geschrieben:Wenn aber SQ-Lite sich derart verhält, warum wurde dies dann von Alaska auserkoren?

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

Hallo Jan,

Jan hat geschrieben: DBFDBE_LIFETIME steht auf 0

Du arbeitest doch aber mit FOXCDX, oder?

Somit solltest Du folgendes einstellen: Wenn Du nun FOXDBE_LIFETIME auf 0 setzt, ist es ganz wichtig, auch CDXDBE_LIFETIME auf 0 zu setzen: 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).