Jump to content

Hyper-V - Branchensoftware verliert Kontakt zu SQL Server


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen

 

erstmal wieder vielen Dank für die vielen Tipps und Anregungen ...

 

Vorab zu den Fragen:

 

- Dual Xeon 6Core mit HT - also 12 Phys. und 24 Virt. Kerne

- 39 User wobei maximal in 15 Sessons gleichzeitig "Last entsteht" - der Rest ist zwar offen aber dümpelt eher rum ...

 

Den Datev Artikel finde ich sehr interessant - ich werde mal hier ansetzten und wie im Artikel vorgehen - mal sehen was sich tut ...

 

Seltsam ist auch dass das laut der Firebird Protokolle oft auch Nachts passiert wo zwar die Sitzungen noch offen sind aber nicht connected - direkten STress kann die Maschine  hier eigentlich nicht  haben ...

Link zu diesem Kommentar

Hallo zusammen

 

das abarbeiten des DATEV ARtikels hat leider nicht geholfen - heute Nacht - irgendwann in den Morgenstunden wieder Connection Shutdown am FB Server. (HASSS)

 

Auch eine neue Erfahrung:

 

Nicht immer wenn das passiert wird ein Log-Eintrag in der FirebirdLOG auf dem Server gesetzt

 

So ist der letzte Eintrag von gestern Abend 17.07 uhr:

W2012HVHOST	Fri Sep 02 17:07:23 2016
	INET/inet_error: read errno = 10054


W2012HVHOST	Fri Sep 02 17:07:23 2016
	Unable to complete network request to host "W2012HVHOST".
	Error reading data from the connection.

Da war ich aber definitiv im System und da waren auf Client Seite keine Fehlermeldungen.

 

Laut Windows Logfiles sind die Anwendungen heute morgen um ca. 6 Uhr abgeschmiert (client anwendungen)

 

 

Nachtrag: die Connection Fail´s betreffen auch den ODBC Treiber auf den Clients. Dieser ist ja von Firebird und ist auf 2003R2 ebenfalls stabil gelaufen - auch hier die Meldung "connection sutdown"..

bearbeitet von GTRDRIVER
Link zu diesem Kommentar

Hallo,

https://www.google.de/search?q=error+reading+data+from+the+connection&ie=utf-8&oe=utf-8&client=firefox-b&gfe_rd=cr&ei=baLKV6nlOYir8we6tJnQCg

sucht ein mensch nach "error reading data from the connection" ist mind. die erste seite in 2 suchmaschinen exklusiv für firebird reserviert (ohne das firebird im suchbegriff auftaucht)

ich bin, wie wohl ersichtlich, kein experte für firebird und application debugging, fand das thema jedoch interessant und schrieb daher etwas.

aus allgemeiner erfahrung finde ich 2012 und 2008 server stabiler als 2003 und bezweifle eher das diese fehler am server selbst liegen.

kann aber auch nicht mehr dazu sagen als das was in den suchergebnissen steht, connection pooling im firebird deaktivieren, evtl. den firebird server als 2003er in der vm laufen lassen.

welche firebird version ist im einsatz?

ich wuerde den druck an den hersteller durchreichen. wenn das nicht möglich ist würde ich 100% arbeitszeit in das debuggen/analysieren stecken bis ich genug zusammen haette den hersteller auf kleiner flamme zu roesten.

Dieses Fehlerbild mit 40 ok-fenstern, das war vor 20 Jahren mal ne sensation, sowas hab ich seit bestimmt 10+ Jahren nicht mehr live gesehen und im endusersupport hab ich wirklich viel gesehen.

mal eine Zeitschiene dokumentieren was wann wo geloggt wird. Versuchen herauszufinden ob und welche Funktion hier evtl. Probleme macht.

der hersteller hat (hoffentlich schriftlich) bestätigt das die klamotte läuft.

es gibt so viele links zu problemen mit firebird (seit jahren), das reicht für 1 bis 2 wochen nur lesen und sammeln von infos, da wird sich was finden lassen.

wobei mich erschreckt, wie schnell in den links die problemlösung in echtes debugging der funktionsaufrufe der applikation abdriften. Sowas macht normalerweise ein Hersteller und nicht ein Serveradmin.

wir hatten hier vor ein paar jahren probleme mit oracle treibern auf clients welche die connection ganz grob umschrieben aehnlich zusammenbrechen liessen (random immer mal wieder)

geholfen hat der umstieg auf oracle fat client auf dem applikationsserver.

Nach alternativen treibern auf dem TS suchen?

Wie du es beschreibst sind es evtl. mehrere unterschiedliche Fehler.

Es ist ein bisschen unglücklich von 2003 auf 2012 zu springen und dann gezwungen zu sein den Fehler bei Microsoft suchen zu muessen. Nicht das Microsoft keine Fehler macht, Firebird scheint jedoch mehr Bugs zu haben als Server 2012. Firebird hatte diesse Fehlermeldung auch schon vor 2012.

 

