SQL SQL Server - UPDATE Batching erforderlich?

Zonk91

Cadet 4th Year
Registriert
März 2013
Beiträge
68
Hallo zusammen,

brauche mal die Meinung von Datenbank Experten, speziell Richtung MS SQL Server.

Bei einer Tabelle die rund um die Uhr stark abgefragt wird (SELECTs), etwa 12k Rows hat, möchte ich bei allen Rows eine Column (Datentyp Date) via UPDATE Statment auf einen fixen Wert Wert setzen (bspw. ‚2050-06-01‘).

Würdet ihr an der Stelle mit Batching arbeiten oder sagt ihr egal, das Statement geht in wenigen Sekunden durch? Ich vermute, dass an der Stelle die ganze Tabelle gesperrt wird und habe deswegen ein wenig Bedenken, hier unnötigen Impact zu produzieren. Wäre klasse, wenn hier jemand mit Erfahrung seine Einschätzung abgeben könnte.
 
Nee wäre tatsächlich eine einzelne Update Anfrage in der Art bspw.: UPDATE UserMapping SET ExpiryDate = ‚2050-06-01‘.
 
Die Begründung, warum diese Query schnell durchlaufen wird wirft die Folgefrage auf was du damit bezweckst alle rows mit der selben Information zu updaten. Welchen Mehrwert hat diese Info? Wenn du alle rows updatest kannst du gleich einen weiteren Table erstellen in dem du in einer einzelnen row dein expiry date führst.
Der impact des updates hängt auch davon ab pb und wieviele Indizes von dieser column abhängen und ob Trigger definiert sind.
 
Mir geht es im Grunde nur darum wie lange hier an der Stelle andere Konsumenten der Datenbank sei es schreibend oder noch wichtiger, lesend warten müssen. Ich hatte immer angenommen, vielleicht naiv, wenn ein UPDATE durchgeführt wird, mit oder ohne einschränkendem WHERE, dass hier ein Lock auf die Ziel-Menge platziert wird. Das ist das was mich primär interessiert. Vermutlich, wie schon @Nixdorf sagte, unnötig, da in wenigen ms erledigt und das Batching T-SQL Skript ist schnell geschrieben. Interessieren würde es mich allerdings trotzdem.

Nebenbei bemerkt: Der Tabellenname und das ExpiryDate sind frei erfunden und sollte nur als Bespiel dienen. Mir gehts hier null um den Use-Case.
 
Zuletzt bearbeitet:
Sind die Abfragen der Clients so wichtig, dass die immer Read Commit abgefragt werden müssen? Ansonsten frag halt per
SQL:
WITH (NOLOCK)
hint ab, dann spielen deine DML-Statements keine Rolle, deine Select-Statements sind dann aber halt ggf. nicht Read Commit, was nicht ganz einer OLTP-Anwendung entspricht aber da kommt es einfach komplett auf den Anwendungsfall drauf an. Bei User Credentials abfragen ist Read Commit schon wichtig, bei Foren-Beiträgen abfragen halt so überhaupt gar nicht.
 
  • Gefällt mir
Reaktionen: Glendon
Zurück
Oben