6
MS SQL Server 2005 Timeout Expired
Hallo,
Ich importiere mit EMS Data Import ca. 200.000 Zeilen und 20 Spalten auf meinen SQL Server
davor möchte ich aber noch den Dateninhalt der dbo.Tabelle löschen und den Datenbestand in eine andere Tabelle kopieren
____________________________________________________________________________________________________________
TRUNCATE TABLE [dbo].[Tabelle1]
GO
INSERT INTO [dbo].[Tabelle1] (xxxxxxxxxxxxx)
SELECT xxxxxxxxx FROM [dbo].[Tabelle3]
GO
TRUNCATE TABLE dbo.Tabelle2
GO
TRUNCATE TABLE dbo.Tabelle3
GO
____________________________________________________________________________________________________________
Das funktioniert auch zu 90% ausgezeichnet nur ab und an bekomme ich beim ausführen der Query ein "Timeout Expired"
Ich habe mittlerweile den Query Timeout auf 0 gestellt und den Connection Timeout auf 600sec
trotzdem bekomme ich nach ca. 15sek diese Meldung.
Langsam gehen mir die Ideen aus!
Ich wäre echt Dankbar für jeden Vorschlag
LG
Ich importiere mit EMS Data Import ca. 200.000 Zeilen und 20 Spalten auf meinen SQL Server
davor möchte ich aber noch den Dateninhalt der dbo.Tabelle löschen und den Datenbestand in eine andere Tabelle kopieren
____________________________________________________________________________________________________________
TRUNCATE TABLE [dbo].[Tabelle1]
GO
INSERT INTO [dbo].[Tabelle1] (xxxxxxxxxxxxx)
SELECT xxxxxxxxx FROM [dbo].[Tabelle3]
GO
TRUNCATE TABLE dbo.Tabelle2
GO
TRUNCATE TABLE dbo.Tabelle3
GO
____________________________________________________________________________________________________________
Das funktioniert auch zu 90% ausgezeichnet nur ab und an bekomme ich beim ausführen der Query ein "Timeout Expired"
Ich habe mittlerweile den Query Timeout auf 0 gestellt und den Connection Timeout auf 600sec
trotzdem bekomme ich nach ca. 15sek diese Meldung.
Langsam gehen mir die Ideen aus!
Ich wäre echt Dankbar für jeden Vorschlag
LG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 88071
Url: https://administrator.de/forum/ms-sql-server-2005-timeout-expired-88071.html
Ausgedruckt am: 23.12.2024 um 10:12 Uhr
6 Kommentare
Neuester Kommentar
Ich habe jetzt mal die Registry durchforstet und bin dabei auf diesen Eintrag gestoßen
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\90\Tools\Shell\DataProject
SQLQueryTimeout steht default auf 30 habe es auf 60000 erweitert und siehe da kein Timeout mehr.
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\90\Tools\Shell\DataProject
SQLQueryTimeout steht default auf 30 habe es auf 60000 erweitert und siehe da kein Timeout mehr.
Moin T-Virus,
ich war gestern schon am Überlegen, ob ich nachfrage...
Sitzt Du bei dieser Abfrage am Client oder bist Du direkt am Datenbank-Server angemeldet?
Grüße
Biber
ich war gestern schon am Überlegen, ob ich nachfrage...
Sitzt Du bei dieser Abfrage am Client oder bist Du direkt am Datenbank-Server angemeldet?
Grüße
Biber
Wenn es nur so eine einfache Frage ist ;)
Also ich starte meine Querys von einem Client...
EMS Data Import und
EMS SQL Manager 2008
Bei beiden habe ich die Query time auf 0 gesetzt.
Naja ich has jetzt 25x ausprobiert und beim 26x wieder Timeout
es ist zum ...
Also ich starte meine Querys von einem Client...
EMS Data Import und
EMS SQL Manager 2008
Bei beiden habe ich die Query time auf 0 gesetzt.
Naja ich has jetzt 25x ausprobiert und beim 26x wieder Timeout
es ist zum ...
Na ja gut, T-Virus,
das mag dann zwar im konkreten Fall für Dich zum ... Dingensmachen sein, ist aber im Grunde erklärlich.
Wenn Du (in Deiner Eigenschaft als DB-Client) auf dem Server rumorgelst, dann bekommst Du nach x sec den Hahn bzw. die Ressourcen abgedreht.
Verständlich, weil solche Antwortzeiten zu 98,7 % immer aufzu doofe suboptimale SQL-Statements hindeuten.
Das hat seine Richtigkeit - und ebenfalls sollte richtig sein, dass Du (am Client) diesen TimeOut-Wert nicht hochsetzen kannst/darfst. Der gilt ja auf dem Server und für alle Clients.
[Offen gestanden - ich hab keinen Verdacht, was Dein gefundener Reg-Wert aussagen soll.
Eventuell die Zeit, ab der Dein Client nicht mehr auf eine Antwort des Servers wartet, sondern von sich aus sagt "Connection closed"??]
Also - besseres Vorgehen:
a) Evtl einen Versuch: Setz Dich an den Server und mach es dort. (wie eben, interaktiv).
Aber nur einen Versuch... wahrscheinlich bringt es nix.
b) Sichereres Vorgehen: Verpack dieses Statement in eine Stored Procedure.
Dann wird es ja zwangsläufig auf dem Server ausgeführt - und damit VIEEEEL näher an der Datenbank, als Du vom Client über T-SQL oder whatever jemals rankommst.
[[c) ]] Wenn Dir das alles zu umwegig ist, dann wäre Plan B, den "SELECT INTO" zu portionieren... also immer nur einen Teil der Quelldaten pro Statement umzuschaufeln.
Ein Zehntel der Datensätze sollte auch nur 10% der Zeit und sonstigen Ressourcen fressen.
Aber das würde mir auch gegen die Berufsehre gehen....
Grüße
Biber
das mag dann zwar im konkreten Fall für Dich zum ... Dingensmachen sein, ist aber im Grunde erklärlich.
Wenn Du (in Deiner Eigenschaft als DB-Client) auf dem Server rumorgelst, dann bekommst Du nach x sec den Hahn bzw. die Ressourcen abgedreht.
Verständlich, weil solche Antwortzeiten zu 98,7 % immer auf
Das hat seine Richtigkeit - und ebenfalls sollte richtig sein, dass Du (am Client) diesen TimeOut-Wert nicht hochsetzen kannst/darfst. Der gilt ja auf dem Server und für alle Clients.
[Offen gestanden - ich hab keinen Verdacht, was Dein gefundener Reg-Wert aussagen soll.
Eventuell die Zeit, ab der Dein Client nicht mehr auf eine Antwort des Servers wartet, sondern von sich aus sagt "Connection closed"??]
Also - besseres Vorgehen:
a) Evtl einen Versuch: Setz Dich an den Server und mach es dort. (wie eben, interaktiv).
Aber nur einen Versuch... wahrscheinlich bringt es nix.
b) Sichereres Vorgehen: Verpack dieses Statement in eine Stored Procedure.
Dann wird es ja zwangsläufig auf dem Server ausgeführt - und damit VIEEEEL näher an der Datenbank, als Du vom Client über T-SQL oder whatever jemals rankommst.
[[c) ]] Wenn Dir das alles zu umwegig ist, dann wäre Plan B, den "SELECT INTO" zu portionieren... also immer nur einen Teil der Quelldaten pro Statement umzuschaufeln.
Ein Zehntel der Datensätze sollte auch nur 10% der Zeit und sonstigen Ressourcen fressen.
Aber das würde mir auch gegen die Berufsehre gehen....
Grüße
Biber
Hi
Ja es mag durchaus sein das es an suboptimalen SQL Statements liegt
wobei ich nicht verstehe was an einer Truncate Table und Insert Into suboptimal sein sollte?
Bin dankbar über Vorschläge!
Ich habe den RegKey auf meinem 2003 Server gefunden und da er unter \Microsoft SQL Server\
zu finden war bin ich mir eigentlich sicher den Reichtigen erwischt zu haben ;)
Außerdem habe ich mit dem SQL Manager Rechtsklick auf Server Einstellungen Query Timeout nach 0sek
und Connection Timeout auf 600sek gestellt.
Die Clients verwenden dann wieder eigene Timeout settings die ich auch hochgedreht habe
Danke für den Tip werde ich versuchen
Gibt es keine zuverlässige Lösung D:
Timeout hochstellen?
Ich finde auch in den Eventlogs kleinen genaueren Hinweis zu dem Timeout
wo genau speichert der SQL Server die logs?
Danke, LG
Wenn Du (in Deiner Eigenschaft als
DB-Client) auf dem Server rumorgelst, dann
bekommst Du nach x sec den Hahn bzw. die
Ressourcen abgedreht.
Verständlich, weil solche Antwortzeiten
zu 98,7 % immer aufzu doofe
suboptimale SQL-Statements hindeuten.
DB-Client) auf dem Server rumorgelst, dann
bekommst Du nach x sec den Hahn bzw. die
Ressourcen abgedreht.
Verständlich, weil solche Antwortzeiten
zu 98,7 % immer auf
suboptimale SQL-Statements hindeuten.
Ja es mag durchaus sein das es an suboptimalen SQL Statements liegt
wobei ich nicht verstehe was an einer Truncate Table und Insert Into suboptimal sein sollte?
Bin dankbar über Vorschläge!
dass Du (am Client)
diesen TimeOut-Wert nicht hochsetzen
kannst/darfst.
diesen TimeOut-Wert nicht hochsetzen
kannst/darfst.
Ich habe den RegKey auf meinem 2003 Server gefunden und da er unter \Microsoft SQL Server\
zu finden war bin ich mir eigentlich sicher den Reichtigen erwischt zu haben ;)
Außerdem habe ich mit dem SQL Manager Rechtsklick auf Server Einstellungen Query Timeout nach 0sek
und Connection Timeout auf 600sek gestellt.
Die Clients verwenden dann wieder eigene Timeout settings die ich auch hochgedreht habe
b) Sichereres Vorgehen: Verpack dieses
Statement in eine Stored Procedure.
Dann wird es ja zwangsläufig auf dem
Server ausgeführt - und damit VIEEEEL
näher an der Datenbank, als Du vom
Client über T-SQL oder whatever jemals
rankommst.
Statement in eine Stored Procedure.
Dann wird es ja zwangsläufig auf dem
Server ausgeführt - und damit VIEEEEL
näher an der Datenbank, als Du vom
Client über T-SQL oder whatever jemals
rankommst.
Danke für den Tip werde ich versuchen
Gibt es keine zuverlässige Lösung D:
Timeout hochstellen?
Ich finde auch in den Eventlogs kleinen genaueren Hinweis zu dem Timeout
wo genau speichert der SQL Server die logs?
Danke, LG
Moin T-Virus,
Ich kennedieses M$-Gelumpe die Datenbanklösungen des sympathischen Weltmarktführers zu wenig.
Unter Oracle würde ich für die Aktion alle REDO-, Logging und Trace-Einstellungen, die sonst sinnvollerweise für alle Datenmanipulationen gelten, AUSSETZEN/ABSCHALTEN.
Ob Du in T-SQL diese Möglichkeiten hast weiß ich nicht. Dort würde ich aber suchen.
Wenn der Grund für den TimeOut ist, dass es halt zu lange dauert...
Aber immerhin - wenn nichts im Eventlog steht, dann können wir aussschließen, dass schlicht und einfach der Tablespace für die neue Tabellenkopie zu klein war.
Das hätte uns sogar M$ berichtet.
Grüße
Biber
wobei ich nicht verstehe was an einer Truncate Table und Insert Into suboptimal sein sollte
Am INSERT INTO ist sicherlich "nur" die Menge der Daten suboptimal.Ich kenne
Unter Oracle würde ich für die Aktion alle REDO-, Logging und Trace-Einstellungen, die sonst sinnvollerweise für alle Datenmanipulationen gelten, AUSSETZEN/ABSCHALTEN.
Ob Du in T-SQL diese Möglichkeiten hast weiß ich nicht. Dort würde ich aber suchen.
Ich finde auch in den Eventlogs kleinen genaueren Hinweis zu dem Timeout
Was soll er auch schreiben?Wenn der Grund für den TimeOut ist, dass es halt zu lange dauert...
Aber immerhin - wenn nichts im Eventlog steht, dann können wir aussschließen, dass schlicht und einfach der Tablespace für die neue Tabellenkopie zu klein war.
Das hätte uns sogar M$ berichtet.
Grüße
Biber
