Seite 4 von 5
Verfasst: Montag 9. Oktober 2006, 22:36
von LEM
uro_fs hat geschrieben:QOS sollte im Netzwerk auf jeden Fall herausfliegen - ansonsten habe ich einfach automatische Konfig mit DHCP.
Hallo Uro_fs
Danke für den Tip. Werde morgen mal sehen, dass ich QOS bei allen Geräten rausschmeisse.
Ähm... was macht QOS eigentlich genau? Warum hat "sehr klein weich" (micro soft) diesen Treiber überhaupt mit installiert ? Eine Idee ?
uro_fs hat geschrieben:Was ich aber gemerkt habe ist - Netzwerkkarte ist nicht gleicht Netzwerkkarte. Einige "vertragen" sich mit bestimmten Hubs nicht besonders, was in einem Transfereinbruch zu sehen ist (manche 100er ist schneller als eine schlechte 1000er - liegt wohl an unsauberer Spannung/Flanke etc.)
Netzwerkkarten und Hub stammen vom gleichen Hersteller über den gleichen Händler. --- Wollte gerade schreiben: Damals als ich die Sachen gekauft habe. Aber das sind schon ein paar Jährchen, und inzwischen wurden die PCs ausgetauscht und nutzen ihre eigenen Zugänge über das Mainboard. Bleibt also doch nichts als der Tip:
"Da die Karten nicht mehr viel kosten hilft hier ausprobieren"
uro_fs hat geschrieben:TMWinadmin kann das Gleiche wie TMadmin nur nicht Batchgesteuert.
Versteh ich das richtig - über die Parameterliste weiter vorne in diesen Beiträgen kann man mit TM(Win)Admin kurzzeitig den Poet ausschalten, dann Daten sichern und Poet wieder einschalten? OHNE das dabei alle PCs mit TM im Netz sich ausloggen müssen?
Und zumindest an einem PC könnte mit kleineren Eingaben weiter gearbeitet werden? Diese Daten werden zwischengespeichert und dann in die PraxisDB eingetragen, sobald der Poet wieder eingeschaltet wurde ???
Warum ich das frage: Dann könnte ich Freitag mittag die komplette Datensicherung in dem Zeitraum während der letzten 1-2 Stunden der Praxiszeit ziehen und bräuchte nicht die Zeit dafür noch hinten dran zu hängen.
Man, wäre das einfacher.

(Ich nehme meine Praxisdaten nämlich immer brav mit nach Hause. Man weiss ja nicht, wer sich sonst mal nachts für so einsam im Dunkeln rumstehende PCs interessiert.)
uro_fs hat geschrieben:Eine weitere schöne Option für kleine Praxen - PraxisDB komplett im Cache laden mit TMWinadmin.
Gute Idee - welches Kommando braucht der PeCinese, damit er schneller Männchen macht ?

