Error Kernel Timestamp-Fehler 2160 bei StammDB nach Kopieren

[Praktischer]

Guten Tag,

zunächst einmal, ich habe selten ein so gutes Forum gefunden wie dieses hier. Die Hotline ist nicht so gut. Danke an alle hier.

Ich habe nach Anleitung in diesem Forum eine Batch-Datei geschrieben, die StammDB, PraxisDB, DruckDB, Formulare und Vorlagen kopiert. Mit Xcopy. Das funktioniert bestens.

Habe einen Reserve-Server im Keller. Mit Norton-Ghost vom Original-Server Partition c und d vor 3 Wochen kopiert. Läuft bestens. Nachdem ich die o.g. aktuellen Datenbanken nun übers Netz kopiert habe, lässt sich Turbomed auf Ersatz-Server nicht mehr starten. Bleibt hängen wegen Timestamp-Fehler. Error 2160.

Muss ich auch Global.ini und Local.ini vom Original-Server kopieren ?
Was mache ich falsch ?

Vielen Dank

Praktischer

[Praktischer]

Guten Tag,

zunächst einmal, ich habe selten ein so gutes Forum gefunden wie dieses hier. Die Hotline ist nicht so gut. Danke an alle hier.

Ich habe nun nach Anleitung in diesem Forum eine Batch-Datei geschrieben, die StammDB, PraxisDB, DruckDB, Formulare und Vorlagen kopiert (von meinem Server Anmeldung1). Mit Xcopy. Das funktioniert bestens. Die Batch-Datei starte ich aus dem DOS-Fenster, nachdem ich Turbomed an allen Stationen beendet habe.

Habe einen ausrangierten Reserve-Server (Anmeldung2) im Keller. Dieser hat eine andere Netzwerkadresse und kann nun, wenn der Original-Server aus ist, als Ersatzserver laufen. Mit Norton-Ghost vom Original-Server Partition c und d vor 3 Wochen kopiert. Läuft bestens.

Nachdem ich die o.g. aktuellen Datenbanken nun übers Netz kopiert habe, lässt sich Turbomed auf Ersatz-Server nicht mehr starten. Bleibt hängen wegen Timestamp-Fehler. Error 2160. Sichere ich die gesamte Partition D als Ghost-Image läuft alles. Die Partition hat aber 3-4 GB wegen der ganzen Bildatlanten etc, und das dauert mir zulange. Ich will nur die Datenbanken transportieren

a) Muss ich auch Global.ini und Local.ini vom Original-Server kopieren ?

b) Was mache ich falsch ? Muss ich noch weitere Config-Dateien kopieren ?

Vielen Dank

Praktischer

[wahnfried]

Hallo,

Lokal.ini und Global.ini müssen nicht kopiert werden.

StammDB-timestamp-Fehler klingt nach nicht synchronisierter Zeit oder Datum zwischen den Rechnern.

Batch wird vom Reserveserver ausgeführt?

Dann fügen Sie am Anfang Ihrer Batch die Zeile ein:

net time \\servername /set /y

Ich kopiere die StammDB nicht, daran wird eh' nichts geändert, kostet nur Zeit (Zeile allerdings für den Fall der Fälle nur auskommentiert, nicht gelöscht). Dafür kopiere ich auch die Dokumente (aber mit dem Schalter /d wie bei Formulare, also "neu und neuere"). Bei der PraxisDB macht der Schalter /d manchmal (abhängig von der Gerätekonfiguration?) Probleme, bei der DruckDB lasse ich ihn auch weg...

Einmal werden Sie aber die Spiegelung incl. StammDB machen müssen, um den Timestamp-Fehler wegzubekommen. Zur Not einmal die TurboMed-interne Datenspiegelung ablaufen lassen, nachdem der Rechner (aber nach Sichern der jetzigen Lokal.ini und Global.ini für den Servermodus!!!) als Client konfiguriert wurde (wenn das läuft: auch die Lokal.ini und Global.ini des Client-Modus sichern..., habe ich aber mit einem Reserveserver noch nicht gemacht, wäre aber ein Experiment wert).

