Verzögertes dbunlock() im Terminalserverbetrieb

[easyberty]

Hallo,

ich habe bei einem Kunden im Terminalserver-Betrieb seit einiger Zeit das Problem, dass eine Datensatzsperrung immer wieder erst nach sehr langer Zeit freigegeben wird.
Der Quellcode, der beim Anklicken des [Eintragen]-Buttons abgearbeitet wird, ist grundsätzlich

Code: Alles auswählen

If rlock()
   replace x with y etc.
   dbcommit()
   dbunlock()
else
   confirmbox("Datensatz ist gesperrt")
endif

Das dbunlock() findet aber oft erst nach Minuten oder gar nicht statt.

WAS TUN???

Gruß easyperty

[AUGE_OHR]

ich habe bei einem Kunden im Terminalserver-Betrieb seit einiger Zeit das Problem, dass eine Datensatzsperrung immer wieder erst nach sehr langer Zeit freigegeben wird.
Der Quellcode, der beim Anklicken des [Eintragen]-Buttons abgearbeitet wird, ist grundsätzlich

Das dbunlock() findet aber oft erst nach Minuten oder gar nicht statt.

was für ein OS() und welche Xbase++ Version ?

[easyberty]

OS()=WINDOWS 2003 R2 Service Pack2
XBASE-Version 1.90.331

Wäre schön, wenn das weiterhilft! Es scheint auch so zu sein, dass das Programm gelegentlich im Hintergrund "weiterläuft", ggf. nach einem Absturz mit einer XPPERROR.LOG-Meldung

Gruß easyberty

[brandelh]

Hi,

grundsätzlich braucht man keine dbcommit() mehr verwenden, das macht das dbunlock() selbst.

Liegen die Dateien eigentlich auf dem TerminalServer lokal oder auf einem Dateiserver ?
Wurden auf dem Server die DBF, DBT, NTX, CDX, FPT - also Daten und Indexdateien - von der
Virenprüfung ausgenommen ?
Ein Virenscanner, der alle Zugriffe prüft kann den Server gewaltig bremsen und DBF etc. sind völlig ungefährlich !

Wieviele USER sind gleichzeitig auf der Datei aktiv ?

[easyberty]

Hallo,

ich denke, die Dateien sind auf dem Dateiserver - es ist ein terminalserver-Betrieb. Wie viele User zugreifen - es sind manchmal bis zu 5) sollte unerheblich sein, da die Sperrung und Freigabe sich auf den individuellen Datensatz und nicht auf die komplette DBF-Datei bezieht und der Datensatz ja nur von einem Anwender bearbeitet wird.
Ich habe beim Kunden mehrfach darauf hingewiesen, dass der Ordner, in dem sich die DBFs befinden, aus dem Virenscanner herausgenommern werden muss, da es mit Scanner schreckliche Dinge gab - es wurden einzelne Datensätze gelöscht, was mir völlig unverständlich ist. Es ist also davon auszugehen, dass kein Virenscanner zugreift - wobei es immer noch vorkommt, dass Datensätze verschwinden, was ein Indiz dafür wäre, dass doch...
Gibt es sonst noch eine Erklärung?

Gruß easyberty

[urbi]

Hallo easyberty,

ich hatte vor etwa zwei Jahren änliche Probleme mit dbunlock() für die ich auch keine Erlärung fand.
Nach einsatz der folgenden Function sind keine Probleme mehr aufgetreten.

Code: Alles auswählen

FUNCTION UUNLOCK()
LOCAL ErrorBlock, bSaveError := ErrorBlock() 
ErrorBlock( {|e| Break(e)} ) 
BEGIN SEQUENCE      
   DBUNLOCK()
RECOVER USING oError 
   ErrorBlock( bSaveError ) 
   SLEEP(20)
END SEQUENCE 
ErrorBlock( bSaveError )    
RETURN NIL

Gruß
Rainer

[easyberty]

Hallo Rainer,

es ist immer wieder verblüffend, dass man zwar die Ursache nicht kennt, aber trotzdem eine Lösung findet!
Vielen Dank; ich werde deine Funktion gerne ausprobieren. Es hätte mich dennoch brennend interessiert, wo der Grund liegt!