Ich schliesse mal mit dem Kommentar von der Firebird-FAQ:

"

Statement failed, SQLCODE = -902 Error reading data from the connection.

This error shows up when you lost connection to the Firebird server. Common causes are:

a) someone rebooted or restarted the server
B) Firebird server crashed

If this shows up repeatedly with some particular query, try with latest Firebird version. If the problem still occurs, contact the developers, as it it most probably a bug in Firebird.

"

wobei firebird server hier eine Instanz meint.

furl.png  delicious.png  co.mments.gif  digg.png  yahoomyweb.png
bearbeitet von Jim di Griz
Link zu diesem Kommentar

 

Das ganze passiert wie gesagt unregelmäßig und kann auch nicht auf Host1 oder Host2 eingegrenzt werden. Mal 1x am Tag - mal 5x am Tag - mal 4 Tage garnicht ...

 

Moin,

 

ich, der alte Mann, erzähle mal einen vom Kriege. :)

 

Die betroffene Umgebeung, sie besteht mehrheitlich aus IGEL-Terminals, ein Routing zum Higher Headquarter, von dort weiter zu einem Rechenzentrum mit der Virtuellen Desktop Infrastruktur. Neben den IGEL auch drei W10 Clients.

 

Neulich, mal wieder, alle IGEL und VDI krochen, für eine einfache Tabelle wurden Stunden benötigt. Oftmals war auch ein Anmelden nicht möglich.

 

Was war es? Ein W10 machte automatische Updates, überlastete dadurch einen Proxy im Dunstkreis des HH.

 

Die Ursache einer Malaise kann also an ganz etwas anderem liegen als vorgestellt. Es muss mit einem Vorher/Nachher nichts zu tun haben, nicht primär. Aber das der W10 Updates machte, eine Nachlässigkeit beim Upgrade von W8 auf W10.

bearbeitet von lefg
Link zu diesem Kommentar

@Sunny

 

Macht nix, denn er verschiebt IMO nur die VM von Host1 auf Host2 und retour um den Host auszuschließen.

 

 

Neue Konstellation:

 

- 2 Hardware Hosts (identsiche Hardware) mit jeweils Server 2012R2 und Hyper-V

- Host1: VM1 RDS Server 1 und VM2 Datei/Datenbankserver

- Host2: VM1 RDS Server 2 und VM2 RDS Server für Buchhaltung (hat jetzt mit dem Rest nix zu tun)

Link zu diesem Kommentar

ich habe heute vom Software Hersteller eine interessante E-Mail bekommen - nachdem man meinen Fall offenbar eingehender geprüft hat.

 

Empfehlung: TS Sessions "über Nacht automatisch abmelden"

Na super! Falls die User Probleme mit der Abmeldung und dem schließen über das Kreuz haben, am besten den TS einmal in der Nacht neu starten. ;)

Link zu diesem Kommentar

Ergänzung: Wenn ein User eine Datei offen hat (Excel Word etc..) und ich ihm die Session abmelde wird er sicher hoch begeistert sein ...

Wenn sowas kommuniziert wurde und von entsprechenden Stellen abgesegnet ist: Wer nicht hören will, muss fühlen ;)

 

Je nach Applikation(en) booten wir die Terminalserver / XenApp Server bei unseren Kunden wöchentlich bis täglich durch. Das ist(?) (bzw. war) sogar Best Practice von Citrix.
Link zu diesem Kommentar

Ach ja - das War Vorschlag Nr.2:  Den Firebird Server 2x pro tag per Script neu starten ....

Zweimal finde ich hart. Aber die Aussage einen Server täglich neu zu starten kenne ich auch. Die kommt immer dann, wenn der Hersteller der SW nicht mehr weiter weiß. Und heutzutage passiert das leider recht schnell.

 

Ergänzung: Wenn ein User eine Datei offen hat (Excel Word etc..) und ich ihm die Session abmelde wird er sicher hoch begeistert sein ...

Das ist natürlich auch Erziehung und Dokumentation. Den Usern erklären worin der Unterschied besteht und darauf hinweisen. Was haben die User lieber? Täglich Connect Fehler oder mal ein Word Dokument verloren?

Link zu diesem Kommentar

Hallo 

 

zu dem "offenen Dokumenten" - ja - das sehe ich auch so - dann müsste man das kommunizieren ...

 

Das andere ist für mich schlichtweg nur traurig - auch wenn es von Herstellern als Best Pract.. beschrieben wird - ich betreue hier im Geschäftliche Umfeld und auch privat diverse Linux Server die dank USV teilweise eine Uptime von >1 Jahr haben... - aber ich weiß - der Vergleich hinkt ...

 

Dennoch - irgendwie Traurig dass das im Jahre 2016 noch immer so ist ...

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...