Läuft Ihre Batch mit TMAdmin.exe-Aufruf? ist sie korrekt durchgelaufen? (d.h. Ende des Datensicherungsmodus der Datenbanken korrekt angezeigt? Hinter der letzten Zeile den Befehl "pause" eintragen, dann kann man das in der DOS-Box kontrollieren (bei Automatisierung der Spiegelung aber nach der Kontrolle wieder auskommentieren oder löschen).

Falls ohne TMAdmin vom Hauptserver bei überall beendetem TurboMed kopiert:
war der Prozeß TurboMed.exe im Speicher an allen Arbeitsplätzen korrekt beendet? Wenn nein, gab es auch beim wieder-Starten von TurboMed auf dem betreffenden Arbeitsplatz oder Server eine Fehlermeldung. Und die Spiegelung läuft dann auch nicht durch. Ob das irgendwo der Fall ist, bekommt man angezeigt, wenn man am letzten noch laufenden Arbeitsplatz die TurboMed-interne DatenSICHERUNG (wohl auch bei der automatischen DatenSPIEGELUNG) laufen läßt. Falls dabei keine Fehlermeldung mit der Angabe der nicht korrekt beendeten Arbeitsstationen erfolgt, kann man ja die Sicherung abbrechen...

Viele Grüße, Wahnfried

[uro_fs]

Hallo,

1haben Sie evtl. in der Zwischenzeit das Zwischenupdate aufgespielt.
Damit wäre dann eine Datenbankinkompatibilität erklärt
2. sind beim Kopieren vorher die Datenbanken mit TMadmin vorbereitet worden?

Gruss
fs

[danspie]

Ich habe beim Kopieren der Datenbanken auf meinen Laptop auch gelegntlich Schwierigkeien mit einem Laufzeitfehler, kopiere ich dann nochmal, ist wieder alles ok. Werde mal einen Versuch mit net time (Danke Wahnfried) versuchen

[Praktischer]

Es funktioniert jetzt !

Dank an uro_fs der noch mal den Hinweis machte. die Datenbanken mit TMAdmin vorzubereiten. Das habe ich jetzt so umgesetzt und die DOS-Befehle zwischen die Admin-Anweisungen gesetzt.

Und Dank an Wahnfried der den super Hinweis mit dem net time Befehl gebracht hat. Auch das habe ich aufgenommen. Nun sind die Rechner synchronisiert, es gibt keine Probleme mehr.

Ich sichere übrigens den Server "Anmeldung1" auf einen Ersatzserver der auch "Anmeldung1" heisst. Da nicht beide gleichzeitig im Netz in Betrieb sein können, nutze ich als Umweg einen dritten PC. Also von A nach B, A ausschalten, C einschalten und dann von B nach C kopieren. Ob das wohl noch "eleganter" geht ?

Natürlich könnte ich die Datenbanken einfach auf DVD-RAM am Originalserver sichern und dann nach Abschalten abends physisch in den Keller gehen und die DVD am Ersatzserver einlesen. Ziemlich plump so, wozu habe ich ein Netzwerk ?

Was möchte ich damit erreichen: Bei einem Defekt des Originalservers schalte ich den ab und fahre den Ersatzserver hoch, die anderen Clients können sich wieder anmelden. Ich habe hier gelesen, man kann auch auf einen Client sichern und den dann als Server konfigurieren, hört sich umständlicher an als meine Methode. Aber sicher bin ich mir nicht ....

[danspie]

Wenn Sie berücksichtigen, dass sie jeden Tag den Aufwand mit kopieren - Herunterfahren Server - Starten Ersatzserver - 2. Kopieren haben, halte ich den Umweg, einen Client zum Server zu achen und dadurch nur einmalig zu kopieren für geringer. Aber das hängt natürlich von Ihrer Netzstruktur ab und von den Aufgaben, die der Server in Ihrem Natz hat

[wahnfried]

Hallo,

mit rfbdoc hatte ich mal außerhalb des Forum angedacht ob diese Umstellmöglichkeit eines Clienten zum Server nicht evtl. an die Netzwerkstruktur "Arbeitsgruppe" gebunden ist, da in einer Domäne der Client sehr viel schwieriger zum Server gemacht werden kann, wenn überhaupt (bzw. der Ausfall des Servers das Netzwerk komplett zum Erliegen bringen würde, wenn kein Ersatzserver bereit ist).

Ich hatte aber (und offensichtlich der Kollege auch nicht) noch keine Zeit, mich dem Thema zu widmen. Aufgrund dieser jetzigen Diskussion stelle ich diese Frage aber einfach mal zur Diskussion.

Unabhängig davon wäre die Umstellmöglichkeit jedes Clienten zum Einzelplatzrechner jederzeit möglich. Per Hausbesuchmodul dann Übertragen der geleisteten Arbeit von den anderen Stationen zu einem Einzelplatzrechner, der als Haupt-Arbeitsplatz definiert wird.

Was sagen die Netzwerk-Kenner zum Thema "Domänen-Client zum Server umdefinieren"? möglich oder nicht?

Man könnte evtl. aus den Clients der Domäne einfach eine Arbeitsgruppe erstellen?

Viele Grüße, Wahnfried

[Thomas]

Hallo Wahnfried,

also in einer Domäne ist das aus mehreren Gründen problematisch.

1. Man hat ja auf dem Domain-Controller ein Server Betriebssystem laufen, z.B. Windows 2003. Auf den Clients hat man in den meisten Fällen ein Client-Betriebssystem, z.B. XP Prof. Ein Domain-Controller kann nur auf einem Server Betriebssystem laufen. Man müsste also im Vorfeld alle Clients mit Windows 2003 Server ausstatten. Das kostet aber irre Geld... Dann jedoch ist ein Weiterarbeiten (also primär das Anmelden an einer Domäne) problemlos möglich, wenn der Domain-Controller ausgefallen ist. Aber wie gesagt, finanziell völlig uninteressant.

2. Aus den Clients einer Domäne "schnell mal" eine Arbeitsgruppe machen ist zwar machbar, aber man muss dazu alle Clients aus der Domäne entfernen und in die Arbeitsgruppe setzen. Wenn der Domain-Controller dann irgendwann wieder da ist, fängt der Streß an, weil dann alle Clients die Verbindung zur Domäne verloren (bekommen) haben. Kein unlösbares Problem, aber aufwändig.

Zum Glück ist das alles aber unnötig.

Nehmen wir an, ein Windows 2003 Server und eine Handvoll XP Prof. Clients. Die Clients sind in der Windows 2003 Domäne. Der Domain-Controller fällt aus. Die Clients selbst können sich mit ihrem gecachten (zwischengespeicherten) Benutzerdaten zunächst trotzdem noch an der Domäne anmelden, natürlich fehlt dann die Verbindung zum Server.

Die Clients können aber danach unabhängig von der Domäne "wie in einem kleinen Peer-to-Peer-Netzwerk" Verbindungen miteinander aufbauen. Das sollte schon mit den Domänenkonten gehen, sofern auf den Clients auch lokale Zugriffsrechte für die Domänen-User auf die Verzeichnisse erteilt worden sind.

Wenn das Probleme macht, dann kann man auf dem zum Server umkonfigurierten Client einfach mit den lokalen Systemtools ein lokales Benutzerkonto einrichten und diesem Konto Zugriffsrechte auf die Verzeichnisse (meist wohl Turbomed) geben. Danach können die anderen XP PCs sich wie in den "kleinen Netzen" auch mit diesem "Server" verbinden. Die Domäne, die im Hintergrund immer noch schlummert, spielt dabei keine Rolle.

Das kann man übrigens gefahrlos ausprobieren, den Windows 2003 Server abschalten und die Verbindungen zwischen den Clients testen. Nur die Finger von der Domänenmitgliedschaft lassen, also keine Arbeitsgruppe erstellen, dann kann man später den Server einfach wieder hochfahren und die Welt ist wieder in Ordnung.

Dann besteht natürlich von vornherein noch die Möglichkeit, ohne Domäne zu arbeiten. Das Vorhandensein eines Windows 2003 Servers erzwingt nicht die Verwendung einer Domäne! Auch ein Windows 2003 Server kann im Arbeitsgruppenmodus betrieben werden, dann müssen natürlich die Benutzerkonten wie gehabt manuell auf jedem Client einzeln eingerichtet, mit Rechten und den gleichen Kennwörtern versehen werden. Dafür ist ein Wiederbeleben eines verstorbenen Systems wesentlich einfacher. In den üblichen Praxisnetzen, die doch meist recht überschaubar sind, ist das durchaus eine gangbare Alternative.

Mal Hand auf's Herz, wer arbeitet wirklich mit eingeschränkten Benutzerrechten (das dürften noch einige sein), wer ändert regelmäßig die Systemkennwörter auf den Systemen (da werden's weniger). Diejenigen, die jetzt noch die Hand heben, sind mit einer Domäne gut bedient (und sind bzw. haben wohl auch einen erfahrenen Administrator, der sich im Notfall um die Reanimation kümmert). Die anderen können den Betrieb ohne Domäne durchaus ins Auge fassen. Die Leistungen des Serverbetriebssystems haben sie dadurch dennoch (z.B. Terminalserverfunktionen, mehr als 10 Verbindungen, Software-RAID, usw.).

Ich hoffe, damit konnte ich etwas Klarheit in die Fragestellung bringen.

Viele Grüße,

Thomas

[uro_fs]

wer mehr als 5 Arbeitsplätze oder 2 und mehr Ärzte in TM verwaltet und in einer Domäne arbeit, der sollte sich überlegen, einen Backup-Server zu installieren (Kosten ca. 1500 Euro inkl. Windows 2003 Server).

Ich brauchte nach einem Komplettausfall des Servers ca. 2 Stunden um die drei wichtigsten Rechner inkl. Ersatz-Server zu konfigurieren (und wartende Patienten zu beruhigen) - machen Sie das mal in der laufenden (oder besser gesagt dann NICHT laufenden Sprechstunde). Sie kriegen ja nicht einmal ein RP gedruckt.

Danach haben wir uns einen Backup-Server angeschafft. Per Taskplaner holt dieser ca. alle 2 Stunden automatisch die aktuellen Daten vom Server. Damit er sich nicht langweilt haben wir den Ersatzserver gleich noch zum Fax-Server/Empfänger gemacht, da der Rechner ja eh immer läuft.

Damit beläuft sich bei einer Umstellung der Aufwand darauf, DHCP zu starten, poet zu starten, Anmeldeskript (im Server) (meldet Netzlaufwerk auf einem bestimmten Buchstaben an) Server1 durch Server2 zu ersetzen.

