Tom: Okay, zu mit schreiben.

Beitrag lesen

Hello,

ob das Deine Frage beantwortet weiß ich nicht, aber vielleicht liegt das Problem darin:

Das DBMS liegt auf dem Fileserver und nutzt in gewissem Umfang dessen Dienste.
Um den konkurrierenden Betrieb zu ermöglichen, werden vom DBMS bei umfangreichen Anforderungen erst Markierungen gesetzt (Löschmarkierungen, Sperrmarkierungen, etc). Eine markierter Datensatz darf von keinem anderen Prozess mehr benutzt / verändert werden (je nach Markierung). Für diese Markierungen benötigt das DBMS Speicherplatz und ggf. das OS selber auch nochmal (--> *.ldb-Datei).

Es sind aber nur eine bestimmte Anzahl von Markierungen möglich, bzw der Arbeitsspeicher muss dafür gesondert bereitgestellt werden. Wenn Du nun dieses Limit überschreitest, gibt es entweder gleich einen Fehler, oder das System fängt an zu swappen, also Daten aus dem Hauptspeicher in eine Auslagerungsdatei zu verschieben. Das erhöht den Zeitbedarf um ca. Faktor 1000 (beispielhaft).

Wenn also in einer Datenbank umfangreiche dedizierte Löschungen (also 'einzelne' Sätze, nicht die ganze Tabelle) vorgenommern werden müssen, wirst Du ggf. nicht um eine Strategie hierfür herumkommen.

Gut zu beobachten ist dieses Verhalten mit einer (fileserverorientierten) Access-Datenbank. Wenn Du dort mehr als 10.000 Sätze in eine Veränderung einbeziehen willst, musst Du die Fileserver-Parameter entsprehend hoch eingestellt haben. Bei NOVELL heißt die Systemvariable dafü z.B. MAX_RECORD_LOCKS und konnte je nach System ohnehin 'nur' maximal 50.000 Sperren gleichzeitig verwalten.

Andere Server-Betriebssysteme haben ähnliche Beschränkungen.

Abhilfe:
a) Sperr die tabellen exclusiv. Dann sind keine Satzsperren nötig
b) markiere "soft", also im Satz und nimm Rücksicht darauf in Deiner Applikation
c) führe eine separate Tabelle mit den IDs der zur Löschung vorgesehenen Sätze

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau