Verbindungsunterbruch zur Datenbank

[DevOma]

Wurde der Data Optimizer mal aufgerufen? Der sucht nach bestimmten Kriterien "Leichen" in der DB - mir scheinen da Items vorhanden zu sein, die ungültige Daten beinhalten - denn es wird nur ein DB-Zugriff gemacht, wenn das Objekt nicht im Cache gefunden wird...

[claudio]

Der Data Optimizer hat einige Objekte gefunden, siehe unten. Wir beobachten ob nach der Optimierung das Problem weiterhin auftaucht.

[rega]

Wurde der Data Optimizer mal aufgerufen? Der sucht nach bestimmten Kriterien "Leichen" in der DB - mir scheinen da Items vorhanden zu sein, die ungültige Daten beinhalten - denn es wird nur ein DB-Zugriff gemacht, wenn das Objekt nicht im Cache gefunden wird...

Der Data Optimizer fand über 415 Objekte! Ich werde ebenfalls kontrollieren, ob das Problem erneut auftritt. Danke!

[claudio]

Der Dataoptimzer hat leider bei uns keinen Erfolg gebracht. Die Probleme treten weiterhin auf.

In den Fehlermeldungen sind jeweils die Methoden LogItemAdd oder BaseItemGet aufgeführt.

Gruss Claudio

[rega]

Bei uns kommt es ebenfalls weiterhin zu Unterbrüchen, siehe Anhang.
Ich habe den Data Optimizer zur Kontrolle erneut durchlaufen lassen, erhielt aber keine "fehlerhaften" Einträge zur Korrektur.

[claudio]

Es scheint also nicht auf eine Funktion rückführbar zu sein, das Problem tritt bei diversen Methoden auf: LogItemAdd, BaseItemGet, LogsGet

Etwas zusätzliche Debug Infos wie Stack Trace o.ä. wäre interessant.

@rega: Konntet Ihr das Problem bisher irgendwie zuverlässig reproduzieren?

[rega]

Es scheint also nicht auf eine Funktion rückführbar zu sein, das Problem tritt bei diversen Methoden auf: LogItemAdd, BaseItemGet, LogsGet

Etwas zusätzliche Debug Infos wie Stack Trace o.ä. wäre interessant.

@rega: Konntet Ihr das Problem bisher irgendwie zuverlässig reproduzieren?

Nein leider nicht, das Problem tritt willkürlich auf. 
Es kann sein, dass Remote Desktop bereits beim ersten Mal starten des Benutzers abstürzt. Aber auch wenn man darin arbeitet und eine weitere Verbindung öffnen möchte oder zwischen zwei bestehenden Verbindungen wechselt.
Wenn man das Programm länger nicht gebraucht hat und es wieder öffnet, stürzt es manchmal auch ab.

Bitte beachten, es gibt weder einen zeitlichen noch Aktion bedingten Zusammenhang. Ich konnte auch schon zwei Tage ohne Unterbrüche arbeiten.

[claudio]

Es scheint also nicht auf eine Funktion rückführbar zu sein, das Problem tritt bei diversen Methoden auf: LogItemAdd, BaseItemGet, LogsGet

Etwas zusätzliche Debug Infos wie Stack Trace o.ä. wäre interessant.

@rega: Konntet Ihr das Problem bisher irgendwie zuverlässig reproduzieren?

Nein leider nicht, das Problem tritt willkürlich auf. 
Es kann sein, dass Remote Desktop bereits beim ersten Mal starten des Benutzers abstürzt. Aber auch wenn man darin arbeitet und eine weitere Verbindung öffnen möchte oder zwischen zwei bestehenden Verbindungen wechselt.
Wenn man das Programm länger nicht gebraucht hat und es wieder öffnet, stürzt es manchmal auch ab.

Bitte beachten, es gibt weder einen zeitlichen noch Aktion bedingten Zusammenhang. Ich konnte auch schon zwei Tage ohne Unterbrüche arbeiten.

Das entspricht auch unseren Beobachtungen. Haben Sie zufällig IPv6 in Ihrem Netzwerk aktiv? Dies ist bei uns der Fall...

