Tablock?

[Spezlerin]

Hallo zusammen,
gibt es hier bei den Select Abfragen auch so etwas wie "with (Tablock)". Was dann ja wohl durch die temp. Sperre zu einer Performanceverbesserung führen würde!?

[Fuerchau]

Wozu soll eine Sperre die Performance verbessern?
Ohne Sperren ist das System auf jeden Fall schneller da es sich nicht um Sperren kümmern muss.

Ansonsten einfach "lock table MyTable in exclusive mode".
Dann kann kein anderer zugreifen.
Die nächste Variante klappt nur mit Journalisierung und CommitControl:
select ...
with CS

[Spezlerin]

Hallo nochmal, also ein Select oder insert oder... mit Tablock verbessert in einer Microsoft DB die Performance ganz gewaltig.
Beispiel aus dem Netz:https://drillchina.wordpress.com/201...t-performance/
Benutze ich selbst auch in unseren Mic DB, bringt mich in einer Abfrage(mit mehreren Join's) z.B. von 23 sec auf 4 sec.

[Fuerchau]

Nun, wenn du den Artikel liest betrifft dies ausschließlich den Insert und nicht den Select.
Es wird nämlich die Zieltabelle gesperrt!
Dies liegt aber auch an der Art der Microsoftimplementierung und, was in dem Artikel nicht steht, an der Transaktionskontrolle.
Mache ich den "insert ... select" mit Autocommit, dann ist es tatsächlich so, dass je Insert wohl eine Transaktion gebildet wird und deshalb das Transaktionslog anwächst. Mache ich vorher einen "StartTransaction", dann den Insert und anschließend CommitTransaction gehts wieder schneller, da eine Transaktion automatisch alle Veränderungen (Insert/Update/Delete) sperrt, bis die Transaktion abgeschlossen ist. Das ist auch beim SQL-Server so.
Ich liebe so unsinnige Tipps, die an der Ursache vorbei eine [Umgehungslösungs-]Lösung präsentieren.

Bei solchen "Bulk"-Inserts ist es da eher effektiv ggf. vorhandenen Indizes zu löschen oder deaktivieren und hinterher zu reaktivieren oder neu zu erstellen. Denn häufiger ist ein Create Index messbar schneller als bei jedem Insert alle Indexbäume nachzupflegen.

Auch bei der AS/400 ist es genauso.
Unter Transaktionskontrolle bleiben alle Insert/Update/Delete bis zum Commit gesperrt.
Das Deaktivieren von Indizes mit anschließendem Neuaufbau kann weitere Vorteile bringen.

[Spezlerin]

Danke für die Erklärung.
War mir so überhaupt nicht klar. Ich sah da nur das Ergebnis.

[Fuerchau]

Ein wenig kann man auch hier nachlesen:
https://msdn.microsoft.com/de-de/library/ms187373.aspx

TABLOCK
Gibt an, dass die abgerufene Sperre auf Tabellenebene aktiviert wird. Der Typ der abgerufenen Sperre hängt von der ausgeführten Anweisung ab. Beispielsweise kann eine SELECT-Anweisung eine gemeinsame Sperre abrufen. Bei Angabe von TABLOCK wird die gemeinsame Sperre auf die gesamte Tabelle statt auf Zeilen- oder Seitenebene angewendet. Wird zusätzlich HOLDLOCK angegeben, wird die Tabellensperre bis zum Transaktionsende aufrechterhalten.
Wenn Sie Daten mit der INSERT INTO SELECT FROM -Anweisung in einen Heap importieren, können Sie optimierte Protokollierung und Sperre für die Anweisung aktivieren, indem Sie den TABLOCK-Hinweis für die Zieltabelle angeben. Außerdem muss das Wiederherstellungsmodell der Datenbank auf einfach oder massenprotokolliert festgelegt werden. Weitere Informationen finden Sie unter INSERT (Transact-SQL).
Wenn der TABLOCK-Hinweis mit dem OPENROWSET-Rowsetanbieter verwendet wird, um Daten in eine Tabelle zu importieren, ermöglicht er mehreren Clients das gleichzeitige Laden von Daten in die Zieltabelle mit optimierter Protokollierung und Sperrung. Weitere Informationen finden Sie unter Voraussetzungen für die minimale Protokollierung beim Massenimport.

Vor allem der letzte Link erklärt den Vorgang für Bulkinserts genauer.
D.h., dass man das nicht zur Regel machen darf denn sonst leidet die Gesamtperformance der Datenbank. Eigentlich sollte man eine Datenbank immer unter voller Transaktionskontrolle verwenden.