Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Verbindungsunterbruch zur Datenbank
#1
Guten Tag

Einige Benutzer bei uns haben mehrmals pro Tag das Problem, dass sie die Verbindung zur Datenbank verlieren. 
Das Ganze läuft wie folgt ab:
Erst reagiert ASG nicht mehr und man kann zwischen den offenen Fenstern nicht länger hin und her switchen. Dann kommt der erste Fehler, welcher aussagt, dass keine Verbindung hergestellt werden konnte (Fehler-1).

Danach wechselt man automatisch in den Offline Modus. Nun möchte man die Verbindung wiederherstellen, was nicht geht (Fehler-2).

Erst beim dritten Versuch klappt der Verbindungsaufbau wieder.
Während diesem Vorgang können andere Benutzer ohne Probleme auf der gleichen DB weiterarbeiten.
Die Datenbank ist im gleichen Subnetz wie der Terminalserver, auf welchem unsere Benutzer arbeiten. 
Ich sehe keine Fehlermeldungen, weder im Eventlog von TS und SQL Server noch im SQL-Log selbst.
Der SQL Server ist während dieser Zeit auch nicht maximal ausgelastet.

Wie entstehen diese Unterbrüche und wie kann ich diese verhindern?

Schönen Nachmittag und Grüsse
rega


Attached Files
.png   Fehler-1.png (Size: 17.06 KB / Downloads: 8)
.png   Fehler-2.png (Size: 25.26 KB / Downloads: 5)
.png   Fehler-3.png (Size: 23.55 KB / Downloads: 4)
Gruss
rega
Reply
#2
Hm, das sollte normalerweise nicht passieren, aber vor jedem Zugriff auf die Datenbank wird eine "Test-StoredProc" aufgerufen um die Konnektivität zu prüfen - kommt die Antwort nicht innerhalb von 15sek, schaltet ASGRD in den Offline-Modus.

Wie man das nun in Ihrem Fall unterbinden kann - gute Frage - man könnte einen höheren Timeout setzen, ich vermute aber eher kurzfristige Netzwerk-Störungen als Ursache - aber genau lässt sich das so nicht sagen...
Regards/Gruss
Oliver
Reply
#3
Erstmals danke für die Antwort!

Denn Keep Alive Timeout bei den Netzwerkeinstellungen der SQL Server Network Configuration der  DB habe ich bereits von 30000 auf 50000 erhöht.
Dies hat leider nichts gebracht. 

Wo genau würden Sie den Timeout höher setzen?
Gruss
rega
Reply
#4
Beim Login (wenn noch keine Verbindung zur Datenbank aktiv ist) kann man die "Umgebung" bearbeiten - dort gibt es eine Checkbox "Erweiterte Einstellungen" - und dann erscheint als eine Option "Timeout".

Das Problem ist das es damit vielleicht einfach nur noch schlimmer wird - also anstatt nach 15sek die Nachricht, erst nach 30sek (das die DB nicht erreichbar ist) - ich bin auch kein Netzwerk-Experte, aber ich denke es wäre wichtiger nach der Ursache zu suchen - und ein Timeout kann nun mal nur auftauchen, wenn bei der Kommunikation mit der DB keine Antwort kommt, daher tippe ich auf Netzwerk-Probleme?!?
Regards/Gruss
Oliver
Reply
#5
Danke!

Ich habe die Erreichbarkeit per Ping bereits getestet. Der Server war während eines Unterbruchs durchgehend erreichbar.
Ping ist evtl. nicht ausreichend... Ich werde das Ganze noch umfassender testen und auch die verschiedenen Ports mit einbeziehen!

Schönen Tag und Grüsse
rega
Gruss
rega
Reply
#6
Guten Tag

Ich vermute Sie haben dasselbe Problem wie wir:
http://forum.asg-rd.com/showthread.php?tid=10557

Bei uns besteht das Problem weiterhin.

Freundliche Grüsse,
Claudio
Reply
#7
In der nächsten Version wird protokolliert welches Kommando ausgeführt wird, wenn die DB nicht erreichbar ist - vielleicht können wir dem Problem damit etwas näher kommen.,..
Regards/Gruss
Oliver
Reply
#8
Guten Tag Claudio

Danke für den Input.
Den Beitrag habe ich bereits gesehen und bin auch alle Punkte durchgegangen, leider hat auch bei mir keiner der Lösungsansätze etwas gebracht.
Bei uns traten diese Probleme erst auf, als wir von der 2012 auf die 2017 Version aktualisiert haben und auf SQL Server Express 2017 wechselten.

Hoffe nun, dass ich einen Fehler über die Überwachung des Ports 1433 finde...

Gruss 
rega
Gruss
rega
Reply
#9
Hallo Oliver

Wann wird die nächste Version voraussichtlich erscheinen?

Gruss
rega
Gruss
rega
Reply
#10
Wir setzen aktuell SQL Server 2016 wSP1 ein.