Was passiert mit den Daten, wenn mal wieder der Blitz in den Trafo 'neihaut ? Oder der Nachbar die Stromleitung anbohrt und somit das ganze Haus vom Netz nimmt? Dann wären doch die Daten im Cache futsch, oder ??
Danke
LEM
Verfasst: Montag 30. Oktober 2006, 22:38
von LEM
uro_fs hat geschrieben:QOS sollte im Netzwerk auf jeden Fall herausfliegen...
Vielen Dank für den Tipp !!
Meine Damen (und auch ich) danken es Ihnen...
Ohne dieses QOS ist das Netz jetzt deutlich schneller - in der Anzeige zum Netzwerkdurchsatz geschätzt gute 20-25%.
Gruß!
LEM
Verfasst: Montag 5. Februar 2007, 17:17
von Kobold
An dieser Stelle mal ein grosses Dankeschön an alle Forumsmitglieder. Mit Ihrer Hilfe habe ich die Umstellung realisiert:
Medistar auf TM
Papier auf Papierlos
Blankoformular
Anbindung des Sonogerätes
Einrichten des gesamten TM-Netzwerkes incl. Heimarbeitsplatz incl. neuer Hardware
und das alles ohne TM-Vertriebspartner in einem Vorgang.
Danke!
Hier ein kleiner Beitrag meinerseits in diesem Thread:
Leider bin ich zu blöd das Skript (spezieller Dank an fs) in die Gruppenrichtlinie einzubinden, das es auch funktioniert. Manuell läuft es tadellos, aber beim runterfahren meldet er zwar, dass ein Script ausgeführt wird, Daten werden aber keine kopiert.
Ich habe das Problem anders gelöst:
ich habe einfach am Ende des Skriptes ein shutdown-Befehl eingefügt und fahre den Rechner jetzt über das Skript herunter (Verknüpfung mit Aussschalt-Icon auf dem Desktop). Das hat den Vorteil, dass man nach Wunsch den Rechner auch "normal" herunterfahren kann.
Mit Robocopie sieht das dann so aus:
D:\turbomed\Programm\TMAdmin /beginBackup /server=server
robocopy.exe "\\SERVER\Turbomed (F)\Turbomed" "D:\Spiegel\Turbomed" /E /ZB /COPY:DAT /R:0 /W:0
D:\turbomed\Programm\TMAdmin /endbackup /server=server
shutdown -s -t 00
Der Kobold
Verfasst: Montag 5. Februar 2007, 19:11
von uro_fs
Hallo Forum,
beim neuerlichen Lesens dieses Threads stolperte ich über die Verwendung von robocopy mit dem Befehl /MIR.
Leute, das ist HOCHGEFÄHRLICH.
Robocopy /MIRror löscht auch Daten auf dem Spiegel, falls im Originalverzeichnis nicht mehr vorhanden sind!
Das kann dazu führen, das ein versehentlich gelöschtes Verzeichnis im Original beim Backup dann ebenfalls auf
"Nimmer Wiedersehen" aus dem Spiegelserver verschwindet.
Nehmt also den Copy-Befehl - und lasst einige EXTRA Files (so werden diese beim Kopiervorgang dann angezeigt) ruhig auf dem Spiegel - sicher ist sicher.
Gruss
fs
Datensicherung
Verfasst: Dienstag 6. Februar 2007, 13:53
von JoergSchoenen
Mein Gott, ist das alles kompliziert.
Ich zippe jeden abend die PraxisDB und Monats-Dokument-Verzeichnisse mit einer selbstgestrickten Java.jar-Datei über USB auf einen Speicherstick (bis 2 GB), geht in 3 Minuten, während ich den Schreibtisch aufräume. Morgens zwischen 6 und 8 Uhr zuhause Kontrolle und Doku und auf gleichem Weg die Daten zurück. Alte PraxisDB wird jeweils 1 Tg. i.d. Praxis und zuhause in Reserve gehalten. 1x/Wo. mit ähnlicher -.jar und Taskplaner i.d. Praxis und zuhause automatische Sicherung in Zip-Datei auf zweite Festplatte und alle paar Monate Brennen auf CD. Falls jemand die Zipxy.jar´s will - kann ich mailen. Voraussetzung ist Java jdk1.5.0_07.
Gruß JoergSchoenen
Re: Datensicherung
Verfasst: Mittwoch 7. Februar 2007, 20:08
von andreas.kotowicz
JoergSchoenen hat geschrieben:Mein Gott, ist das alles kompliziert.
Ich zippe jeden abend die PraxisDB und Monats-Dokument-Verzeichnisse mit einer selbstgestrickten Java.jar-Datei .... Falls jemand die Zipxy.jar´s will - kann ich mailen. Voraussetzung ist Java jdk1.5.0_07.
Wäre nett wenn Sie den Code hier posten könnten.
Datensicherung
Verfasst: Donnerstag 8. Februar 2007, 14:54
von JoergSchoenen
Hallo,
den Code posten kann ich so nicht, ist ein Jarfile, bestehend aus drei „-.java“ -Dateien bzw. 10 class-files + 1 Manifest-file. Habe die Datei aber auf meine homepage hochgeladen. Wenn Sie in die Adressleiste Ihres Browsers „
http://www.j-schoenen.de/praxis/PraxisDBZip.jar “ eingeben und anklicken können Sie die Datei herunterladen. Sie kann, wenn „jdk1.5.0_07“ (oder neuer) installiert ist, durch anklicken ausgeführt werden – braucht aber vielleicht noch eine kurze Gebrauchsanweisung, da eigentlich nur für den Eigengebrauch erstellt. Den Code können Sie nachlesen, wenn Sie das Jarfile mit Winzip öffnen und dort die „ -.java“ –Dateien mit einem Texteditor öffnen (sie sind mit eclipse erstellt).
Viel Spaß.
JoergSchoenen
Verfasst: Samstag 10. Februar 2007, 23:31
von lapins
----Ja PraxisDbZip.jar ist gut zu verstehen,

sind ja nur knapp 1000 lines of code, jetzt weiss ich wenigstens wie ich zum Bahnhof komme!
Also irgendwann sehe ich mir java an, aber bis dahin muss ich meine Sicherungen weniger elegant mit planned Tasks/ bat's /xcopy/ robocopy/ arj32 durchführen.
Beste Grüße
RLap
Noch Fragen Kienzle--Ja,Hauser
Verfasst: Freitag 2. März 2007, 21:33
von aquabus
Hallo
habe die Seite erst vor kurzem gefunden nachdem 2 schwere Hardwarefehler

mich gezwungen haben nach Alternativen zur Datensicherung zu suchen.
Erstes Projekt war das Skript von fs das auch sehr gut funktioniert aber leider nur wenn alle Arbeitsstationen abgemeldet sind. Bei einer angemeldeter Station erscheint im DOS die Meldung " SHARE-Verletzung"
Welchen Fehler habe ich gemacht
oder hat sich seit erscheinen der Threads in 2005 etwas auf Programmebene geändert?
Über einen Hinweis würde ich mich freuen
Re: Noch Fragen Kienzle--Ja,Hauser
Verfasst: Dienstag 6. März 2007, 21:37
von aquabus
Welchen Fehler habe ich gemacht
oder hat sich seit erscheinen der Threads in 2005 etwas auf Programmebene geändert?
Über einen Hinweis würde ich mich freuen[/quote]
Ja, lesen müßte man können
Habe Leerzeichen zwischen "beginBackup \server=server vergessen
nun läuft es !
[b]USB-Platten für Dauerbetrieb nicht geeignet[/b]
Verfasst: Freitag 27. April 2007, 23:25
von lapins
USB-Platten für Dauerbetrieb nicht geeignet
Nach mehreren Vorkommnissen "sonderlicher Art" bei den externen USB Platten erfährt man nach Internetrecherche, dass externe USB Platten i.A. für den DAUERBETRIEB nicht geeignet sind
Dabei wäre es so schön:
-alle 90 Min eine Weitere Generation \praxisdb
- Alle anderen Verzeichnisse(sono, ekg Dokumente lufu Fritz-fax per robocopy (neu und Neueres) .
Dauer: ca 2 Minuten, allerdings optimiert, wobei die zugrunde liegenden Verzeichnisse bei sono und ekg ja schon in die zig GB und bei sono ca 150.000 Dateien gehen. ...
Jetzt wird wieder geändert, diesmal auf USB-Stick und ich frage mich welche Überraschungen ich noch erleben werde: Stichwort max Lösch- und Schreibzyklen ca 100.000
Die Schreibgeschwindigkeiten habe ich bei "alternate" verglichen, da gibt es grosse Unterschiede
->also 1) USB Platten kann man nicht einfach kaufen und verwenden wie eine eingebaute disk (=Dauerbetrieb)
-> 2) Es kommt wieder mein Ärger über die Sicherung von Praxisdb auf.. siehe nächsten eintrag.
Immer die ganze Praxisdb kopieren
Verfasst: Samstag 28. April 2007, 00:00
von lapins
Immer die ganze Praxisdb kopieren?
Das muss auch anders gehen, ich hab nur keine Doku.
Eigentlich will ich bei einem Ausfall nicht mehr als 15 oder 30 min verlieren.
Die Methode "gesamte Praxisdb kopieren" mit tmadmin kostet aber zu viel Zeit.
Die Hyperspeed-Hardware von URO_FS hab ich nicht.
Beim crash erst eine 2.te Platte ausbauen will ich nicht, zumal man ja nicht wissen kann, warum ein Computer jetzt gerade kaputt ist
Über das Netz muss man mindestens 2min warten.
Packt man vorher (per arj32), dann frißt das die CPU Zeit des Servers und das kommt dann fast auf das gleiche heraus.
Außerdem ist die Praxisdb ja nicht das einzige was man aktuell gesichert haben möchte.
USB Platte Dauerbetrieb? ist wohl nicht (s.o.)
LÖSUNG:?
Warum kann man nicht 1x/Tag einen Backup machen und zwischendurch nur frei werdende LOGFILES auf einen anderen Server kopieren?
Die Wiederherstellung ginge dann per Roll-forward also
BACKUP + NEUE Transaktionen = DB-stand von ca 15 min vor crash.
So machte ich das andernorts mit einer anderen db schon 1999.
Das müßte doch mit Fastobjects (mit Doku) ebenso funktionieren?
Weiß jemand was? An TM hab ich das glaub ich vor 3 jahren schon geschrieben aber ohne Antwort, was da normalereweise kaum vorkommt.
mfg RLap
Verfasst: Dienstag 1. Mai 2007, 17:16
von uro_fs
Hallo Lapins,
TM wird Ihnen hier nicht helfen, aber vielleicht das Forum von Versant:
http://www.versant.com/developer/forums ... orum_id=11
Ich habe keine Hyperspeed-Ware. Die erreichten 25 MB/sec sind für USB 2.0 Festplatten ganz normal und wurde auch schon erreicht, als mein Server noch ein einfacher Athlon 1.8 Ghz erster Generation war.
Wenn das nicht erreicht wird beim Kopieren der PraxisDB sollte man mit einem Tool wie HDTune mal die internen und externe FP-Geschwindigkeit testen. Gelegentlich liegt das Problem in einem eingeschalteten "Geräuschdämmungs-Modus" der Festplatte oder falschem USB 2 Treiber.
Eine Server-FP sollte bei den Datenmengen, die TM redundant überträgt ersten einen großen internen Cache (8 Mb oder mehr) haben und mindestens 40 Mb/sek übertragen. Solche FPs kosten heute keine 200 Euro mehr und als Software-Raid 0 (oder Hardware-Raid, wenn Sie haben) haben sie mit zweien davon immer automatisch eine Kopie mitlaufen.
(Mein einfacher Aldi-PC zu Hause macht 62. MB/sek.)
Gruss
fs
Verfasst: Mittwoch 2. Mai 2007, 15:31
von lapins
@lem
Cachen der praxisdb:
beim Start in das Autostart Verzeichniss eine TMCACHE.BAT datei legen
C:\turbomed\Programm\TMAdmin.exe /cachepraxisdb
Dann sollten Sie im Server genug Speicher haben zum Beispiel
256mb(oder512mb) + Grösse des Verzeichnisses \turbomed\praxisdb .
und danach AHA Erlebnisse bei der "Erweiterten Suche" und bei grossen F3 geniessen!
Bei uns sind als Beispiel im Server 1024+256mb und ..\praxisdbp ist ca 800mb gross
@uro_fs (oder fs?)
Usb-Platten Speed ist kein Problem , liegt zwischen 10 und 25,8mb/sek je nachdem ob man Verzeichnisse mit vielen Files oder ein megafile kopiert.
Also Ohne USB-Platten Dauerbetrieb-Problem wäre ja alles super. Aber vielleicht tritt das nur bei uns auf?
Aber in Ihren Beiträgen - die ich immer sehr genau lese! , vom 18.01.2005, 11:02 03.05.2005, 12:39 und 03.05.2005, 12:39 erwähnten Sie, dass Sie Ihre DB über das Netz auch an einen anderen Server alle 2 Stunden kopieren und dass
1GB nur 95 sek dauern. Das wären netto 10,5mb/sek.
Davon kann ich nur träumen. Wir haben 6-8mb/sek, und bis alle Differenzen gesichert sind ist, dauert das so ca 2-3 Minuten.
In dieser Zeit ist aber das Netz so gut wie DICHT. - nicht akzeptabel.
Deshalb mach ich die 90' Sicherung auf schnellen 4GB USB-Sticks ( 13mb/sek OCZstick)
Trotzdem, wenn es kracht, sind auf dem Spiegelserver die Daten noch nicht vollständig, sondern die Usbstick müßte man erst dazukopieren - wieder ein Unsicherheitsfaktor.
Mfg
RLapins
Verfasst: Mittwoch 2. Mai 2007, 15:37
von lapins
@lem
Cachedb+ Ausfall:
Normalerweise werden neue Daten sowohl in den Cache als auch auf die Platte geschrieben (als auch zuerst in logfiles- so logging eingeschaltet ist)
Wenn also die praxisdb im Speicher gecached ist, sollte deswegen auch nicht mehr verloren gehn als "ungecached".
Wegen eines fehlerhaften Memorymodules hatten wir tatsächlich ein paar mal BLUESCREEN , aber Daten gingen deswegen auch nicht verloren.
Mfg Lap
Cachen der PraxisDB
Verfasst: Freitag 27. Juli 2007, 11:27
von hw
Cachen der praxisdb:
beim Start in das Autostart Verzeichniss eine TMCACHE.BAT datei legen
Zitat: C:\turbomed\Programm\TMAdmin.exe /cachepraxisdb
Dann sollten Sie im Server genug Speicher haben zum Beispiel
256mb(oder512mb) + Grösse des Verzeichnisses \turbomed\praxisdb .
und danach AHA Erlebnisse bei der "Erweiterten Suche" und bei grossen F3 geniessen!
Geht das auch beim Einzelplatzsystem (z.B. Laptop zuhause für besondere Auswertungen, Regressabwehr usw.... ?)
Ich habs damit jedenfalls nicht geschafft, der Laptop rödelt nach wie vor auf der Platte rum, von AHA-Effekt jedenfalls keine Spur.
Hauptspeicher ist 1 GB, praxisdb ca. 150 MB
Grüße
HW
Cachen PraxisDB: Cache muss aber sofort gespeichert werden
Verfasst: Samstag 28. Juli 2007, 09:51
von wahnfried
Hallo,
soweit ich weiß, gibt es im BIOS eine Einstellung, den Prozessor-Cache sofort oder verzögert auf der HDD abzuspeichern.
Dies sollte immer auf "sofort speichern" eingestellt sein, da sonst tatsächlich bei Rechnerausfall/Stromausfall_ohne_USV eine nicht bekannte Anzahl von Eingaben verlorengeht (abhängig vom Speicherbedarf der einzelnen Eingaben).
Das ist aber eine generelle Regel für Rechner in Arztpraxen und sollte von jedem verantwortlichen Systembetreuer von vornherein so eingestellt sein, unabhängig von TurboMed...
Da aber Viele ihre Rechner lieber selbst Aufbauen und Warten: lieber nochmal nachsehen!
Für die Systembetreuer-Nutzer: lieber nochmal kontrollieren!
Nun aber noch eine kleine Frage:
Im Zusammenhang mit Speicher-Skripts war der Befehl "Net Use" mit dabei. Aus der Angabe im DOS werde ich nicht schlau und denke, daß auch Andere im Forum gerne wissen würden, was dieser Befehl alles ausführt. Wer gibt mir Nachhilfe?
Viele Grüsse, Wahnfried
Verfasst: Samstag 28. Juli 2007, 10:26
von DerEchteFreund
Lieber Wahnfried,
sind Sie Informatiker? Wissen Sie genau wie ein Cache funktioniert? Wissen Sie, was ein Commit auf einer Datenbank bewirkt?
Wenn Sie eine dieser Fragen mit nein beantwortet haben, sollten Sie nicht derart falsche Aussagen bezüglich des Zwischenspeicherns verbreiten.
Ich weiss, Sie meinen es nur gut, aber diesmal liegen Sie total daneben

