Timeout bei umfangreicher SQL-Transaktion

verwendetes Datenbanksystem: <SQL Server 2008>

Hi, ich möchte gern eine große Menge von Datensätzen (ca. 600.000) von einer Tabelle in eine andere verschieben, also in die eine Tabelle einfügen und aus der ursprünglichen löschen. Dafür verwende ich eine Transaktion, da während die Daten kopiert werden schon neue Daten in der Ursprungstabelle auflaufen können und ich somit u.U. mehr Daten lösche als ich kopiert habe. Problem des ganzen, meine Transaction wird gekillt, weil der SqlClient in ein Timeout läuft und der Meinung ist, die Verbindung ist abgebrochen. Der ConnectionTimeout der Verbindung hat keinen Einfluss darauf also wo kann ich diesen Timeout erhöhen?

Eine so große Transaktion ist ungünstig für die Datenbank (so ist zumindestens mein Wissensstand).

Besser ist es 1 - 100 Datensätze zu verschieben und in der Quelldatenbank zu löschen, und diesen Vorgang in eine Transaktion zu packen.

Grüße Bernd

@BerndFM:
Da liegst Du falsch Bernd.
Eine Transaction ist dafür da eine zusammenhängende Aktion rückgängig machen zu können, bzw eine Aktion gegen Manipulation zu schützen.
Im Auditlog ( *.ldf ) stehen sowieso alle änderungen, es ist der db also egal.

@buyden:
Neben dem ConnectionTimeout gibt es auch ein CommandTimeout

Je nachdem mit welcher Datenbank und mit welchem Isolationlevel ich arbeite haben die anderen User längere Wartezeiten. Wenn Dirty Reads ausgeschlossen sind müssen die anderen Benutzer warten, bis die Transaktion abgeschlossen sind, bevor sie Daten lesen können. Aus diesem Grunde sind meine Transaktionen immer so kurz wie möglich, maximal so 2 Sekunden.

Grüße Bernd

Wie verscheibst du denn die Daten? Hier würde sich SqlBulkCopy anbieten, falls du das nicht ohnehin schon verwendest.
Beachte auch den Hinweis, denn wenn Quelle und Ziel auf der selben Instanz laufen dann gehts so am schnellsten.

If the source and destination tables are in the same SQL Server instance, it is easier and faster to use a Transact-SQL INSERT … SELECT statement to copy the data.

CommandTimeout ist die Lösung.

@chavez
Die Tabellen befinden sich in der selben DB, ich verschiebe sie nur zum verarbeiten in eine work-tabelle und danach in eine history, um den Datenbestand beim Verarbeiten so klein wie möglich zu halten da sich in der Work-Tabelle nur die Datensätze zum aktuellen Vorgang befinden.

huhu,

Je nachdem mit welcher Datenbank und mit welchem Isolationlevel ich arbeite haben die anderen User längere Wartezeiten. Wenn Dirty Reads ausgeschlossen sind müssen die anderen Benutzer warten, bis die Transaktion abgeschlossen sind, bevor sie Daten lesen können. Aus diesem Grunde sind meine Transaktionen immer so kurz wie möglich, maximal so 2 Sekunden.

Handhabe ich genauso. Wenn es wirklich viele Daten sind, dann einzelne Transaktionen a 10.000 Stück (je nach Anwendung variierend) mit einem View zum löschen (der ist tatsächlich performanter).
Zum Teil auch gerne einfach in einer StoredProc mit nem Cursor und Schleife in einzelne Transaktionen zerhackt. Dann müssen die anderen Transaktionen nicht unnötig warten.

Die Tabellen befinden sich in der selben DB, ich verschiebe sie nur zum verarbeiten in eine work-tabelle und danach in eine history, um den Datenbestand beim Verarbeiten so klein wie möglich zu halten da sich in der Work-Tabelle nur die Datensätze zum aktuellen Vorgang befinden.

In diesen Fällen bevorzuge ich Temporäre Tabellen oder - wenn es die performance zulässt - Tabellenvariablen. Das erspart die Aufräumarbeit und man kann das ganze später auch von unterschiedlichen Stellen (Threads) anwerfen, ohne dass die "Worktabelle" von allen belegt wird.

😃

Xynratron