TM Konfiguration massiv zu langsam

[mfinke]

Liebe Kolleginnen, liebe Kollegen,

in dem Thema "Wechsel von TM" habe ich erfahren, dass manche kollegen nur wenige Minuten für die Abrechnung benötigen.

Wir arbeiten auf den Tag (01.04.) seit 8 JAhren mit TM.

Unsere Abrechnung bei ca. 2500 Scheinen und einer Datei mit 17500 Patienten dauert fast 1 Stunde und ich kann mich nicht erinnern, dass es 2006 viel schneller ging.

Ich habe in der Vergangenheit schon andere Praxen besucht, die nie Abstürze haben, was bei uns täglich passiert, aber dass die Abrechnung so schnell gehen kann, das kann ich nicht fassen.

Ich habe den fürterlichen Verdacht, dass bereits bei der Erstinstallation Fehler gemacht wurden, die wir heute noch ausbaden müssen.

Zur Chronologie:

März 2006: (Ich war noch nicht Praxispartner) Installation wobei Netzwerkkabel durch die ganze Praxis gespannt wurden???
3 Betriebssysteme, 4 Rechner, Server war der Rechner am Empfang, der am meisten benutzt wurde
schlechte Schulung

Juli 2007 Erweiterung zur Gemeinschaftspraxis

Feb. 2007 Stnd allone Server durch Hardwareforma installiert
Ärger mit TM, die das Serverpasswort nicht nennen wollten, obwohl nichts davon im Vertrag stand (was behauptet wurde)
Serverpasswort gegen Unterschrift dass auf Support verzichtet wird
später Rücknahme dieser Auflage

Im weiteren Verlauf permanet Druckerprobleme
schlechte Beratung bei Scannerinstallation

2009 dann Umzug der Praxis
Zusage von TM, dass Probleme mit Neuinstallation wohl weg seien
lokaler TM Partner aus Dorsten beauftragt
später festgestell, dass er nicht neu installiert hat, sondern nur Daten vom Altserver auf neuen Server kopiert

Der Supergau kam dann mit Praxis Center
1 WOche praktischer Stillstand
Im Urlaub musste ich ca. 6-8 / Tag per VPN den Server neu starten wegen Absturz durch fehlende activationmod.dll o.ä
Erst nach einer Woche Fehler durch IFAP Hotline in den Griff bekommen

Weiterhin permanent Abstürze,

Jetzt alle 11 Rechner und in der Filiale (per VPN verbunden) 2 Rechner erneuert. ... ohne Erfolg

permanet kommt die Meldung "keine Rückmeldung" und der Labordatenaufruf dauert z.B. teilweise 30 Sekunden

Die Abrechnung dauerte aber von Anfang an mindestens 30 Minuten pro Prüflauf und jetzt erfahre ich d´nach 8 Jahren, dass dies auch in 3 Minuten möglich ist.

Ich fasse es nicht.

Die Zeit und die Nerven, die mich das Programm in den letzten 8 Jahren gekostet hat sind nicht mehr gut zu machen.

Seid der Zusage im letzten Jahr vom Herr Hölscher, Verkaufsleiter, dass er sich darum kümmern will habe ich nichts mehr gehört.

Zuletzt wurde mir vor 3 Wochen ein Rückruf zugesichert..... nichts!!

Gute Nacht

Mit einem depressiven Gruß aus dem Ruhrgebiet

Markus Finke

[caesar]

...als ich vor mindestens 10 Jahren ausnahmsweise den "TM-Partner" anrief mit der Klage, dass TM immer langsamer wird, kam die Antwort: das läge daran, dass wir beim Arbeiten immer schneller werden . Das war mir dann echt zu viel und habe alles selbst in die Hand genommen (das Forum ist sehr hilfreich )--->also selbst ist der Mann oder wechseln; Hier 4 min für >1700 Scheine
Aber Laboraufruf und Diagnoseauswahl seit letzten Updates eben auch verzögert...
gruß
caesar

