Jump to content

Verbindungsabbrüche Datenbank


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Recommended Posts

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?

Link to comment
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.

Edited by ChrisRa
Link to comment

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

Edited by Sunny61
Link to comment

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:

Edited by ChrisRa
Link to comment

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>

Edited by ChrisRa
Link to comment

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.

Link to comment
  • 3 weeks later...

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?

Link to comment
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...