Tabellen Sperren durch SQL

Guten Tag,

habe ein Problem mit Tabellensperren. Ich erzeuge mit hilfe eines Reportes Datensätze die durch eine Codeunit ergänzt werden (alles eigenentwicklung). Das ganze ist releativ umfangreich wobei eigentlich "nur" 2 Tabellen angeprochen werden. Das ganze dauert ca. 5 - 10 Minuten. Obwohl ich kein locktable benutze, werden dennoch die beiden Tabellen in diesem Zeitraum gesperrt, so dass niemand in dieser Zait arbeiten kann. Die beiden Tabellen werden aber permant von ca. 30 Usern bearbeitet. Wie kann ich dem SQL expliziet erklären nur den Datensatz und nicht die Tabelle zu sperren??

mfg

Sebastian

Ich denke das kannst du nicht machen - der SQL Server sperrt durch seine Logiken automatisch die ganze Tabebelle sobald sehr viele Sätze geändert werden. Ist es eventuell möglich diesen Job am Abend zu starten?

Mir ist auch aufgefallen das gewisse Programme in CAL 2-3 min. dauern und in SQL sind diese in 20 sec. fertig. Falls diese Updates öfters zu Bürozeiten laufen müssen wäre ein SQL-Script eine Altenative.

Evenutell noch im vorhandenen Navision Programm prüfen ob alle Schlüssel richtig gesetzt sind.

mfG
Jürgen

Hi!

Nun, leider ist die Problembeschreibung ein wenig "allgemein" gehalten, deshalb ist es schwierig, konkrete Optimierungsvorschläge zu geben.

Einen ganzen "Sack voll" allgemeiner Hinweise erhältst Du, wenn Du das Forum nach "SQL Performance" durchsuchst.

Zum Sperrverhalten mit SQL Server: SQL Server fängt immer mit Zeilensperren an, ist aber in der Lage dies zu "eskalieren". Eine vollständige Tabellensperre (TAB X) ist dabei gar nicht so leicht zu ereugen ...
Das Feature "Always Rowlock" verhindert zwar die Lock-Eskalation und kann daher Blockaden entgegenwirken, was allerdings deutlich zu Lasten der Gesamtperformance geht - und somit entsprechend Hardware "unten d'runter" benötigt ... NICHT ZU EMPFEHLEN!

Um ein paar Dingen mal auf den Grund zu gehen:

Wie sieht bei den Problemtabellen der Primärschlüssel aus? Wie der Clustered Index?
Wie wird in die Tabelle geschrieben? (Code-Beispiel)
Hat die Tabelle SIFT?

Gruß,
Jörg

SIFT, ja in beiden Tabellen.
Primärschlüssel Tabelle 1 : Datum, LineNo.
Primärschlüssel Tabelle 2 : Art,LineNo,Sendungsnummer.

Power hat der SQL schon, 4 CPU´s (XEON) SCSI 10000 Raid 10 und 9GB DDR2 Ram. Anzahl aller User ca. 40.

Clusterd Index ?? Sag mir nichts, wo kann ich da mal nachgucken?!

Wie wird in die Tabellen geschrieben? Weiß nicht genau wie du das meinest. Teilweise neue Datensäteze mit
Init
Schlüssel..
Insert
datensätze
Modify.
Der standart weg denke ich.
Code, naja , sind mehre hundert Zeilen quellcode.

OK, versuchen wir's mal ...

"SIFT" nur dann, wenn die Tabellen mehr als 10.000 Datensätze beinhalten und nicht als "Durchlauferhitzer" benutzt werden, also Sätze angelegt werden und bald wieder gelöscht werden, etc..
Ist SIFT notwendig, dann insofern optimieren, daß nur benötigte Buckets vorgehalten werden ...
Das Thema wurde hier vor kurzem behandelt:
http://www.msdynamics.de/viewtopic.php?t=4434&highlight=

Was das "Schreiben" in die Tabellen angeht, so ist wichtig zu wissen, ob immer nur am Ende angefügt wird, oder ob auch Datensätze zwischendrin eingefügt werden.
In diesem Zusammenhang wird der "Clustered Index" wichtig. Im Standard wird der NAV Primärschlüssel auch zum CI; im Management Studion/Enterprise Manager findest Du ihn als Index "...$0" in den Tabellen.
Man kann ab NAV 4.00 den CI ändern, durch setzten der "Key"-Eigenschaften "Clustered" (meist zusammen mit "SQL Index").
Der CI bestimmt die physikalische Anordnung der Datensätze.
Blockade-Probleme entstehen aus einem Konflikt zwischen "Schreiben" und "Lesen" ... und dieser Konflikt ist nur im Code zu finden ...

Hallo,

Datensätze sind mehr als 500000 und die Datensätze werden nicht wieder gelöscht, SIFT also notwendig.

Ich füge neue Datensätze in der Regel mitten in die Tabelle, bzw modifizieren bereits vorhandene Datensätze.

Konflikt zwischen Lesen und schreiben kann ich mir auch gut vorstellen. Es wird ein Report durchlaufen, innerhalb dieses Reports wird eine Codeunit aufgerufen, welche Datensätze ändert, aber keine neuen erzeugt. Auf diese geänderten Datensätze greift an spätere Stelle der Report wieder darauf zu. Es handelt sich im ganzen um mehere hundert zeilen Code. Denke das ist zuviel zum posten.

Den Link werde ich mir gleich mal zu gemüte ziehen