Wäre Spannend wenn du etwas findest im Trace. :-)

Gruss
Claudio
Reply
#11
(19-01-2018, 12:26 PM)claudio Wrote: Wir setzen aktuell SQL Server 2016 wSP1 ein.

Wäre Spannend wenn du etwas findest im Trace. :-)

Gruss
Claudio

Es ist definitiv kein Netzwerkproblem. Ich habe den Port 1433 im  Sekundentakt überwacht, in dem ich eine Verbindung aufbaute und diese wieder schloss.
Während der Fehler auftrat, war der Server über den Port erreichbar. Die Überwachung des Ports lief über den gleichen Terminalserver, auf welchem der betroffene Benutzer angemeldet war.
Gruss
rega
Reply
#12
(19-01-2018, 05:33 PM)rega Wrote:
(19-01-2018, 12:26 PM)claudio Wrote: Wir setzen aktuell SQL Server 2016 wSP1 ein.

Wäre Spannend wenn du etwas findest im Trace. :-)

Gruss
Claudio

Es ist definitiv kein Netzwerkproblem. Ich habe den Port 1433 im  Sekundentakt überwacht, in dem ich eine Verbindung aufbaute und diese wieder schloss.
Während der Fehler auftrat, war der Server über den Port erreichbar. Die Überwachung des Ports lief über den gleichen Terminalserver, auf welchem der betroffene Benutzer angemeldet war.

Das kann ich grundsätzlich bestätigen. Bei uns nutzen 20 Benutzer ASG - die Probleme treten unregelmässig auf bei allen Benutzern auf. Keiner hat je Probleme mit anderen Applikationen gemeldet, die in derselben SQL Instanz laufen. Nur ASG geht unregelmässig "Offline". Übrigens, so gut wie immer ist es sofort möglich, erneuert online zu gehen.
Reply
#13
Hm, also "erste Hilfe" wäre eine Option die es erlaubt bevor man überhaupt in den Offline-Modus wechselt, nochmal zu versuchen auf die Datenbank drauf zu kommen - das würde ich mal für den nächsten Patch vorsehen - und vielleicht bekommen wir mit der heute veröffentlichten Version 2018 auch neue Erkenntnisse bei welchem Kommando der Fehler auftaucht?!?
Regards/Gruss
Oliver
Reply
#14
(22-01-2018, 02:14 PM)DevOma Wrote: Hm, also "erste Hilfe" wäre eine Option die es erlaubt bevor man überhaupt in den Offline-Modus wechselt, nochmal zu versuchen auf die Datenbank drauf zu kommen - das würde ich mal für den nächsten Patch vorsehen - und vielleicht bekommen wir mit der heute veröffentlichten Version 2018 auch neue Erkenntnisse bei welchem Kommando der Fehler auftaucht?!?

Ja, eine auto-reconnect Option ohne User-Interaktion würde ich begrüssen. Wenn wir dies über die Optionen steuern können, z.b. Anzahl auto-reconnect versuche, wäre gut. Auch scheint hier ein Timeout zu existieren, von ca. 5 Sekunden, währenddessen ASG einfriert. Wenn wir das Timeout auch in den Optionen einstellen könnten, wäre super.

Wir werden auf 2018 aktualisieren. Wo sollte das Log geschrieben werden, falls ein Problem auftaucht? Event Log / Log File / ASG DB?

Danke und Gruss
Claudio
Reply
#15
In Version 2018 steht im Dialog der zum Offline-Modus führt, bei welchem Kommando der Timeout auftrat...
Regards/Gruss
Oliver
Reply
#16
(23-01-2018, 08:03 AM)DevOma Wrote: In Version 2018 steht im Dialog der zum Offline-Modus führt, bei welchem Kommando der Timeout auftrat...

Meinen Sie dieses Fenster?

.png   Fehler-1-2018.png (Size: 14.07 KB / Downloads: 7)

Oder wird das betroffene Kommando in einem anderen Dialog erläutert?
Gruss
rega
Reply
#17
Hm ja, aber der Text scheint zu lang zu sein - wird abgeschnitten - im englischen war da noch eine Zeile zu sehen - hab den Text aber auch schon verkürzt für die nächste Version, dafür noch eine technische Fehlermeldung dazu gepackt...
Regards/Gruss
Oliver
Reply
#18
Hallo zusammen

Wir haben nun ASG 2018 bei diversen Usern ausgerollt. Ein erstes Feedback unten im Screenshot:
[Image: attachment.php?aid=3423]

Gruss Claudio


Attached Files
.png   asg-error1.png (Size: 10.18 KB / Downloads: 103)
Reply
#19
Ok danke
Regards/Gruss
Oliver
Reply
#20
Eigentlich sollte während der Laufzeit diese Funktion gar nicht mehr aufgerufen werden - da die Daten gecacht werden - ich suche mal woran das liegen könnte...
Regards/Gruss
Oliver
Reply




Users browsing this thread: 1 Guest(s)