Clients neu starten - fertig.

Bei 15 Rechnern dauerte es im (kleinen) Ernstfall den wir hatten exakt 5 Minuten (so lange dauerte eine aktuelle Kopie der Daten von Server 1 nach Server2), dann liefen die Rechner über den Ersatzserver.
Und inkl. VPN-Verbindung lief alles wie gewohnt.

Beim Rückstellen werden dann nur Dokumente-Ordner und Praxisdb zurückkopiert und die o.g. Änderungen rückgängig gemacht - das kann man aber abends oder wann auch immer in Ruhe machen, denn der Praxisablauf ist bis dahin völlig reibungslos.

Und wir haben eine papierlose Praxis und ich kann wieder ruhig schlafen.

Gruss
fs

[danspie]

Ich will Thomas etwas widersprechen: der Einsatz einer Domäne ist doch nicht nur daran gekoppelt, dass die Sicherheit in der Domäne optimert ist (Stichwort Passwörter). Ich selber gebe zu, meine Passwörter nicht regelmäßig zu wechseln. Dennoch halte ich ab einer gewissen Größe und Komplexität der verwendeten Programme eine Domäne für sinnvoll. Gerade komplexere Strukturen sind besser zu administrieren. Zudem läuft ein derartiger Server halt einfach staibler. Dafür hat man das Problem, wenn der Server ausfällt. Ich mache es wie uro_fs: mit einem Zweitserver.