[TEPE]

Hallo,

ich würde mal den Server vom Netzwerk Trennen und dann die Abrechnung laufen lassen. Sollte das Problem geklärt sein, ist es mit hoher wahrscheinlichkeit das was ich denke, ein massiver Netzwerkfehler. Hervorgerufen durch defektes Kabel, falsches auflegen der Verkabelung, defektes Switch o.ä.. I


T. P.

[Meckelein]

Hallo Herr Finke,

ganz schöne Leidensgeschichte die Sie hier aufzeigen. Ich würde Ihnen raten, nicht mehr weiter an den Symptomen rum zu doktorn sondern das IT Konzept von Grund auf neu aufbauen zu lassen. Die Frage ist momentan, wollen Sie TM weiter verwenden oder steht Ihr angekündigter Wechsel auf Medical office fest?

Für beide Systeme ist ein fehlerfreies Netzwerk äusserst wichtig. Dies umfasst fehlerfreie Leitungen, sowie funktionierende Hardware. Ich gehe davon aus, dass bei Ihrem Umzug 2009 in neue Praxisräume auch eine vorhandene Verkabelung übernommen wurde. Aber es wurden damals wohl keine Switches, Router o.ä. getauscht. Ein funktionierendes 1000 MBit/s Netzwerk ist zu empfehlen. Hierzu sollten auf jeden Fall die Netzwerkkomponenten auf Aktualität geprüft werden.
Auch der Server sollte komplett auf den Prüfstand. Ihrer Beschreibung nach muss ich davon aus gehen, dass dieser noch aus 2009 stammt, zumindest finde ich keinen anderen Eintrag hierzu. Egal ob TM oder Medical office, hier sollte auf jeden Fall etwas gemacht werden.

Speziell für TM, dieses ist äusserst abhängig davon, wie das Netzwerk konfiguriert wurde. Besonderer Augenmerk sollte hierbei auf ordentlich funktionierendes DHCP, DNS, WINS und SMB liegen. Das sind mMn die Schwachpunkte an denen Turbomed immer hängt. Hier eine Empfehlung abzugeben ist schwer, da dies sehr stark von Ihrer verwendeten Hardware und den Betriebssystemen abhängt. Häufig ist es aber am besten, nochmal quasi neu anzufangen, vor allem wenn man den Server eh tauschen muss, s.o.
Turbomed hängt stark von seinen local.ini und global.ini Dateien ab. Für einen ersten Test empfehle ich immer einen neuen Client zu nehmen, auf diesem ein TM zu installieren und erstmal alles auf Grundeinstellungen zu belassen. Mit diesem kann dann weiter gespielt/gearbeitet werden.

Leider kann ich Ihnen keinen Tipp geben, mit welchem man in kürzester Zeit die Probleme lösen kann.

[kalli]

Ja, bei uns dauert die Abrechnung mit ähnlicher Scheinzahl auch nur ein paar Minuten. Vielleicht sind es nicht 3 sondern 10 Minuten im laufenden Betrieb; vielleicht 2 Minuten für das Verschlüsseln. Beides erledigt eine Helferin nebenbei wenn sie mal Zeit hat. Das Versenden der Datei mit signiertem Begleitschreiben dauert dann noch mal etwa 10min - dieses Mal Arztzeit, signieren muss ich selber mit dem Arztausweis; und ISDN ist eben langsam.

Die Abrechnung sollte vielleicht auf dem Server laufen, dann fällt ein langsames Netz nicht ins Gewicht. Die anderen geschilderten Probleme wie langsamer Laboraufruf sprechen natürlich für Netzwerkprobleme - es sei denn der Server wäre absolut unterdimensioniert. Das scheint mir jedoch unwahrscheinlich, denn hier im Forum gibt es viele Schilderungen von flott arbeitenden Systemen trotz alter und schwachbrüstiger Server...