Verbreitung falscher Nachrichten
Verfasst: Samstag 28. Juli 2007, 14:10
von wahnfried
Lieber echter Freund,
dreimal nein: also habe ich nachgefragt, wo meine Fehlmeinung herkommt (die ich ja glücklicherweise mit "soweit ich weiß" begonnen hatte):
(Diese Info jetzt von meinem PC-Spezialisten-Freund, die Datenbankwartungen usw. beruflich macht und mir meinen Praxisserver vor etwa 5-6 Jahren aufgebaut hat)
Das, was auf "sofort schreiben" eingestellt werden sollte, war der FESTPLATTEN-Cache, bezogen auf meinen Rechner VOR dem Netzwerkaufbau, der damals ein (noch im vorigen Jahrtausend selbst aufgebautes...

) SCSI-System war und dann im Netzwerk bis zur Umstellung auf TurboMed als Client weiterverwendet wurde. Gilt wohl nur für SCSI-Platten und dürfte dann (das ist aber wieder meine eigene Schlußfolgerung...) vermutlich im SCSI-Bios eingestellt werden
Vielen Dank an den Echten Freund für die Korrektur und die Mahnung !
(auch oder gerade wer etwas gut meint, ist lernfähig...

)
Viele Grüsse, Wahnfried
Verfasst: Montag 30. Juli 2007, 19:59
von Lauxtermann
Ich habe die praxisdb mit dem cache-Befehl ins RAM versetzt. Die Anzeige des freien RAM ging um ca. 600 MB runter. Nach Weiterarbeit mit Turbomed wurden aber innerhalb einiger Minuten wieder 600 RAM frei, so daß ich davon ausgehe, daß die praxisdb nur für einen Augenblick im RAM gespeichert wurde. Ist das richtig? Dann wäre der cache-Befehl ja wohl ziemlich unsinnig. Oder gibt es eine andere Erklärung?