Liebe Grüße
easyberty

[urbi]

währe schön etwas über Erfolg oder Misserfolg zu hören

Gruß
Rainer

[easyberty]

Klar, nur wird das etwas dauern

Nochmal danke, Gruß easyberty

[brandelh]

Hi,

die Funktion wartet nach einem Fehler 20/100 Sekunden, bevor es den Befehl wiederholt.
Möglich, dass dazwischen einige Arbeiten abgeschlossen wurden. Insbesondere gleichzeitige Zugriffe von Virenscannern

Eventuell könnte auch die Änderung der folgenden Werte für dich interessant sein:

Handbuch => DBFDBF, FOXDBE etc.

DBFDBE_LIFETIME kürzer oder länger ...
DBFDBE_LOCKMODE DBF_AUTOLOCK - kann verbesserungen bringen, ist aber mit Clipper nicht mehr kompatibel. Blockiert eventuell auch das Lesen, geht aber schneller

DBE_LOCKMODE LOCKING_EXTENDED soll schneller sein, wenn mehr ansehen als ändern ...

NTXDBE_LOCKRETRY diese beiden könnten zum Blockieren führen, wenn sich zwei Prozesse im Wege stehen ....
NTXDBE_LOCKDELAY eventuell beide auf 0 setzen und einen MSGBOX("Konnte nicht Speichern, bitte nochmals versuchen ...") aufrufen.

Die Reaktionszeit ist zufällig und die Rechner haben Zeit ....

[easyberty]

Vielen Dank für euer Engagement!

Da die geschilderte Problematik nur bei dem einen Kunden auftritt - und das auch erst (wieder) seit kurzer Zeit, denke ich, es hat tatsächlich etwas mit einem Virenscanner zu tun, der heimlich wieder installiert wurde.
Ich habe den Kunden gebeten, noch mal in sich zu gehen und das zu prüfen. Wenn tatsächlich kein Scanner installiert sein sollte, muss es ein anderes Hemmnis geben.
Ich werden dann die vorgeschlagenen Maßnahmen abarbeiten, was aber letztlich nur ein Kurieren der Symptome bedeuten würde - immer noch besser als gar nix!

Danke,
easyberty

[AUGE_OHR]

OS()=WINDOWS 2003 R2 Service Pack2
XBASE-Version 1.90.331

bei W2K3 würde ich auf OpLocking tippen wenn du Viren Scanner etc ausschliessen kannst.

[easyberty]

Hi Jimmy,

was ist OpLocking und was kann man dagegen tun??

Gruß easyberty

[Rolf Ramacher]

Hi berXbase spezifisch:

- SL1 fertig zum runterladen. Komplette Verson 1.90.355
- Feedback an Alaska Wünsche ect. wird in ca. 2-3 Wochen fertig sein Info kommt noch
- Auflistung Active-X- Befehle bei Windows-Hilfe mal schauen
- Mit SL1 Source/Ownerdrawing/ Beispiele für Visuelle Styles
- Hardware/Software Infos mit WMI - http://www.activexparts.com
- Wenn Word/Excel dann über den DSO-Framer geht zwar auch mit xbpHtmlViewer
aber Focus usw. funkt. nicht korrekt
- Xbp-Bin/Ownerdrawing gibt es xppdl.bat beinhaltet Beschreibung für den
Formdesigner bezlg. Visuelle Styles


Hinweis zu Netzwerken:

- OP-Locking ausschalten
beim Client HKEY/Local_Machine\System\CurrentControlSet/Services
MRXSmb\Parameters\OpLocksDisable=1
beim Server – bis Services \Lanman\Server\Parameters\EnableOplocks=0
es reicht eigentlich beim Server
- Antivirprogramm keine dbf/ntx/cdx/fdt/dbt - scannen
- Power.Saiving der Netzwerkkarte ausschalten
- Auto-Disconnect Server ausschalten
- Kein Vista ohne SP


Langes öffnen beim use:

- Gleiche bis Services \SharingViolation\Delay=0 bzw. Retrieves=0 – nur Server

DbAppend schon mal Probleme

1- Einstellung nach Services \Lanmanworkstation\DisableFlushOnCleaning=1
2- Latenzzeit ist eintscheidend – testen mit ping z.B.
ty

hier ist ein auszug vom letzten Forentreffen in Rösrath. zusammengestellt von Steffen Pirsig von alaska -

kannst du ja mal prüfen.

[Markus Walter]

Hi,
die Funktion wartet nach einem Fehler 20/100 Sekunden, bevor es den Befehl wiederholt.
Möglich, dass dazwischen einige Arbeiten abgeschlossen wurden. Insbesondere gleichzeitige Zugriffe von Virenscannern

Hi Hubert,
wo siehst Du denn da, dass der Befehl wiederholt wird? Oder habe ich heute einen ganz schlechten Tag?

[brandelh]

das ist meine 'lockere' Übersetzung der Einstellungsparameter:

NTXDBE_LOCKRETRY
NTXDBE_LOCKDELAY

und steht in etwa so in der Hilfe:

NTXDBE_LOCKRETRY a 100000 N Anzahl der Wiederholungsversuche
NTXDBE_LOCKDELAY a 15 N Wartezeit zwischen Wiederholversuchen

ich verstehe das so, dass das Datenbankobjekt standardmäßig 100.000 mal Versucht einen Satz besser die NTX zu sperren,
bevor eine Fehlermeldung erfolgt und 15/100 Sekunden zwischen den Versuchen gewartet wird.

Ich kann mich natürlich auch irren, aber warum solle es diese Parameter überhaupt geben.

[Tom]

OpLocking ist auf Terminal-Servern irrelevant, da es das Caching auf Workstations regelt.

Auch das DbCommit() ist in dieser Topologie eigentlich überflüssig. Wenn man nach einem REPLACE sicherstellen will, dass die Daten auch erkennbar werden, genügt ein DbSkip(0), aber auch das ist prinzipiell redundant. Die Frage aber ist, ob hier wirklich das DbUnlock() bremst. Es ist durchaus möglich, dass es die REPLACE-Operationen selbst sind, wenn etwa große Indexdateien parallel aktualisiert werden müssen. Hier wäre Extended Locking das Mittel der Wahl - und die Suche nach einem heimlich doch noch aktiven Virenscanner wäre tatsächlich empfehlenswert.

[brandelh]

OpLocking ist auf Terminal-Servern irrelevant, da es das Caching auf Workstations regelt.

bist du dir da sicher ? Das Programm auf dem Terminal-Server selbst, das auf die Daten über das Netz auf den Datenserver zugreift, nutzt die "Workstation"-Einstellungen.
Genauso wie der Serverpart auf der Workstation die Servereinstellungen nutzt.

Richtig ist, dass dbunlock() alle vorherigen Dateioperationen erst tatsächlich umsetzt.
Daher kommen viele Fehlermeldungen erst beim dbunlock(), der tatsächliche Fehler liegt aber weiter vorne ...

[Markus Walter]

Hi Tom,
hi Hubert,

Hubert hat recht, wenn die Daten nicht physikalisch auf dem TS liegen, sondern dieser per Netz auf einen Fileserver zugreift. Eine eher "unsinnige" Konstellation, da man sich damit den Vorteil des lokalen Zugriffs holt. Aber manche Admins sind da nicht zu überzeugen, ich habe diese Konstellation leider auch bei zwei Anwendern...

[Tom]

bist du dir da sicher ?

Absolut. OpLocking ist ein Teil des SMB-Protokolls, und das spielt im TS-Betrieb schlicht und ergreifend überhaupt keine Rolle. Der Terminal Server wäre schön blöd, wenn er die Emulation der verschiedenen Desktops intern über SMB regeln würde, das hier auch keinen Sinn hat, da der Rechner schließlich nicht mit sich selbst vernetzt ist.

[Tom]

Hallo, Markus.

Auch in dieser Konstellation wäre der TS der einzige Client. In diesem Fall wäre OpLocking sogar sinnvoll.