Mich stört auch vieles am Turbomed, z.B. die langwierigen Updates auf jedem Rechner einzeln; das regeln andere Programme besser. Aber die Abrechnung hat bei uns seit fast 20 Jahren noch keine Probleme gemacht.

Frohe Ostern! - kalli

[ms-dts-ge]

Hier ist die IT-Abteilung...

Der Server wurde 2009 von der Windows-Seite her "von Null" aufgesetzt. DHCP, DNS, WINS, SMB funktioniert korrekt und ohne Probleme.
Die Leitungen sind neu (da Gebäude neu) und wurden komplett auf 1000MBit zertifiziert, es hängt momentan aber ein 100MBit-Switch dran, wobei der Server einen Gigabit-Uplink hat.
Dies wurde bisher noch nicht ausgetauscht, da das Netzwerk in den "Turbomed-hängt-Wartezeiten" keine Auslastung zeigt.

Die Abrechnung wurde z.B. gestern auf dem Server durchgeführt, somit sollte die Netzwerkgeschwindigkeit da nicht reingespielt haben.

[TEPE]

Im Urlaub musste ich ca. 6-8 / Tag per VPN den Server neu starten wegen Absturz durch fehlende activationmod.dll o.ä


Hallo,

IFAP unbedingt als Einzelplatz installieren!!!!! Der IFAP-Server hat schon immer alles zum erliegen gebracht. In diese Falle bin ich gleich 2x getappt . Unbedingt bei allen Stationen IFAP löschen mit dem Tool was dazu ist und dann Einzelplatz installieren.

Gruß
T.P.

[Meckelein]

An die IT...

Welches Server OS?
Welches Client OS?
Auf den Clients, lokale Benutzer mit eingeschränkten Rechten oder Benutzerauthentifizierung durch AD vom Server?
Freigabe für TM auf dem Server wie konfiguriert?
Netzlaufwerke auf den Clients lokal gemappt? Ist Zugriff über z.B. "T:\" sowie über die UNC Pfade möglich? Netzlaufwerk über Shell Script mittels "net use"?
Wie schaut die genaue Netzwerkkonfiguration aus? Welche Dienste laufen fürs Netzwerk?

Nur so als Beispiel, ich hatte mal Probleme in einer Umgebung mit dem WINS, daher frag ich immer explizit danach. Damals hat die Namensauflösung für die Clients zwar funktioniert, war aber langsam. Ursache war, dass der WINS Server keine Anfragen beantwortet hat und jeder der Clients in regelmässigen Abständen über einen Broadcast das Netzwerk ausgebremst hat. Leider konnte mir bislang weder CGM noch einer der Partner beantworten wie TM seine Zugriffe auf die Freigabe realisiert. Aber meiner Erfahrung nach, liegt genau an diesem Punkt der ganz große Flaschenhals für die Performance. Und zwar Aufgrund der Broadcasts und Timeouts im Netz, welche leider über eine Auslastung im Netzwerk nicht zu sehen sind.

Noch eine Info. Das TM welches auf dem Server läuft ist für die Datenbank auch nur ein Client und wird genauso behandelt wie jeder andere PC im Netzwerk. Der Geschwindigkeitsvorteil kommt hier hauptsächlich davon, dass das Windows "versteht" dass es Zugriffe auf den Netzwerkpfad auch lokal Auflösen kann.

Und bitte nicht böse sein oder so, wir unterhalten uns hier nur über persönliche Erfahrungen mit dem "Problem" Turbomed

[ms-dts-ge]

Ich bin nicht böse, ich bin viel mehr auch an den Erfahrungen interessiert

Windows 2008 Server Standard (SP2) 32bit, 4GB RAM
Clients inzwischen fast alle Win 7 64 bit

kein AD, nur Arbeitsgruppe, Benutzer an den PC jeweils lokal Admin
ganz normale Windows-Freigabe, auf den Clients normal gemappt als T:\
Zugriff über UNC möglich, keine Verzögerung bei Aufruf über UNC-Pfad.
kein Shell-Skript
Genaue Netzwerkkonfiguration? Was ist interessant?
IPv4, privater IP-Adressbereich, DHCP, DNS, WINS vom Turbomed-Server
Server macht ausserdem: Dateifreigabe, Druckerfreigaben, TMBACKUP, Dyn Updater

