Zum Inhalt wechseln


Foto

Verbindungsabbrüche Datenbank


  • Bitte melde dich an um zu Antworten
28 Antworten in diesem Thema

#1 ChrisRa

ChrisRa

    Senior Member

  • 404 Beiträge

 

Geschrieben 27. Oktober 2016 - 11:48

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?


Keep IT simple.  ;)


#2 Sunny61

Sunny61

    Expert Member

  • 21.578 Beiträge

 

Geschrieben 27. Oktober 2016 - 12:46

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?
Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#3 ChrisRa

ChrisRa

    Senior Member

  • 404 Beiträge

 

Geschrieben 27. Oktober 2016 - 12:52

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 von ChrisRa, 27. Oktober 2016 - 13:06.

Keep IT simple.  ;)


#4 Sunny61

Sunny61

    Expert Member

  • 21.578 Beiträge

 

Geschrieben 27. Oktober 2016 - 13:14

Es gibt noch 2 CUs für den SQL 2014, evtl. solltest Du das letzte installieren und erneut testen: https://support.micr...e-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 von Sunny61, 27. Oktober 2016 - 13:24.

Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#5 ChrisRa

ChrisRa

    Senior Member

  • 404 Beiträge

 

Geschrieben 27. Oktober 2016 - 13:24

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

 

https://technet.micr...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 von ChrisRa, 27. Oktober 2016 - 13:37.

Keep IT simple.  ;)


#6 Sunny61

Sunny61

    Expert Member

  • 21.578 Beiträge

 

Geschrieben 27. Oktober 2016 - 13:43

Auf der gleichen Seite einfach den SQL Server ändern: https://technet.micr...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.micr...de-de/kb/309422
http://sqlmag.com/bl...-and-anti-virus

Bearbeitet von Sunny61, 27. Oktober 2016 - 13:43.

Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#7 ChrisRa

ChrisRa

    Senior Member

  • 404 Beiträge

 

Geschrieben 27. Oktober 2016 - 13:55

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.


Keep IT simple.  ;)


#8 Sunny61

Sunny61

    Expert Member

  • 21.578 Beiträge

 

Geschrieben 27. Oktober 2016 - 14:05

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

#9 ChrisRa

ChrisRa

    Senior Member

  • 404 Beiträge

 

Geschrieben 27. Oktober 2016 - 14:28

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 von ChrisRa, 27. Oktober 2016 - 14:29.

Keep IT simple.  ;)


#10 ChrisRa

ChrisRa

    Senior Member

  • 404 Beiträge

 

Geschrieben 28. Oktober 2016 - 07:03

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 von ChrisRa, 28. Oktober 2016 - 07:05.

Keep IT simple.  ;)


#11 Sunny61

Sunny61

    Expert Member

  • 21.578 Beiträge

 

Geschrieben 28. Oktober 2016 - 07:50

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?
Gruppenrichtlinien: http://www.gruppenrichtlinien.de/

#12 ChrisRa

ChrisRa

    Senior Member

  • 404 Beiträge

 

Geschrieben 28. Oktober 2016 - 08:22

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.


Keep IT simple.  ;)


#13 Squire

Squire

    Board Veteran

  • 3.298 Beiträge

 

Geschrieben 29. Oktober 2016 - 19:03

Netzwerktreiber und Firmware der physikalischen Nic sind aktuell?


"Every once in a while, declare peace. It confuses the hell out of your enemies"


#14 ChrisRa

ChrisRa

    Senior Member

  • 404 Beiträge

 

Geschrieben 14. November 2016 - 07:15

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


Keep IT simple.  ;)


#15 Jim di Griz

Jim di Griz

    Board Veteran

  • 810 Beiträge

 

Geschrieben 14. November 2016 - 12:17

Hallo,

welche Authentifizierung wird genutzt?

vielleicht ist es so etwas:

http://windowsitpro....ication-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?


2152 MCP 2000 Server, 70-410, 70-411, 70-412, 70-413, 70-414, 70-

Lizenzen : vse msdn abo