[brandelh]

Hi,

bei uns laufen meine Programme auf bis zu 5 TS (die Namen der Maschine logge ich, so kann ich mitzählen und den Admins sagen wenn einer beim Update vergessen wurde)
die gleichzeitig auf die eine Netzfreigabe auf dem Datenserver zugreifen. Mann sollte also keine voreiligen Schlüsse ziehen
Sinnvoller wäre es aber in der Tat, sowas auf einer Maschiene zu halten, wenn es irgendwie geht, von der Serverlast eigentlich kein Problem ...
aber die Datenserver werden gesichert, die anderen nicht ... und bei allem anderen geht es auch so ...

[Tom]

Hallo, Hubert.

Sobald irgendwie genetzwerkelt wird, also SMB auf Datenebene (!) relevant wird, kommt OpLocking (jedenfalls vor SMB2, da werden dann wieder andere Dinge interessant) ins Spiel, das ist richtig. Bei einem "klassischen" Terminal-Server-Betrieb (ein Server, alle Clients greifen per remote zu) jedoch nicht. Sollte es sich bei der hier geschilderten Ausgangssituation also um genau diese handeln, ist OpLocking völlig irrelevant. Davon abgesehen dürfte es auch im anderen Fall nicht die Ursache für eine deutlich spürbare Verzögerung sein. Ich schrub's schon anderswo - an diesen ganzen OpLocking-Stellschrauben dreht man m.E. aus reiner Hilflosigkeit, aber nennenswerte Wirkung haben sie nach meiner Beobachtung auch im intensiv konkurrierenden Netzwerkbetrieb eher nicht. Wir haben das bei sehr, sehr vielen Kunden beobachtet, aber unterm Strich kaum messbare Veränderungen erkennen können.

Übrigens. Wenn hier tatsächlich ein TS-Server mit einem gesonderten Fileserver arbeitet und Vista/7/Server 2008 laufen, könnte die Ursache im Caching der Datei-Metadaten (SMB2) liegen. Das müsste dann aber auch mit Datenverlusten einhergehen.

Erfahrungsgemäß sind es a) Virenscanner oder b) das Problem ist hausgemacht - und die Fehlerursache wird an der falschen Stelle gesucht. Monitoring z.B. mit FileMon (SysInternals) könnte helfen, weil man da sehen könnte, welche Dateizugriffe in welchen Zeitfenstern stattfinden, und was sie ggf. bremst.

[Markus Walter]

Hallo, Markus.

Auch in dieser Konstellation wäre der TS der einzige Client. In diesem Fall wäre OpLocking sogar sinnvoll.

Hi Tom,

klar, wenn es sich nur um einen TS handelt und alle über den arbeiten.

Wir haben (leider) häufig die Situation, dass einige "Workstations" per TS arbeiten (z. B. Filialen oder Ehefrau von zu Hause), andere aber "normal" über Netz (die TS-Lizenzen kosten schließlich Geld und das geben meine Anwender nur sehr ungern aus). Somit "Mischbetrieb". In der Regel haben unsere Anwender dann aber nur einen Server (eben mit aktivierten TS-Diensten). In zwei Fällen haben wir aber einen TS (1x sogar 2 Stück), einen Fileserver und zusätzlich arbeiten manche Workstations noch über Netz.

[Tom]

Hallo, Markus.

Ja, solche Konstellationen haben wir auch. In dieser Situation muss man sich z.B. mit der SMB2-Problematik auseinandersetzen, und möglicherweise - wenn SMB/1 eingesetzt wird - hilft auch, an OpLocking-Schrauben zu drehen (ich halte das allerdings nach wie vor für einen Mythos, siehe oben). Das widerspricht aber nicht meiner Aussage: Im reinen TS-Betrieb (x Workstations greifen auf einen TS per remote zu, der gleichzeitig Fileserver ist) ist OpLocking völlig irrelevant. Es ist ein Bestandteil des SMB-Protokolls, und das spielt in dieser Situation bezogen auf Datendateien keine Rolle.