[Thomas]

Hallo danspie,

Sie schreiben:

Dennoch halte ich ab einer gewissen Größe und Komplexität der verwendeten Programme eine Domäne für sinnvoll. Gerade komplexere Strukturen sind besser zu administrieren.

Hhhmm, nicht verwechseln: Komplexe Programme und komplexe Strukturen. Die Programme mögen komplex sein, die Strukturen (Benutzergruppen, Organisationseinheiten, Standorte, Replikationsebenen, Backup DCs usw.) sind in den meisten Praxen doch eher simpel (sprich - nichtexistent), oder?

Zudem läuft ein derartiger Server halt einfach staibler.

Dem wiederspreche ich ja nicht. Hat aber nichts mit dem Einsatz einer Domäne zu tun, wie ich schrieb. Ein Windows 2003 Server kann auch prima im Arbeitsgruppenmodus laufen, und ist eben immer noch ein Windows 2003 Server. In der Frage von Wahnfried ging es um die Nebenwirkungen beim temporären Ersetzen eines Domain-Controllers.

Aber ich denke, wir gleiten ab diesem Punkt ins philosophieren ab... die technischen Fakten habe ich beschrieben. Was jemand draus macht, bleibt jedem selbst überlassen

[danspie]

Hallo Thomas,
Sie haben Recht, komplexe Programme und komplexe Strukturen sind zwei Paar Stiefel: meiner Meinung nach werden die komplexen Strukturen kommen: der Trend wird zu Zusammenarbeit/Zweigpraxen etc gehen, da übder die digitale Vernetzung in der Hintergrundarbeit erhebliche Kosteneinsparung möglich ist. Eine komplett digitalisierte Praxis kann eine Zweitpraxis mit deutlich geringeren Nebenkosten fahren.
Aber auch komplexe Programme, d.h. Programme mit Server/Client-Struktur erfordern einen Server. Wenn ich dann aber derartige Programme habe, richte ich einen stabilen Server mit entsprechendem Betriebssystem ein (hier stimmen Sie ja auch zu). Dann kann ich baer den Server sowieso nicht einfach so ersetzen, sondern nur durch einen zweiten Server. Dann nütze ich doch die administrativen Vorteile einer Domäne!
Ich glaube, dies ist keine philosophische Frage, sondern hat doch erhebliche Konsequenzen: wenn ich im wesentlichen TM laufen habe und sonst nichts, werde ich keinen großen Aufwand in meine Netzstrukturen stecken,habe ich dagegen komplexere Programme oder plane ich in der Zukunft komplexere Strukturen, sollte ich eine Domäne aufbauen - diese aber wohl am besten mit zweitem Server (?)
Aber ich glaube, wir sind von unseren Ansichten nicht weit voneinenader entfernt.
Viele Grüße

[uro_fs]

W2k3 Server und Domäne ist schon eine zuverlässige Sache.
Wir haben in 2 Jahren kein einziges Windows-Problem nur 1x ein Festplatten-Problem (das war aber eine defekte Charge vom Hersteller) gehabt.

Ansonsten bedurfte der Server keinerlei Eingriffe ausser Update TM und Ifap.

Gruss
fs

P.S.: noch ein Tipp für Leute mit "echtem Server" und Raid-Systemen.

Die Performance wird interessanter Weise meist deutlich besser, wenn man Read-ahead, adaptive Read-ahead und andere Caches im Controller ausschaltet.
Die Doppelung von Cache in Festplatte UND Raid-Controller hebeln sich meist gegenseitig aus.

Bei mir wurde durch deaktivieren des Caches die Random-Transfergeschwindigkeit von 50 auf 70 MB/sek erhöht und die effektiven Zugriffszeiten drastisch gesenkt, was sich in deutlich besseren Antwortzeiten im TM äussert.