MS-Access: Problem mit Netzlaufwerk

Don Manuel · 19.08.2005, 11:25

Und gleich noch ein Access-Ärgernis:
Wie gibt's das,
das die gleiche DB lokal einen Spalten-Kopiervorgang
von einer Tabelle in eine andere mit 9000 Zeilen problemlos schafft,
während der gleiche Vorgang Access zum Absturz bringt
und sogar die Netzwerkverbindung zum Server temporär lahmlegt,
(selbiger reagiert temporär auch auf keine RDP-Anforderungen mehr),
wenn die DB auf Netzlaufwerk liegt?

bully · 20.08.2005, 17:44

Ich habe mit Access und Netzlaufwerken allergrößte Probleme und Abstürze auf einem Samba-Server gehabt, schuld waren die oplocks. Möglicherweise steckt sowas dahinter.

lg
bully

Don Manuel · 20.08.2005, 19:51

Zitat:

Original geschrieben von bully
... oplocks. Möglicherweise steckt sowas dahinter...

Interessant, was ist das

bully · 21.08.2005, 00:12

Das opportunistische Sperren, auch bezeichnet als „Oplocks“ (entspricht „Opportunistic locking“) wird vom Windows-Dateisystem über Registrierungseinträge aufgerufen (im Gegensatz zu einer API), um die Netzwerk-Performance zu erhöhen, wenn auf eine Datei auf einem Server zugegriffen wird. Die Performance wird durch lokales Puffern der Datei auf dem Client erhöht, was Folgendes erlaubt:

Read-ahead:
Der Client liest die lokale Kopie der Datei, dadurch wird die Netzwerk-Latenz eliminiert.

Write caching:
Der Client schreibt in die lokale Kopie der Datei, dadurch wird die Netzwerk-Latenz eliminiert.

Lock caching:
Der Client puffert die Sperren der Anwendung lokal, und wieder wird die Netzwerk-Latenz eliminiert.

Die Performance-Steigerung von Oplocks kommt von der Möglichkeit des exklusiven Zugriffs auf die Datei sogar wenn sie über DENY_NONE geöffnet ist , da Windows den Status der Datei auf konkurrierende Zugriffe von anderen Prozessen überwacht.

Ein wichtiges Detail ist, dass Oplocks vom Dateisystem aufgerufen werden, nicht von einer Anwendungs-API. Daher kann eine Applikation eine opportunistisch gesperrte Datei schließen, aber das Dateisystem gibt den Oplock nicht auf. Wenn der Bruch des Oplocks durchgeführt wird, schließt das Dateisystem einfach die Datei in Vorbereitung auf das folgende Öffnen der Datei durch den zweiten Prozess.

Opportunistisches Sperren ist eigentlich ein unpassender Name für dieses Feature. Der wirkliche Nutzen dieses Features ist das Puffern von Daten („Cachen“) auf Client-Seite, und die Oplocks sind nur ein Mitteilungsmechanismus für das Zurückschreiben von Daten auf die Platte des Netzwerk-Servers. Die Einschränkung der Oplocks ist die Zuverlässigkeit des Mechanismus, einen Oplock-Bruch (Mitteilung) zwischen dem Server und dem puffernden Client auszuführen. Wenn dieser Austausch fehlerhaft abläuft (üblicherweise wegen eines Timeouts aus irgendwelchen Gründen), dann geht der Nutzen des client-seitigen Pufferns verloren.

Opportunistisches Sperren wird von Samba standardmäßig für alle Freigaben auf „on“ gesetzt, also sollten Sie in jedem Fall vorsichtig vorgehen, um zu bestimmen , ob der potenzielle Nutzen die potenziellen Verzögerungen wert ist. Die folgenden Empfehlungen sollen Ihnen dabei helfen, eine Umgebung zu charakterisieren, in der opportunistische Sperren effektiv eingerichtet werden können.

Die Windows-Oplocks sind ein leichtgewichtiges performance-steigerndes Feature. Sie sind kein robustes und zuverlässiges Protokoll. Jede Implementierung von Oplocks sollte als Kompromiss zwischen Performance und Zuverlässigkeit geprüft werden. Die Zuverlässigkeit sinkt mit jeder oben genannten Regel, die nicht erzwungen wird. Stellen Sie sich einen Hochverfügbarkeits-Server auf einem Atoll im Südpazifik vor, der über ein WAN eine „mission-critical“ Multi-User-Firmen-Datenbank bereitstellt, und das auf einer Freigabe mit aktivierten Oplocks, während eines tropischen Sturms. Diese Konfiguration wird sehr wahrscheinlich Probleme mit Oplocks erfahren.

Quelle: http://gertranssmb3.berlios.de/output/locking.html

Wenn du einmal nach Access, Samba und oplocks googelst, findest du die absurdesten Fehler, die dadurch auftreten können.

lg
bully

Don Manuel · 21.08.2005, 10:04

Spannende Sache, noch nie davon gehört.
Danke für das Stichwort, werde mich einlesen.
Falls jemand allerdings schon weiß, wie ich das bei W2K-Server & Client deaktiviere,
wäre ich sehr dankbar

.

Don Manuel · 21.08.2005, 10:07

Hier bei Microsoft bin ich mal fündig geworden.
Ich werde dann im Laufe des Tages testen und berichten.