(32bit und Arbeitsgruppe war Anforderung des Turbomed-Installateurs in 2009)

WINS-Probleme wurden schonmal vermutet, aber von Anfang an lief auf dem Server der WINS-Server Dienst,
um eben genau diese Probleme zu umgehen.

[Meckelein]

OK, dann wird der Server demnächst wohl neu gemacht, also hoffe ich zumindest, weil ein 32 Bit OS ist einfach nicht mehr zeitgemäss und der Mainstream Support endet dieses Jahr, also gibts "nurnoch" Sicherheitsupdates bis 2020. Nichts desto trotz wird das zugrunde liegende Problem woanders zu suchen sein, da es ja schon länger existiert als der Server.

Zum einen erstmal, TM ist sehr stark davon abhängig, dass die Namensauflösungen im internen Netzwerk funktionieren, egal ob über WINS oder neuer über DNS. Da ich selber mit Linux arbeite habe ich zwar immer ein komplettes DNS am laufen, aber mach zusätzlich noch ein WINS mit an. Es stört nicht und ältere Software freut sich darüber meist.

Zum anderen würde ich jetzt mal her gehen und mir die komplette TM Config anschauen und zwar unabhängig davon, was ein TM Supporter sagt was richtig ist. Hierzu mal eine Einzelplatzinstallation in eine neue VM machen und diese im Anschluss in einen Server umwandeln, Anleitung oder man besorgt sich iwie das Tageskennwort von CGM . Wichtig hierbei sind vor allem die "leeren" local.ini und global.ini Dateien. Diese würde ich mir als Grundversion nochmals zusätzlich speichern. Mit diesem so gewonnen "TM-Server" kann jetzt der erste Performancetest gefahren werden. Anschliessend kann das ganze noch mit an diesen Server angeschlossene Clients wiederholt werden. Im Anschluss kann dann zu den Optimierungen gegriffen werden.

Eine Turbomed Server Installation wird von den Partnern und CGM immer als so ultra Wichtig und schwer dargestellt, im Endeffekt handelt es sich lediglich um die Einzelplatzinstallation von TM und dem anschliessenden eintragen des Fast Object Server (FOS) als Dienst mit Autostart. Wenn man sich mal unter Linux das Install Script angeschaut hat, erkennt man, das quasi einfach noch eine zusätzliche setup.exe für den FOS unter Windows ausgeführt wird, das ist alles.

Und eins noch zu MS Server 2008, schalten Sie die Firewall mal auf Durchzug, also alles rein und alles raus, nach Aussage von meinem Windows Systemhaus bockt die gerne mal auch wenn entsprechende Freigaben konfiguriert sind. Vom Umstellen der Pfade halte ich persönlich jetzt nicht so viel, wenn man das macht, sollte man unbedingt ein Shell Script bauen, welches nach einem Update die Ordner lokal mit dennen auf dem Server synct, nicht dass da was verloren geht. Die Sache mit der CacheDB ist echt super, aber nur wenn man genug Arbeitsspeicher im Server hat und eine DB Reorganisation hilft auch häufig weiter.

So das wars erstmal für den Anfang

[jipsy]

Ich bin nicht böse, ich bin viel mehr auch an den Erfahrungen interessiert

Windows 2008 Server Standard (SP2) 32bit, 4GB RAM
Clients inzwischen fast alle Win 7 64 bit

