Verbindungsabbrüche Datenbank

[ChrisRa 42]

Hallo zusammen,

 

wir haben Anfang der Woche eine Datenbank auf einen neuen SQL Server 2014 umgezogen.

Seitdem haben wir sporadische Verbindungsabbrüche. So 2-3 am Tag. Anwendungen frieren ein oder crashen. Die Software verliert die ODBC-Verbindung.

 

Ich suche seit 2 Tagen nach brauchbaren Logs o.ä. finde aber nirgends vernünftige, aussagekräftige Fehler.

Der Server ist im Monitoring und ist via Pings seit Erstelldatum ununterbrochen erreichbar. Diese Fehlerquelle kann man also ausschließen, denke ich mal.

 

Hat noch jemand eine Idee, wo ich ansetzen kann?

[Sunny61 833]

Im SQL Server Management Studio mit SELECT @@Version die Versionsnummer rausfinden und posten. Ist denn die uns unbekannte Anwendung für den SQL 2014 freigegeben?

[ChrisRa 42]

Ja, ich muss noch dazu sagen, dass es mehrere Datenbanken von unterschiedlichen Anwendungen sind, die diese Abbrüche haben. Die Anwendungen sind für den SQL 2014 freigegeben.

Ich habe den SQL-Server Standard installiert. Ich habe also keine weiteren Konfigurationen vorgenommen.

 

Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64) 

Jun 17 2016 19:14:09 

Copyright © Microsoft Corporation

Standard Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)

 

Hier mal die verwertbaren Eventlogs:

Diese Fehler tauchen nach einem Reboot des Servers auf. Machen imho aber nicht den Eindruck, als würden diese den Fehler verursachen.

 

 

Event ID 107 Quelle: Report Server Windows Service (MSSQLSERVER)

Report Server Windows Service (MSSQLSERVER) kann nicht mit der Berichtsserver-Datenbank verbunden werden.

 

 

Event ID 490 Quelle: ESENT

sqlservr (1624) Versuch, Datei "C:\Windows\system32\LogFiles\Sum\Api.chk" für den Lese-/Schreibzugriff zu öffnen, ist mit Systemfehler 5 (0x00000005): "Zugriff verweigert " fehlgeschlagen. Fehler -1032 (0xfffffbf8) beim Öffnen von Dateien.

 

 

Event ID 490 Quelle: ESENT

msmdsrv (1660) Versuch, Datei "C:\Windows\system32\LogFiles\Sum\Api.chk" für den Lese-/Schreibzugriff zu öffnen, ist mit Systemfehler 5 (0x00000005): "Zugriff verweigert " fehlgeschlagen. Fehler -1032 (0xfffffbf8) beim Öffnen von Dateien.

bearbeitet 27. Oktober 2016 von ChrisRa

[Sunny61 833]

Es gibt noch 2 CUs für den SQL 2014, evtl. solltest Du das letzte installieren und erneut testen: https://support.microsoft.com/de-de/kb/2936603

 

EDIT: Kannst Du zum Zeitpunkt eines solchen Abbruches, denn noch auf das Dateisystem des SQL Servers zugreifen, oder ist nur die Instanz nicht mehr verfügbar?

bearbeitet 27. Oktober 2016 von Sunny61

[ChrisRa 42]

Das ist ja schon mal ein Ansatz, super. Danke!

 

https://technet.microsoft.com/de-de/library/dd638062(v=sql.105).aspx

 

Sollte ich mich daran halten? Ich finde keinen aktualisierten Artikel. 

 

Edit: Die Instanz ist innerhalb von Sekunden wieder erreichbar. Ein erneuter Login funktioniert sofort.

bearbeitet 27. Oktober 2016 von ChrisRa

[Sunny61 833]

Auf der gleichen Seite einfach den SQL Server ändern: https://technet.microsoft.com/de-de/library/dd638062(v=sql.120).aspx

Ich würde die Instanz mit allen Datenbank in einem Wartungsfenster updaten. Natürlich nicht ohne saubere Datensicherung vorher. Sind es immer die gleichen Clients, die die Abbrüche melden? Und was ist während so einem Abbruch, kannst Du dann von einem Client auf das Dateisystem zugreifen? Gibt es im SQL Server Log Einträge?

 

Habt ihr denn im AV-Scanner auch die passenden/richtigen Ausnahmen eingetragen? https://support.microsoft.com/de-de/kb/309422

