Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Verbindungsunterbruch zur Datenbank
#41
Der Client-Connection-String kann anscheinend nicht direkt auf IPv4 oder IPv6 gesetzt werden - entscheidend ist die Server-Konfiguration - es sollte also auch kein Problem sein IPv4 zu deaktivieren und alles über IPv6 laufen zu lassen

https://docs.microsoft.com/en-us/sql/too...using-ipv6
Regards/Gruss
Oliver
Reply
#42
@rega

Wir haben die Ursache mit einem Process Monitor Trace herausgefunden:
https://docs.microsoft.com/en-us/sysinte...ds/procmon

Ein Kollege hat das procmon.exe Tool parallel mitlaufen lassen, natürlich gefiltert auf die Process Id des ASG. Er hat es gestoppt, einige Sekunden nachdem das Problem auftrat. Dadurch hatten wir am Schluss des Trace das Problem mitgeschnitten. ProcMon zeichnet File, Registry und Netzwerk I/O auf -> damit konnten wir die IPv6 Connections identifizieren, die ein Timeout verursacht haben.

Vielleicht hilfts ja. Advanced Variante wäre dann ein Wireshark Trace, wenn ihr weiterhin das Netzwerk im Verdacht habt.
Reply
#43
Danke für die Info - ich denke auch das es auf jeden Fall ein Netzwerk-Problem ist und die Kombination IPv4 und IPv6 verursacht diese Probleme nachweislich laut MS-Doku wenn man nicht entsprechende Konfigurationen vornimmt...
Regards/Gruss
Oliver
Reply
#44
(08-02-2018, 09:03 PM)claudio Wrote: @rega

Wir haben die Ursache mit einem Process Monitor Trace herausgefunden:
https://docs.microsoft.com/en-us/sysinte...ds/procmon

Ein Kollege hat das procmon.exe Tool parallel mitlaufen lassen, natürlich gefiltert auf die Process Id des ASG. Er hat es gestoppt, einige Sekunden nachdem das Problem auftrat. Dadurch hatten wir am Schluss des Trace das Problem mitgeschnitten. ProcMon zeichnet File, Registry und Netzwerk I/O auf -> damit konnten wir die IPv6 Connections identifizieren, die ein Timeout verursacht haben.

Vielleicht hilfts ja. Advanced Variante wäre dann ein Wireshark Trace, wenn ihr weiterhin das Netzwerk im Verdacht habt.

Danke für denn Tipp Claudio!
Mit ProcMon kam ich bis jetzt leider nicht weiter.

Ich werde nun Wireshark auf einem ausgewählten Terminalserver laufen lassen, um das Ganze zu analysieren.
Gerne schreibe ich meine Ergebnisse ins Forum, sobald sich etwas ergeben hat.

Gruss und schonmal schönes Wochenende!
Reply
#45
Ich habe es nun mit WireShark geprüft und es wird eindeutig keine IPv6 Verbindung hergestellt.
Die Fehler traten bei Version 2018 Patch 1 auf.

Falls Sie es wünschen, kann ich Ihnen auch die WireShark Datei per PN zusenden.
ASG lief nach der Unhandled Expection Meldung ohne Probleme weiter und verblieb auch im Online Modus.


Attached Files Thumbnail(s)
       
Gruss
rega
Reply
#46
Ich glaube das auch ohne Datei - allerdings fällt mir auf, das es hier beim "LogsGet"-Command zum Timeout kommt - das könnte dann auch sein, das die Log-Daten zu gross sind?!? Tritt der Fehler beim Start auf? Dann sollte mal "Tools=>Reset Layout" gemacht werden, damit die Logs nicht mehr beim Start geladen werden - und die Größe der Logs sollte nochmal geprüft werden (falls schon erfolgt, ist immer schwierig in einem Sammel-Thread die Übersicht zu behalten) - oder eben eine automatische Begrenzung der Log-Einträge aktivieren (Einstellungen=>Logs)
Regards/Gruss
Oliver
Reply
#47
Ja, die Verbindung wird teilweise auch beim Start unterbrochen. Die Grösse des Transaction Logs der DB liegt bei 6.2 MB und die Logs sind auf 30 Tage und/oder 500 Einträge limitiert.
Ich werde vorerst die "Reset Layout" Option bei den betroffenen Benutzern durchführen und mich wieder melden, falls das Problem erneut auftritt.
Gruss
rega
Reply
#48
Leider hat die Option "Reset Layout" nichts bewirkt. 
Heute hat ein Benutzer wieder die gleiche Fehlermeldung wie gestern erhalten...
Gruss
rega
Reply
#49
Ich habe im Wireshark folgende Meldungen bei einem Unterbruch. Kann es einen Einfluss haben, dass die vom Remote Desktop benutzten Ports immer wieder wechseln und kann ich das unterbinden?
Dynamic Ports sind auf dem SQL deaktiviert.