Der Titel des Threads sollte eher heissen "TM-Server massiv zu klein dimensioniert". 4GB, wenns geht ein Prozessor mit vielen, dafür langsamen Kernen und sicherlich keine schnellen Festplatten geschweige denn SSDs. Mag hart klingen, aber die Kiste ist bestimmt nach dem Booten schon mit dem OS/ Virenscanner ausgelastet. Der muss ja jede Aktion von der HDD ausführen, bei 4GB brutto bleibt dem OS ja garnichts mehr zum cachen der PraxisDB etc. Was sind denn als CPU, HDD/SSD und Mainboard verbaut? Ich sass neulich vor einer HP-Kiste mit RPM5400er HDDs, 3GB RAM wo die Praxis meinte es ist alles furchtbar langsam -> da konnte ich auch nur sagen "Sorry, aber wenn die Kiste schon 1h braucht um 20 Windows-Updates zu installieren und neu zu booten, dann ist sicherlich nicht das TM der Flaschenhals..".

[mfinke]

Guten Abend
Also Jipsy, wie ich bereits schrieb haben wir vor 8 Jahren mit einem Ottonormal PC als Server begonnen, ca. 1500 Scheine.

Die Ausrüstung die ms-dts-ge uns 2009 gebaut hat war zur Vorpraxis ein Quantensprung.

Ich habe heute nochmal unsere Erstkraft gefragt. Sie bestätigte mir, dass damals die Abrechnung bzw. der Prüflauf schon fast genauso lange dauerte.
Ich lasse gerade ein Prüflauf am Server laufen. Der hat nach genau 20 Minuten 16% das entspricht ca. 450 Patienten von 2656 geschafft.
Das kann nicht alleine an der Hardware liegen, da muss in der Datenbank etwas faul sein.

Ich muss sagen das die Beiträge von Meckelheim doch dtl. zielführender sind.
Da macht sich ein Kollege richtig Gedanken - vielen Dank dafür!!

Gruß M. Finke

[Meckelein]

G'Morgen,
hab gestern und heute nochmal bisschen in der Vergangenheit gewühlt, wollte mit ein paar Infos kommen. Natürlich muss ich jipsy Recht geben, das System ist nicht mehr zeitgemäss, das ist aber auch schon alles. Einige Posts hier im Forum, die sich mit der Performance von TM im Bezug auf die im Server eingesetzte Hardware beschäftigen haben mir schon immer missfallen.
Dazu ein aktuelles Beispiel ganz kurz:

Code: Alles auswählen

Aktuell 
Xeon E3-1230v2 8GB RAM HDDs
Abrechnung ca. 7 bis 8 pro Sekunde

Vor ca 1.5 Jahren 
AMD 265 Dual Core 1.8 GHz 4 GB RAM HDDs
Abrechnung ca. 3 bis 4 pro Sekunde

Man sieht ganz klar einen Unterschied von 100% in der Performance, aber eben keinen Einbruch in den Bereich in dem Hr. Finke arbeiten muss. Turbomed, besser gesagt der FOS, ist nicht davon abhängig wie schnell der Server ist auf dem er läuft, sondern einzig von der Anzahl an Zugriffen die pro Sekunde auf die DB möglich sind. Und diese hängen von etlichen Faktoren ab. Die Geschwindigkeit des Prozessors spielt dabei aber mal keine Rolle. Die größe des Arbeitsspeichers ist interessant, aber nur unter Windows Systemen, da man hier mittels des CacheDB Tricks die Datenbank in einen Cache schiebt. Die Geschwindigkeit der HDD/SSD macht einiges aus, aber vor 6 Jahren hat man noch nicht über eine SSD nachgedacht, diese Technik war schlicht zu teuer, damals ca. im sechsstelligen Bereich. Des weiteren geht es bei der Festplatte eher darum wie viele IOPS diese schaffen, d.h. ich kann auch mit einem ordentlichen Raid-5 mit 10k Festplatten eine SSD ähnliche Gesamt-Performance erzielen.

