GTRDRIVER 17 Geschrieben 1. September 2016 Autor Melden Teilen Geschrieben 1. September 2016 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 ... Zitieren Link zu diesem Kommentar
GTRDRIVER 17 Geschrieben 3. September 2016 Autor Melden Teilen Geschrieben 3. September 2016 (bearbeitet) 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 3. September 2016 von GTRDRIVER Zitieren Link zu diesem Kommentar
Jim di Griz 13 Geschrieben 3. September 2016 Melden Teilen Geschrieben 3. September 2016 (bearbeitet) 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 crashedIf 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. bearbeitet 3. September 2016 von Jim di Griz Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 3. September 2016 Melden Teilen Geschrieben 3. September 2016 (bearbeitet) 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 3. September 2016 von lefg Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 5. September 2016 Melden Teilen Geschrieben 5. September 2016 Kann es denn sein, dass der Firebird Server die Connections von alleine schließt? Evtl. hilft der Ansatz bei der Suche weiter. Im MS-SQL Server kann man das einstellen, im Firebird evtl. auch. Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 5. September 2016 Melden Teilen Geschrieben 5. September 2016 @Sunny 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 ... Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 5. September 2016 Melden Teilen Geschrieben 5. September 2016 @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) Zitieren Link zu diesem Kommentar
GTRDRIVER 17 Geschrieben 5. September 2016 Autor Melden Teilen Geschrieben 5. September 2016 Hallo zusammen 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" Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 5. September 2016 Melden Teilen Geschrieben 5. September 2016 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. ;) Zitieren Link zu diesem Kommentar
GTRDRIVER 17 Geschrieben 5. September 2016 Autor Melden Teilen Geschrieben 5. September 2016 (bearbeitet) Ach ja - das War Vorschlag Nr.2: Den Firebird Server 2x pro tag per Script neu starten .... So langsam zweifle ich wirklich ... Ergänzung: Wenn ein User eine Datei offen hat (Excel Word etc..) und ich ihm die Session abmelde wird er sicher hoch begeistert sein ... bearbeitet 5. September 2016 von GTRDRIVER Zitieren Link zu diesem Kommentar
Dukel 451 Geschrieben 5. September 2016 Melden Teilen Geschrieben 5. September 2016 Gibt es alternativen zu dieser Software? Der Hersteller klingt nicht sehr kompetent und da würde ich mir einmal andere Optionen überlegen. Zitieren Link zu diesem Kommentar
testperson 1.660 Geschrieben 5. September 2016 Melden Teilen Geschrieben 5. September 2016 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. 1 Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 5. September 2016 Melden Teilen Geschrieben 5. September 2016 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? Zitieren Link zu diesem Kommentar
GTRDRIVER 17 Geschrieben 5. September 2016 Autor Melden Teilen Geschrieben 5. September 2016 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 ... Zitieren Link zu diesem Kommentar
Dominik Weber 19 Geschrieben 5. September 2016 Melden Teilen Geschrieben 5. September 2016 Wir hatten auch eine Lösung die auf Firebird lief .... 2003er Server auf Blech ... keine Probleme Sobald das Gerät virtualsiert war, gab es nur Probleme mit Firebird. Server neu auf Blech ... keine Probleme mehr .. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.