http://sqlmag.com/blog/sql-server-and-anti-virus

bearbeitet 27. Oktober 2016 von Sunny61

[ChrisRa 42]

Der Abbruch erfolgt so schnell, in dieser Zeit kann man leider nichts weiteres prüfen.

 

Gibt es noch weitere Quellen für Logs, bis auf die Fehlerprotokolle unterhalb des SQL Server-Agent?

 

Ein Antivirenscanner ist auf dem Server nicht installiert.

[Sunny61 833]

Kannst Du denn die 490er Fehler zeitlich mit den Abbrüchen in Verbindung bringen? http://www.eventid.net/display-eventid-490-source-ESENT-eventno-3643-phase-1.htm Scannen die Clients evtl. zu viel? Du solltest zuerst das aktuelle CU installieren, den Server booten und dann erneut testen.

[ChrisRa 42]

Die 490er nicht. Ich habe nun noch ein paar weitere Fehler im Eventlog gefunden, die ich zeitlich ziemlich genau zuordnen kann. Ich update den SQL-Server morgen früh erstmal und warte den Vormittag mal ab. Sollte es weitere Abbrüche geben, fasse ich die Fehler im Eventlog mal zusammen.

 

Danke für deine Unterstützung!  :)  :thumb1:

bearbeitet 27. Oktober 2016 von ChrisRa

[ChrisRa 42]

Ich habe heute Morgen das CU2 installiert. Außerdem habe ich die Services des SQL-Servers nun im Kontext eines lokalen Administrators laufen.

Die Fehlermeldungen sind aus dem Log verschwunden. Abbrüche gibt es immer noch.

 

Eine Meldung erscheint noch im Log, nachdem ein Client einen Verbindungsabbruch hatte.

 

Event ID1, Quelle: VBRuntime

The VB Application identified by the event source logged this Application RPCSVR_<SOFTWAREHERSTELLER>: Thread ID: 1900 ,Logged: RPC-Error: 6BA Client 10.1.0.48:20001 <TERMINALSERVER>/<APPLICATIONUSER>

bearbeitet 28. Oktober 2016 von ChrisRa

[Sunny61 833]

Läuft auf dem SQL Server ein Terminal- bzw. RDS-Server? Haben die Abbrüche alle Clients oder nur bestimmte? Ist das eine VM? Wenn nein, dann bitte die Treiber für die NIC prüfen. Ist ein Teaming eingerichtet? Gibt es mehrere NICs? Wenn ja, wie ist die Aufteilung für den SQL Server in dieser Hinsicht?

[ChrisRa 42]

Der SQL-Server läuft in einer eigenständigen VM ohne weitere Software/Rollen/Dienste (bis auf die Anwendungsspezifischen). Abbrüche haben alle Clients. Sowohl Terminalserver als auch direkt angebundene am Standort Vorort. Teaming ist zurzeit noch nicht eingerichtet. Mehrere NICs gibt es auf dem Host. Die VM des SQL-Servers ist aber nur an einem virtuellen Switch angebunden. Der SQL-Server hat also nur eine NIC. 

 

Der Host hängt mit einer NIC im alten Netzwerk (der Datenbankumzug hat stattgefunden, weil wir eine neue Domänenstruktur aufbauen) und mit einer NIC im neuen Netzwerk. Der SQL-Server hängt in dem Virtuellen Switch des neuen Netzwerkes. 

 

Verbindungsabbrüche gibt es aber nicht. Der SQL-Server hat zu allen Clients durchgehend <1ms. Infrastrukturelle Probleme hatte ich also erstmal ausgeschlossen.

 

Ich beobachte nun mal den RPC-Dienst der Anwendung mit dem Procmon. Vielleicht gibt es da ja neue Erkenntnisse.

[Squire 290]

Netzwerktreiber und Firmware der physikalischen Nic sind aktuell?

[ChrisRa 42]

Wird heute Abend mal gemacht. Abbrüche sind immer noch da. Keine neuen Erkenntnisse.

[Jim di Griz 13]

Hallo,

welche Authentifizierung wird genutzt?

vielleicht ist es so etwas:

http://windowsitpro.com/windows/resolve-performance-problems-associated-authentication-scaling

MaxConcurrentAPI, wegen der "Access denied" Meldungen.

Ist der neue SQL-Server ein neuer Server oder eine neue Instanz auf einem bestehenden Server?

Ist die Arbeitslast hoch zur Zeit der Abbrüche?