Es ist unbestritten, dass in die Praxis ein neuer Server gehört und zwar egal ob weiterhin TM verwendet oder gewechselt wird. Aber das aktuelle System ist nicht die Ursache für diese krassen Performance Probleme. Anregungen für Problemlösungen habe ich schon gegeben. Ich selber würde von unten Anfangen, es ist nunmal gerade der beste Zeitpunkt. Also Servermaschine kaufen, kleiner Prozi mit 16GB RAM für Windows (Linux langen 8 GB) und nem Raid für Datensicherheit reichen in meinen Augen. Wenn man Zusatzdienste wie Terminalserver, Exchange oder was auch immer benötigt steigen natürlich die Anforderungen, ich rede hier nur von TM und Absicherung des System sowie Backup.

Hr. Finke, danke für die Blumen, aber zum Kollegen hab ich es noch nicht geschafft, ich bin nur ein EDV Techniker mit Leib und Seele der vor etlichen Jahren sein Hobby zum Beruf gemacht hat und dem es den größten Spass bereitet sich in Probleme rein zu denken

[ms-dts-ge]

Der Server läuft mit einem Intel Xeon E3110, 3GHz Dual-Core, 3 "normale" Festplatten (7200er) als RAID5.
Es ist ja auch manchmal eine Kostenfrage, was man sich so als Server hinstellt.
Die Anforderungen die ich in Verbindung mit Turbomed höre, sind exorbitant im Vergleich zu anderen
Branchensoftwareprodukten. (DATEV, Sage, div. Warenwirtschaftssysteme oder kleinere ERP, alles bezogen auf <20 Arbeitsplätze)
Unternehmen in der Größe würden sich auch keinen Server für 7k€+ hinstellen, warum sollen es die Ärzte machen?

@jipsy
Die Kiste ist nach dem Booten nicht ausgelastet, überhaupt ist das Ding fast nie ausgelastet, geschweige denn über 40% Taskmanager-CPU-Last. Eher so 10%.

[mmoellinger]