[rega]

Es scheint also nicht auf eine Funktion rückführbar zu sein, das Problem tritt bei diversen Methoden auf: LogItemAdd, BaseItemGet, LogsGet

Etwas zusätzliche Debug Infos wie Stack Trace o.ä. wäre interessant.

@rega: Konntet Ihr das Problem bisher irgendwie zuverlässig reproduzieren?

Nein leider nicht, das Problem tritt willkürlich auf. 
Es kann sein, dass Remote Desktop bereits beim ersten Mal starten des Benutzers abstürzt. Aber auch wenn man darin arbeitet und eine weitere Verbindung öffnen möchte oder zwischen zwei bestehenden Verbindungen wechselt.
Wenn man das Programm länger nicht gebraucht hat und es wieder öffnet, stürzt es manchmal auch ab.

Bitte beachten, es gibt weder einen zeitlichen noch Aktion bedingten Zusammenhang. Ich konnte auch schon zwei Tage ohne Unterbrüche arbeiten.

Das entspricht auch unseren Beobachtungen. Haben Sie zufällig IPv6 in Ihrem Netzwerk aktiv? Dies ist bei uns der Fall...

Ja, auch wir haben IPv6 in unserem Netzwerk aktiv. Ich werde dies aber nun zum Test deaktivieren.

[claudio]

Es scheint also nicht auf eine Funktion rückführbar zu sein, das Problem tritt bei diversen Methoden auf: LogItemAdd, BaseItemGet, LogsGet

Etwas zusätzliche Debug Infos wie Stack Trace o.ä. wäre interessant.

@rega: Konntet Ihr das Problem bisher irgendwie zuverlässig reproduzieren?

Nein leider nicht, das Problem tritt willkürlich auf. 
Es kann sein, dass Remote Desktop bereits beim ersten Mal starten des Benutzers abstürzt. Aber auch wenn man darin arbeitet und eine weitere Verbindung öffnen möchte oder zwischen zwei bestehenden Verbindungen wechselt.
Wenn man das Programm länger nicht gebraucht hat und es wieder öffnet, stürzt es manchmal auch ab.

Bitte beachten, es gibt weder einen zeitlichen noch Aktion bedingten Zusammenhang. Ich konnte auch schon zwei Tage ohne Unterbrüche arbeiten.

Das entspricht auch unseren Beobachtungen. Haben Sie zufällig IPv6 in Ihrem Netzwerk aktiv? Dies ist bei uns der Fall...

Ja, auch wir haben IPv6 in unserem Netzwerk aktiv. Ich werde dies aber nun zum Test deaktivieren.

War haben nicht IPv6 deaktiviert, sondern auf dem SQL Server festgelegt, dass er nur noch auf seiner primären IPv4 Adresse und Port 1433 verbunden werden kann. Denn was wir im Process Monitor Trace feststellen konnten ist, dass die Verbindungen zum MSSQL ein Mix zwischen IPv4 über IPv6 ist.

[rega]

Es scheint also nicht auf eine Funktion rückführbar zu sein, das Problem tritt bei diversen Methoden auf: LogItemAdd, BaseItemGet, LogsGet

Etwas zusätzliche Debug Infos wie Stack Trace o.ä. wäre interessant.

@rega: Konntet Ihr das Problem bisher irgendwie zuverlässig reproduzieren?

Nein leider nicht, das Problem tritt willkürlich auf. 
Es kann sein, dass Remote Desktop bereits beim ersten Mal starten des Benutzers abstürzt. Aber auch wenn man darin arbeitet und eine weitere Verbindung öffnen möchte oder zwischen zwei bestehenden Verbindungen wechselt.
Wenn man das Programm länger nicht gebraucht hat und es wieder öffnet, stürzt es manchmal auch ab.

Bitte beachten, es gibt weder einen zeitlichen noch Aktion bedingten Zusammenhang. Ich konnte auch schon zwei Tage ohne Unterbrüche arbeiten.

Das entspricht auch unseren Beobachtungen. Haben Sie zufällig IPv6 in Ihrem Netzwerk aktiv? Dies ist bei uns der Fall...

