Oplock
Dieter Tautz
Unter Vista hatte ich ein Problem mit zerstörten Indexdateien. Auf Grund
eines Hinweises in dieser Group habe ich in der Registry "Oplock"
abgeschaltet. Danach hatte ich keine Probleme mehr.
Jetzt habe ich das gleiche Problem unter Windows 7. Die entsprechenden
Schlüssel in dere Registry sind aber gesetzt.
Hat jemand einen Hinweis ?
Beste Grüße
Dieter
Olaf Doschke
smb2-Netzwerk-Protokoll aktiv, was die Oplockabschaltung auch bei
entsprechenden Resgistry-Eintr�gen nicht mehr unterst�tzt.
Abhilfe schafft hier, das smb2 Protokoll abzuschalten, was man mit folgendem
Registry-Eintrag erreicht:
Bis vor kurzem war die Abschaltung von SMB2 sowieso wegen einer
Sicherheitsl�cke im Protokoll als schnelle Ma�nahme empfohlen, siehe z.B.
http://www.tecchannel.de/sicherheit/news/2022273/microsoft_1_click_workaround_fuer_smb2_luecke/
Dort gibt es auch einen Link zu einem MSI von MS zur Abschaltung von SMB2
(und einen zur wieder Einschaltung).
Tsch��, Olaf.
Dieter Tautz
Danke für den Tip. Ich habe das Protokoll jetzt abgeschalten und werde den
Fall beobachten.
Dieter
Dieter Tautz
Im Moment habe ich keine Probleme mehr. Dein Hinweis hat also Erfolg
gebracht. Was macht man auf Serverseite (Windows 2008) ?
Beste Grüße
Dieter
Olaf Doschke
> gebracht. Was macht man auf Serverseite (Windows 2008) ?
Auch da oder unter R2 gilt, erst SMB2 ausschalten. Das sollte genauso gehen
wie unter Vista oder Win7.
Du kennst ja sicherlich die entsprechenden Registry Keys die Serverseitig
danach dann Oplocks selbst ausschalten, oder?
Es reicht aber, Oplocks nur clientseitig auszuschalten. Wenn der Server
Oplocks anbietet, der Client aber keine anfordert, werden auch keine
gemacht. Wenn Oplocks am Server ausgeschaltet ist, kriegt kein Client
Oplocks, auch wenn er sie fordert. Es nur Clientseitig zu machen hat noch
den Vorteil, da� einzelne Clients ohne problematische FoxPro- oder auch
Access-Applikationen dann von Oplocks noch profitieren k�nnen. Insofern
halte ich es f�r weniger wichtig, am Server Oplocks zu deaktivieren.
Tsch��, Olaf.
Dieter Tautz
> Du kennst ja sicherlich die entsprechenden Registry Keys die Serverseitig
> danach dann Oplocks selbst ausschalten, oder?
Nein, kenne ich nicht. Ich habe nur die Hotfixes (Exe) von Microsoft
Dieter
Olaf Doschke
"Auf Grund eines Hinweises in dieser Group habe ich in der Registry "Oplock"
abgeschaltet."
Also kennst Du dann doch zumindest die Registry Keys f�r Clients.
Wo ich die Regsitryeinstellungen mal gepostet hatte, habe ich aber auch die
f�r Server mitgepostet.
Mu� ich jetzt nochmal neu raussuchen...
hier: http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html
Zitat:
Disabling Oplocks on Windows Client PCs
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters
OplocksDisabled = 1
Disabling Oplocks on Windows Servers
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
EnableOplocks = 0
und wegen SMB2 nun noch:
Disabling Oplocks on SMB2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
SMB2 = 0
Mehr macht der Hotfix auch gar nicht.
Tsch��, Olaf.
Dieter Tautz
Dieter Tautz
> Also kennst Du dann doch zumindest die Registry Keys für Clients.
Ich kannte bisher diese Einstellungen, aber das Dokument war von 2005:
Workstation:
hkey_local_machine\system\currentcontrolset\services\lanmanworkstation\parameters
"EnableOplockForceClose"=dword:00000001
"EnableOplocks"=dword:00000000
"UseOpportunisticLocking"=dword:00000000
Server:
hkey_local_machine\system\currentcontrolset\services\lanmanserver\parameters
"EnableOplockForceClose"=dword:00000001
"EnableOplocks"=dword:00000000
Dieter
Dieter Tautz
Die Indexdatei war gerade wieder defekt. Was nun ? Gibt es da noch ein
anderes Problem mit Windows 7 ?
Dieter
Jürgen Wondzinski
a) Woran merkst du, dass ausgerechnet die Indexdatei kaputt ist? Keine
Schäden an der Memo oder DBF?
b) hast du auch wirklich die VFP9 SP2 Runtime mit VersionsNr 9.0.7423 auf
den Kundenrechnern?
c) Hast du SET TABLEVALIDATE TO 11 im Startprogramm?
d) Ein Virenscanner am Server oder Client im Einsatz, der unsinnigerweise
die Datenverzeichnisse mitscannt ?
--
wOOdy
Visual FoxPro Technologieberater
Microsoft "Most Valuable Professional" 1996 bis 2009
"*´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´. (¸.·` *
..·`.Visual FoxPro: It's magic !
(¸.·``··*
Olaf Doschke
Was Indizes angeht gab es aber auch noch einen Bug, zu dessen milderung
emfpohlen wird
h�ufiger mal SYS(1104) und/oder FLUSH FORCE aufzurufen, zumindest bei
Abschlu�,
also hinter dem letzten Tableupdate() einer Transaktion beispielsweise.
Tsch��, Olaf.
Dieter Tautz
> a) Woran merkst du, dass ausgerechnet die Indexdatei kaputt ist? Keine
> Schäden an der Memo oder DBF?
Nach einem "reindex" ist die Welt wieder in Ordnung
> b) hast du auch wirklich die VFP9 SP2 Runtime mit VersionsNr 9.0.7423 auf
> den Kundenrechnern?
Das Problem habe derzeit nur ich, da ich der Einzige mit Windows 7 bin und
ich arbeite mit der IDE.
> c) Hast du SET TABLEVALIDATE TO 11 im Startprogramm?
Nein
> d) Ein Virenscanner am Server oder Client im Einsatz, der unsinnigerweise
> die Datenverzeichnisse mitscannt ?
Nein
Dieter
Jürgen Wondzinski
deiner Argumentationskette kann ich nicht ganz folgen:
>> Die Indexdatei war gerade wieder defekt
>> Das Problem habe derzeit nur ich,
Wenn ne Indexdatei kaputt ist, haben das Problem eigentlich alle. Wieso also
nur du?
Und wie äussert sich das Problem eigentlich?
Hast du noch VFP7er Apps parallel im Einsatz ?
>> ich arbeite mit der IDE.
Und: Hat die wenigstens die VersionsNr 7423 ? Den aktuellsten HotFix (der
auch alle früheren Fixe beinhaltet!) kannst du hier runterladen:
http://code.msdn.microsoft.com/KB968409/Release/ProjectReleases.aspx?ReleaseId=2445
Die Runtime-Module auf den Clientrechnern werden, wie schon des öfteren
gesagt, am einfachsten mit dem Runtime-Intaller vom
ftp.prolib.de/public/vfp9sp2rt.exe beglückt.
[SET Selbstgespräch ON]
Hmmm... Eigentlich könnte man da auch gleich noch den OpLock-Patcher mit
reinnehmen. Jepp. Dat mach ich bei näxter Gelegenheit mit rein.
[SET Selbstgespräch OFF]
Ansonsten noch mal zur eventuellen (!) Ursache der Oplocks:
a) OpLocks ausschalten kann man nur beim SMB1 Protokoll.
b) Beim SMB2 Protokoll gibt es diese Option überhaupt nicht mehr.
c) Wenn man SMB2 abschaltet, ist wieder SMB1 aktiv
d) Daraus folgt: man muss sowohl SMB2 ausschalten, als auch die SMB1-OpLocks
abschalten.
e) das macht man am sinnvollsten einmalig am Server, sofern man darüber die
Kontrolle hat. Ansonsten muss man jeden (!) einzelnen Client umstellen. Und
auch nur ein vergessener Client sorgt schon dafür, dass der Spuk wieder
anfängt. Daher: Server patchen!
Jürgen Wondzinski
>>>> c) Hast du SET TABLEVALIDATE TO 11 im Startprogramm?
>> Nein
Stellt sich die Frage: Warum nicht? Wenn ich kaputte Dateien habe, ist doch
das Erste, dass ich entsprechende Überwachungen einschalte (obwohl das
eigentlich dauerhaft an sein sollte). Wie willst du sonst mitbekommen, WANN
was kaputt geht?
Da bei Record-Updates zuerst in der DBF, dann in der FPT, dann in der CDX
und danach wieder im Header der DBF rumgeschrieben wird, halte ich es für
seltsam, dass da nur ne CDX nicht korrekt geschrieben würde.
Falls die Antwort ein genuscheltes "Hab ich bislang ned gekannt" ;) ist:
Dieser Befehl is nu schon seit VFP8 im Produkt, d.h. seit Januar 2003 konnte
man den in der Hilfe und im "What's New" nachlesen und entsprechend
implementieren. Watt sacht da der Grünfrosch von der Verkehrsüberwachung:
"Unwissenheit schützt vor Strafe nicht" ;)
Matthias Kahlert
> [SET Selbstgespräch ON]
> Hmmm... Eigentlich könnte man da auch gleich noch den OpLock-Patcher mit
> reinnehmen. Jepp. Dat mach ich bei näxter Gelegenheit mit rein.
> [SET Selbstgespräch OFF]
Sowas dann bitte nur optional... nicht jeder nutzt DBFs übers Netzwerk,
und ich will eigentlich nicht dass mir irgendein Setup-Programm ohne
Rückfrage in den SMB-Einstellungen rumpfuscht... vor allem dann nicht,
wenn es nicht mal notwendig wäre...
Microsoft hat sich schon was dabei gedacht, dass die Einstellungen so
sind wie sie sind. Bei mir machen Sie jedenfalls keine Probleme. Und ich
will gar nicht wissen, was es für Auswirkungen hat, wenn das einfach
ohne Grund verstellt wird.
Wenn die Einstellung wirklich so dermassen problematisch wäre, und
keinerlei Vorteile bieten würde, dann würde Microsoft das auch per
Default abstellen.
--
Matthias
Jürgen Wondzinski
>> Sowas dann bitte nur optional...
Latürnich. Ein Hakerl zum Anklicken is doch eh selbstverfreilich ;)
> Microsoft hat sich schon was dabei gedacht, dass die Einstellungen so sind
> wie sie sind.
Klar: Sie sind auf SQL-Server optimiert, damit die CashCow keine Probleme
hat. Dafür haben dann alle Filebasierten Datenbanken ihre Probleme, egal ob
Access, FoxPro, Paradox etc...
>> Bei mir machen Sie jedenfalls keine Probleme
Vielleicht bist du nur deshalb bislang davongekommen, weil bei dir nie _ein_
einziger User die Dateien offen hat? Denn nur bei einem einzigen User hat ja
die OpLock-"Optimierung" gegriffen, sobald ein zweiter sich draufschaltet,
isses eh vorbei.
Matthias Kahlert
>>> Bei mir machen Sie jedenfalls keine Probleme
>
> Vielleicht bist du nur deshalb bislang davongekommen, weil bei dir nie
> _ein_ einziger User die Dateien offen hat? Denn nur bei einem einzigen
> User hat ja die OpLock-"Optimierung" gegriffen, sobald ein zweiter sich
> draufschaltet, isses eh vorbei.
Nö, ich bin deshalb davongekommen, weil ich DBFs nicht auf einer
Netzwerkfreigabe einsetze :-D
Bei lokalen Anwendungen liegen die DBFs lokal, und bei
Client/Server-Anwendungen liegen die Daten im SQL Server... ;-)
--
Matthias
Dieter Tautz
"Jürgen Wondzinski" wrote:
> Das Problem habe derzeit nur ich,
Ich habe mich nicht korrekt ausgedrückt. Ich glaube der einzige Verursacher
zu sein.
Das Problem tritt oft dann auf, wenn ich Datensätze hinzugefügt habe. Die
Auswirkungen haben dann natürlich alle.
> Und wie äussert sich das Problem eigentlich?
Datensätze werden nicht angezeigt, die dann aber nach einem reindex wieder
vorhanden sind (Lücken in der Reihenfolge)
> Hast du noch VFP7er Apps parallel im Einsatz ?
Nein
> Und: Hat die wenigstens die VersionsNr 7423 ?
Jetzt ja.
Danke. Dieter
Olaf Doschke
>
> Datens�tze werden nicht angezeigt, die dann aber nach einem reindex wieder
> vorhanden sind (L�cken in der Reihenfolge)
Das deutet doch darauf hin, da� es Indizes in IDX-Dateien gibt oder in zweit
CDX.
Das einf�gen neuer Daten in eine DBF egal �ber welchen Weg aktualisiert nur
die direkt zum DBF geh�rende CDX-Datei.
Unaktualisiert bleiben wie gesagt IDX, zweit-CDX und insbeonsdere auch
solche, die lokal gebildet werden. Auch wenn Du - was geht - �ber Felder
einer anderen Tabelle indizierst, passiert das nur dann wieder, wenn diese
Tabellen offen und per RELATION korrekt verbunden sind.
Du k�nntest bei solchen Datenanf�geupdates, um sicherzugehen da� da nichts
schmutziges passieren kann und die ja doch getrennte CDX sich aus
OpLock-Gr�nden oder sonstwelchen Gr�nden nicht mit aktualisiert die Tabelle
exklusiv �ffnen und dann APPENDen oder was auch immer Du machst.
Tsch��, Olaf.
Bernhard Sander
>> Datens�tze werden nicht angezeigt, die dann aber nach einem reindex wieder
>> vorhanden sind (L�cken in der Reihenfolge)
>
> Das deutet doch darauf hin, da� es Indizes in IDX-Dateien gibt oder in zweit
> CDX.
>
> Das einf�gen neuer Daten in eine DBF egal �ber welchen Weg aktualisiert nur
> die direkt zum DBF geh�rende CDX-Datei.
>
> Unaktualisiert bleiben wie gesagt IDX, zweit-CDX und insbeonsdere auch
> solche, die lokal gebildet werden. Auch wenn Du - was geht - �ber Felder
> einer anderen Tabelle indizierst, passiert das nur dann wieder, wenn diese
> Tabellen offen und per RELATION korrekt verbunden sind.
Da kommen doch ein paar Fragezeichen auf.
Aktualisiert werden immer alle offene Indizes, egal ob in der strukturellen
CDX-, in sekund�ren CDX-, in IDX-Dateien, egal ob die lokal liegen oder im Netz.
Das gilt insbesondere auch f�r ein Reindex. Wenn bei dem Reindex die
zus�tzlichen Dateien nicht offen sind, werden die auch nicht ber�cksichtigt.
Gru�
Bernhard Sander
Olaf Doschke
> Aktualisiert werden immer alle offene Indizes, egal ob in der
> strukturellen CDX-, in sekund�ren CDX-, in IDX-Dateien, egal ob die lokal
> liegen oder im Netz.
> Das gilt insbesondere auch f�r ein Reindex. Wenn bei dem Reindex die
> zus�tzlichen Dateien nicht offen sind, werden die auch nicht
> ber�cksichtigt.
Jein, Du kannst so etwas schmutziges machen:
Create Cursor curOrte (iID I Autoinc, cOrt C(40))
Index On iID Tag xID
Create Cursor curPLZ (iID I Autoinc, iPLZ I, iOrt I)
Set Relation To iOrt Into curOrte
Index On curOrte.cOrt TAG xOrt
Insert Into curOrte (cOrt) Values ("Hamburg")
Insert Into curOrte (cOrt) Values ("Berlin")
Insert Into curPLZ (iPLZ, iOrt) Values (22085,1)
Insert Into curPLZ (iPLZ, iOrt) Values (12345,2)
BROWSE FIELDS curPLZ.iPLZ, curOrte.cOrt
Damit hat dann curPLZ einen Index xOrt mit Daten aus curOrte, die in
Relation stehen zu Daten aus curOrte aber ein Reindex so eines Index klappt
auch nur korrekt, wenn die Relation wieder so steht, wie bei der
urspr�nglichen Erstellung. Geschweige denn, da� man die beiden Tabellen auch
immer so in dem Zusammenhalt nutzen mu�, damit der Index nicht
auseinanderl�uft. Ungew�hnlich, unwahrscheinlich, aber ich habe es schon
andere machen sehen.
Im Browse wird nun kein zusammenselektierter Cursor angezeigt, sondern die
xBase-Relation live angezeigt. Nicht in Sortierung nach PLZ, sondern nach
Ortsname, eben xOrt, obwohl der Ortsname ja gar kein Feld von curPLZ ist.
Tsch��, Olaf.