Hallo Miteinander,
habe ein bißchen mitgelesen und bin über das Stichwort VPN und Filiale gestolpert: welches VPN?, wie ist die Filiale angebunden?
Im Openvpn gibts einen Schalter (http://openvpn.net/index.php/open-sourc ... l#redirect), der den gesamten Netzwerkverkehr durch den Tunnel routet, die Zeiten erscheinen mir so extrem langsam, geht der Traffic evtl. über einen Rechner in der Filiale und wieder zurück??? (sehr unwahrscheinlich aber nichts ist unmöglich, wie sehen die Einstellung der gateways aus?)
Ziemlich schräger Gedanke, aber?
Gruß
mölli

[ms-dts-ge]

Cisco Dial-Up VPN, die zwei Clients in der Filiale wählen sich per Cisco VPN Client ein und verbinden sich als Remotedesktop auf den Server. Einen Fehler von der Seite kann meiner Meinung nach ausgeschlossen werden,
da die VPN-Filiale ebenfalls nach 2009 dazu kam.

[TEPE]

Hallo,

bin kein IT Profi habe aber immer so lange gebastelt, bis ging (meistens ).
Aus dieser Erfahrung würde ich immer die Fehlerkette ausschalten, also wie ja scheinbar schon begonnen nur am Server testen, aber ich würde unbedingt auch das Netzwerkkabel trennen. Sollten externe Laufwerke dran stecken würde ich die auch mal entfernen. Die Datenbank wird ja hoffentlich Intern liegen . Nebenbei habe ich noch DHCP betrieb gelesen, der ist für so ein relativ großes Netzwerk ungeeignet, zumindest würde ich wenigstens die ständigen Rechner mit fester IP ausstatten. 10 Adressen können ja trotzdem für DHCP vorgehalten werden. Eine Domain wäre evtl. auch besser für die Neuinstallation.
Noch paar allgemeine Fehlerquellen. Sollte der Server die letzten 6 Jahre nur gelaufen sein, würde ich Ihn unbedingt auch mal öffnen und den Lüfter vom Prozessor mit seinen Kühlkörper reinigen. Denn wenn der Prozessor nicht gekühlt wird, bringt er nur noch die hälfte seiner eh schon schwachen Kraft.

Frohe Ostern!
Da bleibt ja Zeit zum basteln...

T. P.

[nmndoc]

Hallo Herr Finke,
Speziell für TM, dieses ist äusserst abhängig davon, wie das Netzwerk konfiguriert wurde. Besonderer Augenmerk sollte hierbei auf ordentlich funktionierendes DHCP, DNS, WINS und SMB liegen. Das sind mMn die Schwachpunkte an denen Turbomed immer hängt. Hier eine Empfehlung abzugeben ist schwer, da dies sehr stark von Ihrer verwendeten Hardware und den Betriebssystemen abhängt. Häufig ist es aber am besten, nochmal quasi neu anzufangen, vor allem wenn man den Server eh tauschen muss, s.o.

Können Sie den Punkt "WINS" evtl etwas genauer ausführen? Wo genau liegt das Problem bzw wie sollte die Konfiguration aussehen?

Eine Bemerkung die ich mir nicht verkneifen kann: Sie haben natürlich vollkommen Recht, dass ein funktionierendes Netzwerk speziell betr DNS/DHCP sehr wichtig ist. Um so 'lustiger' finde ich, dass ich es vom TM-Partner so kenne, dass er die Rechner einfach hinstellt, Arbeitsgruppe, fete IPs und fertig. Wenn man "Glück" hat zeigt der DNS Eintrag auf den Server (egal ob dort DNS läuft oder nicht), den Router oder auf sich selbst.

[nmndoc]

@ms-dts-ge:

Hier einige Punkte die mir spontan einfallen - teilweise auch welche die ich so bestätigen kann, wie Sie es erleben:

Erst einmal allgemein:

• Die Abrechnung hatten Sie auch schon mal direkt am Server laufen lassen (sonst bitte testen)? Ich vermute aber nicht nennenswert schneller?
• TM ist m.E. sehr abhängig von der Platten-Performance. Ich habe hier schon "Server" gesehen, die mit Onboard-Controller RAID-1 und normalen SATA-HDDs z.B. beim Entpacken des TM-Updates Schreibgeschwindigkeiten von 10 MB/s hatten. Lesen wird zwar besser gewesen sein - aber sehr sicher deutlich unter dem, was die HDDs eigentlich können sollten (sieht man übrigens genau NICHT an einer hohen CPU-last - sondern niedrige CPU bei langsamer Schreib/Leseleistung).
  Sie haben sogar ein RAID5 (mit 3 Platten). Falls das auch ein einfacher Onboard-Controller ist, bin ich mir fast sicher dass das Ihre Serverperformance "killt". evtl. sogar bei einem "richtigen Controller". Ich persönlich verwende mittlerweile nur noch RAID-1 oder ggf. 2x RAID-1 (System, daten, also 4 HDDs). Wobei mit dem richtigen Controller vermutl. 10 o.ä. besser wäre (ich mag es aber, dass man bei RAID-1 im Notfall eine HDD einfach azch ohne RAID an einen Rechner hängen kann um die Daten auszulesen). Sie könnten das im Prinzip nur indirekt ausprobieren, wenn Sie TM mal auf einen schnellen Rechner am besten mit SSD kopieren um zu sehen, ob das überhaupt einen DEUTLICHEN Unterschied macht.
• Windows Server in Arbeitsgruppe halte ich persönlich für fragwürdig (aber typisch TM-Partner) und mit o.g. 3-HDD-RAID5 "reisst" der Server sicher nichts mehr (ich denke aber nicht dass das das primäre Problem ist)

Speziell TM:

• Hatten Sie schon immer TM oder wurden da evtl. Daten aus einer anderen Software nach TM konvertiert
• Die Anzahl der Patienten 17000+ kommt mir sehr viel vor - haben andere auch so viel? Evtl. könnte das zB einen Unterschied machen (und nicht ausschließlich die Scheine). Würde das mal gerne bei uns in eingen Praxen vergleichen - wo sieht man das?
• Haben Sie einen Arzt in der Praxis/Lizenz oder mehrere? In einer Praxis sind es sagen wir mal 100 Ärzte und da ist die Tagesliste und ich denke auch die Abrechnung extrem langsam (TL locker 10 min wenn "alle Ärzte" ausgewählt ist). übrigens Trotz SSD im Server. Ich vermute dass hier ein Logik-Problem in TM liegt. Statt z.B. erst "alle Vorgänge von Datum <heute>" einzulesen und dann den Bezug zum behandelnden Arzt herzustellen habe ich den Eindruck dass für jeden Arzt nach relevanten Vorgängen gesucht wird (was dann in der Summe antürlich viel mehr und vorallem unnötige Abfragen bedeutet).
• evtl wäre eine Überprüfung / Konsistenzprüfung der DB sinnvoll. Ich denke Fehler u.ä. können TM sehr verlangsamen.
• Aus meiner Erfahrung (und da wären die o.g. Angaben wie Anzahl der Patienten, Übernahme aus Alt-Programm etc zum Vergelich mal interessant): wir haben mind eine Praxis in der z.B. das Konvertieren/Updaten irgendwelcher DB-Informationen (Ziffer, medikamente, o.ä.) die ja manchmal fällig sind, EXTREM lange (Stunden!) dauert - trotz identischer Hardware. Insofern würde ich da gerna mal die Informationen vergleichen.

[Meckelein]

Hallo nmndoc,

man kann ein Netzwerk auf zwei Arten aufbauen. Die eine ist die einfache, alles per DHCP vom Router aus, automatisch. Das langt für die allermeisten Fälle auch vollkommen aus. Die Rechner bekommen ihre IP, bekommen das Gateway und den DNS mitgeteilt, damit läuft Internet. Mit einem Windows 7 und aufwärts ist auch über die Heimnetzgruppe ein gegenseitiger Zugriff auf die Freigabe einigermassen einfach realisiert. Nachteil daran ist, dass die Fehlersuche sich äusserst schwierig gestalltet und sobald man ein Serverbetriebssystem in so ein Netz einfügt wirds wirklich lustig

Die andere Möglichkeit ist, die Dienste selbst zu konfigurieren. Vor allem wenn echte Server da stehen ist dies der wesentlich bessere Weg. In diesem Zuge kommen wir zu WINS. Erstmal kurz, was ist WINS? Einfach ausgedrückt ist es das "Telefonbuch" für die Windows Clients im internen Netzwerk, also die Übersetzung des Computernamens im Windows in die dazugehörige IP Adresse. Seit vier oder fünf Jahren empfiehlt aber MS selber, nicht mehr auf WINS zu setzen, sondern lieber einen internen DNS Server aufzusetzen, da dieser die Aufgabe besser übernimmt. Nichts desto trotz funktioniert WINS auch an aktuellen Betriebssystemen noch. Also auch ein aktuelles Win 7/8/8.1/10 können noch WINS sprechen und tun dies auch. Das Problem dabei ist, dass WINS im zweifelsfall ein Broadcast ins Netzwerk sendet, wenn kein Server im Netzwerk vorhanden ist, der das übernimmt. Auch bei einer Fehlkonfiguration von WINS auf dem Client oder am Server kann es zu solchen Broadcast Schwemmen kommen. Das Problem an dieser Situation ist, dass hierdurch das Netzwerk kurzfristig lahmgelegt wird ohne das auf einem Netzwerkmonitor ein erhöhter Traffic auftaucht. Man kann diese Broadcasts am besten mit einem Netzwerksniffer wie Wireshark sehen. Auch kann es auf dem Client zu Timeouts wegen einer WINS Anfage kommen, wenn der Server nicht darauf reagiert.

Ich weiss nicht genau in wie fern TM auf WINS angewiesen ist, da man auch alles über die IP Adresse laufen lassen kann. Da in meinem Samba Server aber immer ein WINS mit läuft, hab ich mir darüber bislang noch keine Gedanken gemacht, das WINS komplett abzuschalten.