13
SQL Server Agent Fehler bei Datenabruf
Guten Morgen liebe Admins,
ich habe ein Problem mit dem Datenabruf via Linked Server.
Wir rufen in unserem Unternehmen Daten aus einer Intersystems Cache' Datenbank ab.
Dies geschieht in vielen Fällen über einen Agent Job der diverse Prozeduren aufruft.
In den Prozeduren werden über Linked Server Daten aus eine Cache' DB gezogen.
Das Problem:
Wird der Zentralrechner, auf dem die Datenbanken laufen, neu gestartet oder wird vom ersten Zentralrechner auf den zweiten Zentralrechner geschwenkt,
dann laufen alle Agent Jobs, welche diese Connection nutzen, auf einen Fehler.
Der Datenabruf funktioniert, wenn man eine Abfrage direkt im SSMS ausführt, ohne Probleme.
Läuft diese Abfrage aber automatisiert in der Nachtverarbeitung, läuft der Job auf einen Fehler.
Fehlermeldung:
Das Datenquellenobjekt des OLE DB-Anbieters "MSDASQL" für den Verbindungsserver "LinkedServerName" kann nicht initialisiert werden. [SQLSTATE 42000] (Fehler 7303) Der OLE DB-Anbieter "MSDASQL" für den Verbindungsserver "LinkedServerName" hat die Meldung "[Cache ODBC][State : S1T00][Native Code 450] [C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\sqlservr.exe] Request timed out due to user timeout" zurückgeben. [SQLSTATE 01000] (Fehler 7412).
Wieso sollte es auf einmal einen Timeout geben?
Kann man, falls es wirklich ein Timeout ist, diesen irgendwie aufheben?
Habt ihr eine Ahnung was das wohl sein könnte?
Infos:
Die Treiber 32 + 64 bit sind alle auf dem neuesten Stand.
Es handelt sich zum Großteil um Windows Server 2016 mit SQL Server 2016
Versuche die SQL Server Dienste neu zu starten haben auch nichts gebracht.
Vielleicht hat ja ein Admin einen Tipp für mich.
Ich bedanke mich vorab für Infos und wünsche einen schönen Tag.
MfG
O aus Dortmund
ich habe ein Problem mit dem Datenabruf via Linked Server.
Wir rufen in unserem Unternehmen Daten aus einer Intersystems Cache' Datenbank ab.
Dies geschieht in vielen Fällen über einen Agent Job der diverse Prozeduren aufruft.
In den Prozeduren werden über Linked Server Daten aus eine Cache' DB gezogen.
Das Problem:
Wird der Zentralrechner, auf dem die Datenbanken laufen, neu gestartet oder wird vom ersten Zentralrechner auf den zweiten Zentralrechner geschwenkt,
dann laufen alle Agent Jobs, welche diese Connection nutzen, auf einen Fehler.
Der Datenabruf funktioniert, wenn man eine Abfrage direkt im SSMS ausführt, ohne Probleme.
Läuft diese Abfrage aber automatisiert in der Nachtverarbeitung, läuft der Job auf einen Fehler.
Fehlermeldung:
Das Datenquellenobjekt des OLE DB-Anbieters "MSDASQL" für den Verbindungsserver "LinkedServerName" kann nicht initialisiert werden. [SQLSTATE 42000] (Fehler 7303) Der OLE DB-Anbieter "MSDASQL" für den Verbindungsserver "LinkedServerName" hat die Meldung "[Cache ODBC][State : S1T00][Native Code 450] [C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\sqlservr.exe] Request timed out due to user timeout" zurückgeben. [SQLSTATE 01000] (Fehler 7412).
Wieso sollte es auf einmal einen Timeout geben?
Kann man, falls es wirklich ein Timeout ist, diesen irgendwie aufheben?
Habt ihr eine Ahnung was das wohl sein könnte?
Infos:
Die Treiber 32 + 64 bit sind alle auf dem neuesten Stand.
Es handelt sich zum Großteil um Windows Server 2016 mit SQL Server 2016
Versuche die SQL Server Dienste neu zu starten haben auch nichts gebracht.
Vielleicht hat ja ein Admin einen Tipp für mich.
Ich bedanke mich vorab für Infos und wünsche einen schönen Tag.
MfG
O aus Dortmund
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: 1574415750
Url: https://administrator.de/contentid/1574415750
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
13 Kommentare
Neuester Kommentar
Noch nicht wirklich einen Tipp aber eine Beobachtung: Mein SSMS habe ich eigentlich immer offen, wenn das dann länger gestanden hat und ich die erste Abfrage starte bekomme ich auch sofort einen Fehler zurück. Die genaue Meldung muss ich mir nochmal aufschreiben. Das passiert aber auch wirklich sofort, der Timeout ist also nicht sehr lang. Beim zweiten mal, also direkt eine Sekunde danach geht es dann auch schon.
Kannst du über Zeitstempel oder Ereignislog sehen wie lange der Request überhaupt gedauert hat? Lässt sich eventuell der Request mehrfach durchführen oder was passiert wenn kurz davor eine banale Abfrage über den selben linked server ausgeführt wird, scheitert dann auch die eigentliche Abfrage?
Tritt der Fehler erst seit kurzem auf oder schon seit dem es das Setup gibt?
Kannst du über Zeitstempel oder Ereignislog sehen wie lange der Request überhaupt gedauert hat? Lässt sich eventuell der Request mehrfach durchführen oder was passiert wenn kurz davor eine banale Abfrage über den selben linked server ausgeführt wird, scheitert dann auch die eigentliche Abfrage?
Tritt der Fehler erst seit kurzem auf oder schon seit dem es das Setup gibt?
Moin Ukulele,
Danke für Deine Info zu Deiner Beobachtung.
Im Event Log steht nichts anderes als in meinem Post genannt.
Die Abfragen dauern in der Regel schon länger.
Ich führe die Tests immer mit banalen Abfragen aus.
Das Problem bezieht sich auf mehrere Server.
Die Jobs laufen monate ohne Probleme.
Wird jedoch der Zentralrechner neu gestartet laufen diese immer wieder auf einen Fehler.
Denke es hat in dem Moment keine richtige Connection oder es besteht eine "alte" Session", welche bei Neustart die Connection verliert.
Daher Dienst-Neustart getestet.
Es gibt kein Setup !
Grüsse O
Danke für Deine Info zu Deiner Beobachtung.
Im Event Log steht nichts anderes als in meinem Post genannt.
Die Abfragen dauern in der Regel schon länger.
Ich führe die Tests immer mit banalen Abfragen aus.
Das Problem bezieht sich auf mehrere Server.
Die Jobs laufen monate ohne Probleme.
Wird jedoch der Zentralrechner neu gestartet laufen diese immer wieder auf einen Fehler.
Denke es hat in dem Moment keine richtige Connection oder es besteht eine "alte" Session", welche bei Neustart die Connection verliert.
Daher Dienst-Neustart getestet.
Es gibt kein Setup !
Grüsse O
Mit Setup meine ich ob diese Konstellation, diese Einrichtung das Problem immer schon gehabt hat oder ob das jetzt erst seit kurzem so ist.
Das Problem gibt es eigentlich schon immer.
Daten mussten dann immer manuell nachgeladen werden.
Wenn ein Agent Job manuell nachgestartet wird, werden die Daten wieder normal geladen.
Er läuft er dann wieder bis zum nächsten Neustart des ZR.
Das ist auf allen Servern so...
Daten mussten dann immer manuell nachgeladen werden.
Wenn ein Agent Job manuell nachgestartet wird, werden die Daten wieder normal geladen.
Er läuft er dann wieder bis zum nächsten Neustart des ZR.
Das ist auf allen Servern so...
Und wenn du so eine fehlerhafte Abfrage hast und direkt noch einmal ausführst, geht dann der zweite Versuch?
Hi,
die Abfragen sind nicht fehlerhaft!
Wenn ich die Abfragen im SSMS ausführe funktionieren die immer.
Im Agent auch immer, AUSSER es gab einen ZR Neustart/Schwenk.
Dann und nur dann laufen diese Jobs auf einen Fehler.
Danke für Deine Nachfrage.
die Abfragen sind nicht fehlerhaft!
Wenn ich die Abfragen im SSMS ausführe funktionieren die immer.
Im Agent auch immer, AUSSER es gab einen ZR Neustart/Schwenk.
Dann und nur dann laufen diese Jobs auf einen Fehler.
Danke für Deine Nachfrage.
Sry ich meinte nicht "fehlerhafte Abfrage" sondern in einem Fall wo die Abfrage einen Fehler zurück liefert. Geht dann die selbe Abfrage bei einer Wiederholung einfach durch?
Moin,
du schreibst das passiert jedes Mal wenn ein Neustart oder einen Schwenk auf einen anderen Server durchgeführt wird.
Was für eine SQL Konfiguration hast du?
Reden wir hier von Always ON Verfügbarkeitsgruppen, SQL Server Always ON Failoverclusterinstanz oder sogar von einer HA Lösung von Hyper-V bzw. VMware?
Ich vermute das dein Problem eher daher kommt und das deine Prozedur nicht korrekt verbindet.
Mit dem SSMS machst du eine AD-Hoc Abfrage und da wird es vermutlich immer funktionieren, da du aktuelle Credentials verwendest bzw. den korrekten Servernamen.
Allerdings ist das ist jetzt eher eine Vermutung, da wir deine Konfiguration nicht kennen.
Viele Grüße
Rene
du schreibst das passiert jedes Mal wenn ein Neustart oder einen Schwenk auf einen anderen Server durchgeführt wird.
Was für eine SQL Konfiguration hast du?
Reden wir hier von Always ON Verfügbarkeitsgruppen, SQL Server Always ON Failoverclusterinstanz oder sogar von einer HA Lösung von Hyper-V bzw. VMware?
Ich vermute das dein Problem eher daher kommt und das deine Prozedur nicht korrekt verbindet.
Mit dem SSMS machst du eine AD-Hoc Abfrage und da wird es vermutlich immer funktionieren, da du aktuelle Credentials verwendest bzw. den korrekten Servernamen.
Allerdings ist das ist jetzt eher eine Vermutung, da wir deine Konfiguration nicht kennen.
Viele Grüße
Rene
Alles gut Ukuele,
also der Ablauf ist folgender...
Ich muss Daten aus einer bestimmten Quelle (Cache' Datenbank) abrufen.
Dafür baue ich im Vorfeld entspr. Abfragen, führe diese aus und checke ob alles korrekt, komplett und im richtigen Format enthalten ist.
Danach, wenn alles okay ist, baue ich auf Basis dieser Abfragen, eine Procedure, welche ich über den Agent Job ausführe.
Das funktioniert seit Jahren mit allen möglichen Datenquellen.
Ausser beim Datenabruf aus einer Cache' DB.
@Rene:
Danke für Deine Fragen.
Ja, dass passiert jedes Mal, wenn der Zentralrechner, auf dem die Cache' DB läuft neu gestartet wird.
Die SQL Server sind allesamt VM's
Das es mit den Credentials oder der Authentifizierung zu tun hat, habe ich auch schon überlegt.
Allerdings mache ich ja, wenn ich das automatisiert über den Agent Job mache,
auch keine Ad-Hoc Abfrage, oder?
Was könnte ich denn da anders machen?
Zumal es sich um ca. 20-30 Jobs handelt, die das ganze Jahr eigentlich ohne Probleme laufen und nur bei Neustart/Schwenk des ZR auf den o.g. Fehler Timout laufen.
Nachdem ich heute die fehlerhaften Jobs manuell gestartet habe, werden diese bis zum nächsten Neustart wieder ohne Probleme laufen....
Danke Euch für weiteren Input, da ich es mir nicht erklären kann...
Grüsse O
also der Ablauf ist folgender...
Ich muss Daten aus einer bestimmten Quelle (Cache' Datenbank) abrufen.
Dafür baue ich im Vorfeld entspr. Abfragen, führe diese aus und checke ob alles korrekt, komplett und im richtigen Format enthalten ist.
Danach, wenn alles okay ist, baue ich auf Basis dieser Abfragen, eine Procedure, welche ich über den Agent Job ausführe.
Das funktioniert seit Jahren mit allen möglichen Datenquellen.
Ausser beim Datenabruf aus einer Cache' DB.
@Rene:
Danke für Deine Fragen.
Ja, dass passiert jedes Mal, wenn der Zentralrechner, auf dem die Cache' DB läuft neu gestartet wird.
Die SQL Server sind allesamt VM's
Das es mit den Credentials oder der Authentifizierung zu tun hat, habe ich auch schon überlegt.
Allerdings mache ich ja, wenn ich das automatisiert über den Agent Job mache,
auch keine Ad-Hoc Abfrage, oder?
Was könnte ich denn da anders machen?
Zumal es sich um ca. 20-30 Jobs handelt, die das ganze Jahr eigentlich ohne Probleme laufen und nur bei Neustart/Schwenk des ZR auf den o.g. Fehler Timout laufen.
Nachdem ich heute die fehlerhaften Jobs manuell gestartet habe, werden diese bis zum nächsten Neustart wieder ohne Probleme laufen....
Danke Euch für weiteren Input, da ich es mir nicht erklären kann...
Grüsse O
Hallo O,
ich habe jetzt zwar noch nicht ganz verstanden, auf welchem Rechner welche Datenbank läuft und welcher von denen dann neu gestartet wird, aber:
Überlegung 1: Der Server, von dem Ihr abruft, steht in dem Moment nicht zur Verfügung und deswegen kommt der Timeout. Kann aber sein, daß dann die Meldung anders lautet.
Überlegung 2: Der Abfrageplan wird neu erstellt oder die Daten müssen erst noch ins RAM gelesen werden oder sonst irgendwas wird durch den Neustart ausgelöst und deswegen dauert es etwas länger und löst den Timeout aus.
Möglichkeiten zur Behebung:
Wenn der Server in dem Moment nicht zur Verfügung steht, dann könnte man mit try/catch den Fehler abfangen und die Datenübertragung neu starten bis es entweder klappt oder eine von Euch festgesetzte Zeitspanne / Anzahl Versuche überschritten wurde.
Wenn es ein Timeout ist, dann kann man die Zeitspanne hochsetzen. Das geht entweder im Providerstring mit Timeout=xxx (keine Ahnung, ob das bei jedem geht) oder über sp_serveroption mit der Option "connect timeout".
Gruß, Mad Max
ich habe jetzt zwar noch nicht ganz verstanden, auf welchem Rechner welche Datenbank läuft und welcher von denen dann neu gestartet wird, aber:
Überlegung 1: Der Server, von dem Ihr abruft, steht in dem Moment nicht zur Verfügung und deswegen kommt der Timeout. Kann aber sein, daß dann die Meldung anders lautet.
Überlegung 2: Der Abfrageplan wird neu erstellt oder die Daten müssen erst noch ins RAM gelesen werden oder sonst irgendwas wird durch den Neustart ausgelöst und deswegen dauert es etwas länger und löst den Timeout aus.
Möglichkeiten zur Behebung:
Wenn der Server in dem Moment nicht zur Verfügung steht, dann könnte man mit try/catch den Fehler abfangen und die Datenübertragung neu starten bis es entweder klappt oder eine von Euch festgesetzte Zeitspanne / Anzahl Versuche überschritten wurde.
Wenn es ein Timeout ist, dann kann man die Zeitspanne hochsetzen. Das geht entweder im Providerstring mit Timeout=xxx (keine Ahnung, ob das bei jedem geht) oder über sp_serveroption mit der Option "connect timeout".
Gruß, Mad Max
Moin Mad Max
vielen Dank für Deine Infos.
Thema ZR:
Es gibt 2, einer ist gespiegelt, der andere aktiv.
Auf dem aktiven laufen jeweils die DB.
Also ZR 1 aktiv, ZR 2 Mirror. Oder umgekehrt, wenn geschwenkt.
Überlegung 1:
Der Server steht zur Verfügung. Daten sind von diesem abrufbar.
Nach Neustart Select kein Thema.
Nachtverarbeitung No Chance.
Job manuell angeschmissen = Job läuft durch und ohne Probleme weiter bis zum nächsten Neustart.
Überlegung 2:
Ja, aber was wird ausgelöst? Der Neustart ist ja komplett durch und Daten verfügbar.
Query Plan... ?
Kann ich mir nicht vorstellen. Checke aber mal ob es einen Zusammenhang gibt.
Tipps:
Try/Catch könnte ich mal testen. Geht leider erst wieder beim nächsten Neustart.
Kann ich leider nicht so einfach anstoßen, da ZR.
Timeouts sollten alle entsprechend auf max bzw. was möglich ist gesetzt sein. Checke ich aber auch.
Ich danke Dir erstmal für Deine Überlegungen und Tipps.
Bin für weitere Tipps dankbar.
Noch nen schönen Abend.
Grüße O
vielen Dank für Deine Infos.
Thema ZR:
Es gibt 2, einer ist gespiegelt, der andere aktiv.
Auf dem aktiven laufen jeweils die DB.
Also ZR 1 aktiv, ZR 2 Mirror. Oder umgekehrt, wenn geschwenkt.
Überlegung 1:
Der Server steht zur Verfügung. Daten sind von diesem abrufbar.
Nach Neustart Select kein Thema.
Nachtverarbeitung No Chance.
Job manuell angeschmissen = Job läuft durch und ohne Probleme weiter bis zum nächsten Neustart.
Überlegung 2:
Ja, aber was wird ausgelöst? Der Neustart ist ja komplett durch und Daten verfügbar.
Query Plan... ?
Kann ich mir nicht vorstellen. Checke aber mal ob es einen Zusammenhang gibt.
Tipps:
Try/Catch könnte ich mal testen. Geht leider erst wieder beim nächsten Neustart.
Kann ich leider nicht so einfach anstoßen, da ZR.
Timeouts sollten alle entsprechend auf max bzw. was möglich ist gesetzt sein. Checke ich aber auch.
Ich danke Dir erstmal für Deine Überlegungen und Tipps.
Bin für weitere Tipps dankbar.
Noch nen schönen Abend.
Grüße O
TRY CATCH wäre auch meine Wahl, eine Fehlernummer würde glaube ich helfen.
Danke für Deinen/Euren Tipp.
Werde ich testen.
Melde mich, sobald ich Ergebnisse habe.
Werde ich testen.
Melde mich, sobald ich Ergebnisse habe.