19.08.2005, 11:25	#1
Don Manuel Inventar Registriert seit: 08.02.2001 Beiträge: 9.977	MS-Access: Problem mit Netzlaufwerk Und gleich noch ein Access-Ärgernis: Wie gibt's das, das die gleiche DB lokal einen Spalten-Kopiervorgang von einer Tabelle in eine andere mit 9000 Zeilen problemlos schafft, während der gleiche Vorgang Access zum Absturz bringt und sogar die Netzwerkverbindung zum Server temporär lahmlegt, (selbiger reagiert temporär auch auf keine RDP-Anforderungen mehr), wenn die DB auf Netzlaufwerk liegt?

20.08.2005, 17:44	#2
bully Speedtouchfreak Registriert seit: 07.04.2004 Beiträge: 1.852 Mein Computer	Ich habe mit Access und Netzlaufwerken allergrößte Probleme und Abstürze auf einem Samba-Server gehabt, schuld waren die oplocks. Möglicherweise steckt sowas dahinter. lg bully ____________________________________ Freunde nehmen dich so wie du bist. Freunde verzeihen dir deine Schwächen. Freunde sind treu. Freunde freuen sich dich zu sehen. Mein Hund ist mein Freund. Meine Homepage

21.08.2005, 00:12	#4
bully Speedtouchfreak Registriert seit: 07.04.2004 Beiträge: 1.852 Mein Computer	Das opportunistische Sperren, auch bezeichnet als „Oplocks“ (entspricht „Opportunistic locking“) wird vom Windows-Dateisystem über Registrierungseinträge aufgerufen (im Gegensatz zu einer API), um die Netzwerk-Performance zu erhöhen, wenn auf eine Datei auf einem Server zugegriffen wird. Die Performance wird durch lokales Puffern der Datei auf dem Client erhöht, was Folgendes erlaubt: Read-ahead: Der Client liest die lokale Kopie der Datei, dadurch wird die Netzwerk-Latenz eliminiert. Write caching: Der Client schreibt in die lokale Kopie der Datei, dadurch wird die Netzwerk-Latenz eliminiert. Lock caching: Der Client puffert die Sperren der Anwendung lokal, und wieder wird die Netzwerk-Latenz eliminiert. Die Performance-Steigerung von Oplocks kommt von der Möglichkeit des exklusiven Zugriffs auf die Datei sogar wenn sie über DENY_NONE geöffnet ist , da Windows den Status der Datei auf konkurrierende Zugriffe von anderen Prozessen überwacht. Ein wichtiges Detail ist, dass Oplocks vom Dateisystem aufgerufen werden, nicht von einer Anwendungs-API. Daher kann eine Applikation eine opportunistisch gesperrte Datei schließen, aber das Dateisystem gibt den Oplock nicht auf. Wenn der Bruch des Oplocks durchgeführt wird, schließt das Dateisystem einfach die Datei in Vorbereitung auf das folgende Öffnen der Datei durch den zweiten Prozess. Opportunistisches Sperren ist eigentlich ein unpassender Name für dieses Feature. Der wirkliche Nutzen dieses Features ist das Puffern von Daten („Cachen“) auf Client-Seite, und die Oplocks sind nur ein Mitteilungsmechanismus für das Zurückschreiben von Daten auf die Platte des Netzwerk-Servers. Die Einschränkung der Oplocks ist die Zuverlässigkeit des Mechanismus, einen Oplock-Bruch (Mitteilung) zwischen dem Server und dem puffernden Client auszuführen. Wenn dieser Austausch fehlerhaft abläuft (üblicherweise wegen eines Timeouts aus irgendwelchen Gründen), dann geht der Nutzen des client-seitigen Pufferns verloren. Opportunistisches Sperren wird von Samba standardmäßig für alle Freigaben auf „on“ gesetzt, also sollten Sie in jedem Fall vorsichtig vorgehen, um zu bestimmen , ob der potenzielle Nutzen die potenziellen Verzögerungen wert ist. Die folgenden Empfehlungen sollen Ihnen dabei helfen, eine Umgebung zu charakterisieren, in der opportunistische Sperren effektiv eingerichtet werden können. Die Windows-Oplocks sind ein leichtgewichtiges performance-steigerndes Feature. Sie sind kein robustes und zuverlässiges Protokoll. Jede Implementierung von Oplocks sollte als Kompromiss zwischen Performance und Zuverlässigkeit geprüft werden. Die Zuverlässigkeit sinkt mit jeder oben genannten Regel, die nicht erzwungen wird. Stellen Sie sich einen Hochverfügbarkeits-Server auf einem Atoll im Südpazifik vor, der über ein WAN eine „mission-critical“ Multi-User-Firmen-Datenbank bereitstellt, und das auf einer Freigabe mit aktivierten Oplocks, während eines tropischen Sturms. Diese Konfiguration wird sehr wahrscheinlich Probleme mit Oplocks erfahren. Quelle: http://gertranssmb3.berlios.de/output/locking.html Wenn du einmal nach Access, Samba und oplocks googelst, findest du die absurdesten Fehler, die dadurch auftreten können. lg bully ____________________________________ Freunde nehmen dich so wie du bist. Freunde verzeihen dir deine Schwächen. Freunde sind treu. Freunde freuen sich dich zu sehen. Mein Hund ist mein Freund. Meine Homepage

21.08.2005, 10:04	#5
Don Manuel Inventar Registriert seit: 08.02.2001 Beiträge: 9.977	Spannende Sache, noch nie davon gehört. Danke für das Stichwort, werde mich einlesen. Falls jemand allerdings schon weiß, wie ich das bei W2K-Server & Client deaktiviere, wäre ich sehr dankbar .

21.08.2005, 10:07	#6
Don Manuel Inventar Registriert seit: 08.02.2001 Beiträge: 9.977	Hier bei Microsoft bin ich mal fündig geworden. Ich werde dann im Laufe des Tages testen und berichten.

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)