MS SQL 2005 - clients verlieren verbindung nach 10 stunden

[lordpeng]

>naja, wie unterscheidet sich die "zertifizierte" hardware des software-herstellers gegenüber den von dir gelieferten
>komponenten (sodass sie dir eine zusammenarbeit zwecks problemfindung verweigern)?

server: hp proliant ml350g5 server (steht schon seit ewigkeiten dort)
clients: sind hp deskpro's bzw. lenovo thinkcentre

also ganz die billgste schrott-hw halt *ggg*

die softwarefirma würd vermutlich irgendwelche x-beliebigen nonames mit der grössten gewinnspanne hinstellen und gut is ...

[radditz]

Spuckt denn die Applikation selbst irgendeine Fehlermeldung aus?
Oder kommt da einfach ein nettes Problembericht senden?

Normalerweise spuckt der ODBC Treiber nämlich eine Meldung ala "Error xyz", wobei xyz irgendeine zahl is, aus, und das lässt sich dann ganz leicht reproduzieren bzw. warten.

übrigens finde ich es ziemlich fahrlässig eine DB-Verbindung mehr als 10 Stunden offen zu lassen...
Das lädt ja Hacker ein, belastet die DB und Netzwerkkomponenten unnötig.


Gut programmierte Software ignoriert übrigens so einen Disconnect und Reconnected automatisch

[lordpeng]

>Spuckt denn die Applikation selbst irgendeine Fehlermeldung aus?
>Oder kommt da einfach ein nettes Problembericht senden?
nein, es kommt ein 'Allgemeiner Netzwerkfehler Connection Write (WrapperWrite())' seitens des ODBC treibers, gefolgt von einem 'Kommunikationsverbindungsfehler', die anwendung selber verabschiedet sich dann mit einem klassischem hänger, so dass sie per taskmanager geschlossen werden muss

>Normalerweise spuckt der ODBC Treiber nämlich eine Meldung ala "Error xyz", wobei xyz irgendeine zahl is, aus,
siehe oben

>und das lässt sich dann ganz leicht reproduzieren bzw. warten.
sag das dem software-hersteller ...

>übrigens finde ich es ziemlich fahrlässig eine DB-Verbindung mehr als 10 Stunden offen zu lassen...
>Das lädt ja Hacker ein, belastet die DB und Netzwerkkomponenten unnötig.
ob die einzelnen verbindungen wirklich 10 stunden offen sind, kann ich ned beurteilen, denk ich aber ned, zumal der sql server ja standardmässig eine autoclose funktion aktiviert hat ...

>Gut programmierte Software ignoriert übrigens so einen Disconnect und Reconnected automatisch
tja - gut programmierte software, wie du sagst ...

[zigan]

haben die clients den dns server des AD als ersten server eingetragen?

einfach mal /dnsflush durchführen, dann testen ob die verbindung noch geht...

zweite möglichkeit nochmals das kerberos default timeout
der server schickt ein connection denied, die clients suchen normalerweise um ein neues ticket an, und alles geht
tut das diese "netzwerkapplikation" auch?

die einstellung ist in den domain policies zu ändern, testweise auf 12 stunden, und wenns dann nach 12 stunden passiert, ists wirklich das timeout

ach ja und xp verhält sich in vielen dingen völlig anders als w2k oder gar nt4,.....je nach servicepack sogar anders, (alle änderungen stehen eh bei den sps genau beschrieben .. )

[lordpeng]

>haben die clients den dns server des AD als ersten server eingetragen?
ja

>einfach mal /dnsflush durchführen, dann testen ob die verbindung noch geht...
das ist in der tat einen versuch wert ...

>und wenns dann nach 12 stunden passiert, ists wirklich das timeout
auch wenn ich's für eher unwahrscheinlich halte, ich werds auf jedenfall probieren (wie so vieles andere auch, dass ich inzwischen probiert hab)

>ach ja und xp verhält sich in vielen dingen völlig anders als w2k oder gar nt4
ja leider, traurig ist nur, dass es sich um ein 08/15 netz mit 5 clients handelt, wie ich sie schon zig-fach eingerichtet hab - und das eigentlich immer nach dem selben schema ...

[radditz]

Möglicherweise hilft dir das hier:
http://support.microsoft.com/?scid=kb%3 ... &x=15&y=13


Soweit ich das sehe, tritt der Fehler beim Connecten auf.

Meine Theorie ist folgende:
Die Datenbankverbindung ist nicht persistent. Der Client verbindet sich on demand zum Server.
Nach 10 Stunden passiert im Hintergrund irgendwas, so dass der Hostname nicht aufgelöst werden kann (oder ähnlich).
Der Client möchte connecten, klappt aber nicht, weil kein Hostname (daher auch die Meldung "Kommunikationsverbindungsfehler").

Vermutlich dürfte ein manuelles löschen des DNS-Cachesauch nicht viel ändern, weil das den Client quasi resettet.
Allerdings _könnte_ das eintragen der IP-Adresse anstatt des Hosts in der Software auf den Clients das Problem beheben.


Wie wird die ODBC-Verbindung eigtl. hergestellt? Wird dazu "oldschool" in der Systemsteuerung eine neue ODBC-Verbindung eingetragen, oder spielt sich die Konfiguration dieser alleine in der Software ab?

[lordpeng]

>Vermutlich dürfte ein manuelles löschen des DNS-Cachesauch nicht viel ändern, weil das den Client quasi resettet.
das problem würds wohl nicht lösen, aber zumindest würde es das problem hervor rufen, so dass man es möglicherweise wirklich darauf eingrenzen könnte ...

>Allerdings _könnte_ das eintragen der IP-Adresse anstatt des Hosts in der Software auf den Clients das Problem beheben.
werd ich nach möglichkeit heute testen ...

>Wie wird die ODBC-Verbindung eigtl. hergestellt? Wird dazu "oldschool" in der Systemsteuerung eine neue
>ODBC-Verbindung eingetragen
in der systemsteuerung, wobei es keine rolle spielt, ob named pipes oder tcp/ip verwendet wird

auf jedenfall vorerst mal danke für eure bisherigen antworten

[radditz]

gibts denn schon news?

[lordpeng]

NOCH nicht, allerdings hab ich gestern abend das kerberos timeout erhöht, obs was bringt wird sich zeigen ...
ein manuelles löschen des dns cache löst das problem jedenfalls nicht aus

[lordpeng]

so wie's aussieht scheints doch am kerberos timeout gelegen zu haben - allerdings wars seit der umstellung des timeout erst 1x dass die produktiv- rechner > 10std. gelaufen sind, d.h. ist das ergebnis für mich noch nicht zu 100 % fix, d.h. ich werds in den nächsten tagen mal beobachten und mich dann nochmals melden

auf jedenfall danke für alle die mir tipps gegeben haben ... und ein besonderes danke natürlich an zigan (bierkiste steht, wennst amal in die obersteiermark kommen solltest)

[lordpeng]

UPDATE: so wie's aussieht hat es wirklich am kerberos timeout in verbindung mit der zum einsatz kommenden version vom ms sql 2005 gelegen (ist die 2005sp2)

eine erhöhung des kerberos timeouts auf 14 stunden brachten den erhofften erfolg - vermutlich hätte aber ein update auf sql2005sp3 oder sql2008 ebenso den selben erfolg gebracht, aber einen sql server der ned von mir installiert wurde, den greif ich ned an ...

[zigan]

danke für das update