Ja, auch wir haben IPv6 in unserem Netzwerk aktiv. Ich werde dies aber nun zum Test deaktivieren.

War haben nicht IPv6 deaktiviert, sondern auf dem SQL Server festgelegt, dass er nur noch auf seiner primären IPv4 Adresse und Port 1433 verbunden werden kann. Denn was wir im Process Monitor Trace feststellen konnten ist, dass die Verbindungen zum MSSQL ein Mix zwischen IPv4 über IPv6 ist.

Ich hatte IPv6 in der Network Configuration auf dem SQL bereits deaktiviert, bemerkte aber nun, dass Listen All noch aktiviert war...

[DevOma]

Das hört sich sehr interessant an - und könnte eine Erklärung für das Unerklärliche sein :-) Ich werde dem mal nachgehen...

[DevOma]

Hier ein paar Hinweise seitens MS um solche Probleme zu verhindern:

https://social.msdn.microsoft.com/Forums...baseengine

[rega]

Ich muss leider enttäuschen, habe gestern IPv6 auf den Terminalservern und auf dem SQL Server deaktiviert, auch in den SQL Network Settings.
Heute hat sich wieder ein Benutzer bei mir gemeldet, bei Ihm kam es zu einem Verbindungsunterbruch beim Befehl LogItemAdd.

[DevOma]

Wie gross sind die Logs? Werden diese automatisch gelöscht über die Einstellungen? Wir haben immer mal wieder Fälle wo es 100.000de Log-Einträge gibt...

Ich überlege noch wie und wo man noch etwas loggen könnte...

[rega]

Wie gross sind die Logs? Werden diese automatisch gelöscht über die Einstellungen? Wir haben immer mal wieder Fälle wo es 100.000de Log-Einträge gibt...

Ich überlege noch wie und wo man noch etwas loggen könnte...

Die Logs werden automatisch nach 30 Tagen gelöscht, zusätzlich ist eine Limite von 500 Einträgen definiert.
Die momentane gesamt Grösse der Logs liegt unter 10 MB

Macht es Sinn die Berechtigungen Connect, Execute und Select explizit auf der DB zu definieren, obwohl die Berechtigungen dbowner bereits gesetzt ist?

[DevOma]

Das macht dann keinen Unterschied - und sonst dürfte es ja überhaupt nicht funktionieren...
Mein Problem momentan ist - es wird ein StoredProc aufgerufen (ConnectionTest) - wenn dies nicht funktioniert, dann kommt die Option zum Wechsel in den Offline-Mode - da es aber sporadisch nicht möglich ist, muss irgendwas an der Verbindung zur Datenbank netzwerktechnisch zu diesem Problem führen - nur was? Das eigentliche SQL-Kommando wird immer erst danach abgesetzt - wenn es dabei zu einem Fehler kommt, ist zumindest kein Wechsel mehr möglich und es wird zu einem Fehler kommen...

[claudio]

Also ich kann bestätigten, nachdem wir am 31.01. den IPv6 Listener auf dem SQL Server deaktiviert haben (wir haben die SQL Instanz nur noch auf einer IPv4 Adresse mit Port 1433 aktiv), sind die zufälligen Disconnects verschwunden. Ich habe von allen Usern positives Feedback zurückerhalten.

Weiter Info:
- IPv6 ist ansonsten weiterhin im gesamten Netzwerk aktiv - nur die ASG SQL Kommunikation findet via IPv4 statt
- Im Netzwerk Trace konnte ich feststellen, dass ASG vor dem 31.01. ständig zwischen IPv4 und IPv6 SQL Kommunikation gewechselt hat

[rega]

Das Problem besteht bei mir leider noch immer. Die SQL-Serververbindung läuft nur über IPv4, siehe Screenshot. Die heute erhaltene Fehlermeldung, habe ich aber noch nie gesehen (PropertiesSet).

[DevOma]

Ich versuche mich mal Schlau zu machen, ob man dem SQL-Protokoll mitgeben kann wie er sich mit dem SQL Server verbinden soll