t-virus
Goto Top

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

Content-Key: 88071

Url: https://administrator.de/contentid/88071

Ausgedruckt am: 28.03.2024 um 14:03 Uhr

Mitglied: T-Virus
T-Virus 21.05.2008 um 19:54:05 Uhr
Goto Top
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.
Mitglied: Biber
Biber 21.05.2008 um 20:12:44 Uhr
Goto Top
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
Mitglied: T-Virus
T-Virus 21.05.2008 um 20:56:01 Uhr
Goto Top
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 ...
Mitglied: Biber
Biber 21.05.2008 um 21:40:07 Uhr
Goto Top
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 auf zu 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
Mitglied: T-Virus
T-Virus 21.05.2008 um 22:45:15 Uhr
Goto Top
Hi

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 zu doofe
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.

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.

Danke für den Tip werde ich versuchen

Gibt es keine zuverlässige Lösung D:
Timeout hochstellen? face-sad

Ich finde auch in den Eventlogs kleinen genaueren Hinweis zu dem Timeout
wo genau speichert der SQL Server die logs?

Danke, LG
Mitglied: Biber
Biber 22.05.2008 um 00:03:29 Uhr
Goto Top
Moin T-Virus,

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 dieses 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.
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