Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Verbindungsunterbruch zur Datenbank
#21
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...
Regards/Gruss
Oliver
Reply
#22
Der Data Optimizer hat einige Objekte gefunden, siehe unten. Wir beobachten ob nach der Optimierung das Problem weiterhin auftaucht.

[Image: attachment.php?aid=3424]

[Image: attachment.php?aid=3425]

[Image: attachment.php?aid=3426]

[Image: attachment.php?aid=3427]


Attached Files Thumbnail(s)
               
Reply
#23
(24-01-2018, 12:55 PM)DevOma Wrote: 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!
Gruss
rega
Reply
#24
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
Reply
#25
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.


Attached Files Thumbnail(s)
   
Gruss
rega
Reply
#26
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?
Reply
#27
(31-01-2018, 01:15 AM)claudio Wrote: 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.
Gruss
rega
Reply
#28
(31-01-2018, 10:12 AM)rega Wrote:
(31-01-2018, 01:15 AM)claudio Wrote: 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...
Reply
#29
(31-01-2018, 11:37 AM)claudio Wrote:
(31-01-2018, 10:12 AM)rega Wrote:
(31-01-2018, 01:15 AM)claudio Wrote: 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.
Gruss
rega
Reply
#30
(31-01-2018, 11:56 AM)rega Wrote:
(31-01-2018, 11:37 AM)claudio Wrote:
(31-01-2018, 10:12 AM)rega Wrote:
(31-01-2018, 01:15 AM)claudio Wrote: 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.
Reply
#31
(31-01-2018, 12:02 PM)claudio Wrote:
(31-01-2018, 11:56 AM)rega Wrote:
(31-01-2018, 11:37 AM)claudio Wrote:
(31-01-2018, 10:12 AM)rega Wrote:
(31-01-2018, 01:15 AM)claudio Wrote: 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...
Gruss
rega
Reply
#32
Das hört sich sehr interessant an - und könnte eine Erklärung für das Unerklärliche sein :-) Ich werde dem mal nachgehen...
Regards/Gruss
Oliver
Reply
#33
Hier ein paar Hinweise seitens MS um solche Probleme zu verhindern:

https://social.msdn.microsoft.com/Forums...baseengine
Regards/Gruss
Oliver
Reply
#34
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.
Gruss
rega
Reply
#35
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...
Regards/Gruss
Oliver
Reply
#36
(01-02-2018, 11:42 AM)DevOma Wrote: 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?
Gruss
rega
Reply
#37
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...
Regards/Gruss
Oliver
Reply
#38
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
Reply
#39
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).


Attached Files Thumbnail(s)
       
Gruss
rega
Reply
#40
Ich versuche mich mal Schlau zu machen, ob man dem SQL-Protokoll mitgeben kann wie er sich mit dem SQL Server verbinden soll
Regards/Gruss
Oliver
Reply




Users browsing this thread: 1 Guest(s)