Attached Files Thumbnail(s)
   
Gruss
rega
Reply
#50
Also das würde ich einer gewissen "Eigenständigkeit des native SQL Clients" zuweisen - aber letztendlich kann man beim Angeben des SQL-Servers (oder der Instanz) auch einen Port mitgeben - einfach einen Doppelpunkt und dann den Port angeben

SQLSERVER(\Instance):Port

Vielleicht hilft das dann weiter?
Regards/Gruss
Oliver
Reply
#51
Leider hat auch die Definition des Ports keine Änderung gebracht. Wir erhalten weiterhin Verbindungsunterbrüche...
Gruss
rega
Reply
#52
Leider ist das Problem immer noch bestehend. 
Bei jedem Unterbruch wird mir die angezeigt, dass sich Daten während des Unterbruchs geändert haben.
Wissen Sie was der Eintrag ObjectProperties Settings: ??? bedeutet?

Momentan bin ich am Testen ob die Unterbrüche auch auf der 2012 SQL Express Version auftreten.


Attached Files Thumbnail(s)
   
Gruss
rega
Reply
#53
Das kann ignoriert werden - sind interne Settings - können wir mal prüfen, welche genau

Ich kann da leider nicht viel ändern - es muss was im Netzwerk sein - einige Fehler konnten über IPv6 ausschalten eliminiert werden - aber clientseitig kann ich da einfach keine Optionen mitgeben
Regards/Gruss
Oliver
Reply
#54
Es ist nicht möglich, dass die Unterbrüche am Netzwerk liegen. Die Server befinden sich im gleichen Subnet und auf dem gleichen ESX Host. Somit steht nichts zwischen den Servern, was einen Einfluss haben könnte. Die Windows Firewall ist deaktiviert.



Ich habe einen Test durchgeführt, indem ich einen Benutzer alleine auf einem separaten identischen SQL Server (gleiches Subnet, Windows 2016, SQL Express 2017) arbeiten liess.
Er hatte in dieser Zeit lediglich einen Unterbruch in der Woche. Normalerweise sind es zwei bis drei Unterbrüche täglich. 
Nachdem ich alle Benutzer auf den neuen SQL Server migrierte, traten die Unterbrüche wieder gleich oft auf. 

Auf dem SQL Server kann ich sehen, dass meine Session innerhalb von 10 Minuten geschlossen wird. Während diesen 10 Minuten habe ich eine aktive RDP Verbindung über ASG offen.
Wenn ich nun eine andere Verbindung öffne, ensteht wieder eine neue SQL Session und ich bleibe wieder für ca. 10 Minuten angemeldet. 

Falls meine offene Session länger als 5 Minuten "idle" ist, da ich keine neue Verbindung geöffnet habe und sich ein zweiter Benutzer am ASG anmeldet, wird meine bestehende SQL Session für den neuen Benutzer verwendet. Erst wenn ich dann kurz darauf mit dem ersten Benutzer wieder eine Abfrage starte, habe ich eine zweite SQL Session offen. 

Solange ich eine offene SQL Session habe kann ich problemlos arbeiten. Wenn ich aber eine neue Session öffne (nach 10 Minuten oder beim Start) kann es sein, dass ich die bekannten Unterbrüche habe. Was in 2 von 10 Tests der Fall ist.

Aus meiner Sicht funktioniert die Keep Alive Funktion nicht ordnungsgemäss. 
Wie kann diese im ASG oder auf dem SQL 2017 entsprechend konfiguriert werden?

Danke!
Gruss
rega
Reply
#55
Ich bin kein SQL-Server-Experte - es gibt bestimmt viel einzustellen auf einem SQL-Server, aber das kann ich leider nicht beantworten. Die "Keep Alive Funktion" sind Interna im SQL-Client oder SQL-Server - das lässt sich nicht im ConnectionString einstellen - das Problem ist das wir sicherlich eine 4stellige Zahl an SQL-Nutzern haben, das Problem aber anscheinend nur bei einer Handvoll Kunden auftaucht - und da wiederrum ist das Problem durch Deaktivieren von IPv6 bei der Hälfte verschwunden - das war auch das einzige was ich bei meinen Recherchen herausgefunden habe. Wir selbst nutzen und testen das Programm tag-täglich und das Problem ist noch nie aufgetaucht.

Ich kann die Tage nochmal schauen ob ich einen Support-Channel für SQL-Probleme bei MS finde und da das Problem schildern, aber ich wüsste momentan nicht wie wir an dieser Stelle sonst weiterkommen sollen...
Regards/Gruss
Oliver
Reply




Users browsing this thread: 1 Guest(s)