MEDICAL OFFICE - Anwenderforum

Hallo Josmed,

dafür kann eine sogenannte Archivierung durchgeführt werden. Dabei werden ältere Daten (Bilder, Gescanntes) aus der Medoff.gdb in die Medoffarc.gdb ausgelagert. Auf diese Daten wird dann nur noch lesend zugegriffen. Die Medoffarc ändert sich demzufolge zwischen den Archivierungen nicht und braucht nur einmalig gesichert zu werden. Auf evtl. mobile Geräte bzw. Notfallserver muß die Archivdatenbank händisch umkopiert werden. Man kann sie mobil auch weglassen und auf den Zugriff unterwegs verzichten.
Um das entsprechende Volumen wird die Medoff.gdb verkleinert.
Die Abgrenzung erfolgt zeitlich. Man archiviert z.B. alles, was älter als zwei Jahre ist.
Der Vorgang erfordert Fachwissen und große Sorgfalt. Er kann durch Ihre Systembetreuung erfolgen.

Grüße und ein schönes Wochenende aus dem Norden
U. Strübing

Hallo Josmed,

willkommen im Club der Willigen - es gibt eine Anleitung (liegt bei mir) - habe es mehrfach versucht die Dokumente in die MEDOFFARC auszulagern - nach stundenlangem Hin und Herschaufeln, war aber die Grund-DB - MEDOFF.gdb am Filialort (nach Kopieren und persönlicher Auslieferung) immer zerschossen - wir haben das ganze Spielchen (dauerte immer ca. 12-18 Stunden bei 30GB) mehrfach durchgespielt - Schlussendlich haben wir es seien lassen... - für kleine DBs mit 5-6 GB vielleicht kein Problem - vielleicht auch bei 12 GB kein Problem - unsere hat nun 53GB... und wir haben kapituliert. (Rsync dauert nur noch 8-10 Stunden)

Nach dem dritten Fehlversuch (unklarer Ursache) hat unser Betreuer INDAMED eingeschalten, die dann die zerschossene DB ansehen (geht nicht im laufenden Betrieb! - also nur am WE oder Brückentagen) und händisch flicken wollten. Daraus ist nichts mehr geworden - verlief alles im Sand.

Wer sich traut, kann von mir die Anleitung haben und das mal auf einem Testsystem mit einer kopierten DB (vor dem Kopieren Dienste ausschalten!) ausprobieren. ich übernehme aber keine Gewähr für zerschossene Datenbanken etc. - Ob der Support dann freiwillig helfen will, wenn was schief läuft, weiß ich auch nicht... -

Good luck

TF

ich sichere den MO relevanten Ordner auf Festplatte, aktuell ca 10 G USB, 3.0 unter 4 Minuten, das hat mich positive erstaunt. Dabei ist eine Datei ca 8 GB starkt.
das ganze mit robocopy
JS

Hallo Josmed,

ich hatte vor ein paar Wochen ein Gespräch mit Herrn Wingenbach über das Thema. Wie Herr Fiermann bereits sagt, gibt es eine definierte Möglichkeit, die Datenbank zu schrumpfen, wenn sie noch nicht zu groß ist. Ich habe es auch mal an meinem Testsystem ausprobiert, ging alles gut. Das Problem ist jedoch, daß es keine Lösung gibt, sobald Sie einen mobilen Client nutzen, da die Synchronisation sonst nicht mehr funktioniert. Wenn Sie also Ihre Datenbank schrumpfen wollen, müssen Sie danach alle Clients mit Mobil-Modul komplett neu aufsetzen!! Das hat mich dann davon abgehalten, weil das Backup auch eigentlich recht schnell geht.


Wie "batsatd" schreibt, dauert es nur wenige Minuten (5 Min. für 7,5 GB), in denen MO (zumindest bei mir) unbeeinträchtigt weiterläuft. Ich sichere auf eine externe SATA-Platte, heute wäre sicherlich USB 3 flexibler. Mein "Server" läuft mit einer schnellen SSD, da machen die zusätzlichen Zugriffe nicht viel aus. Das einzige wichtige ist jedoch, daß Sie die Datenbank vorher in einen "sicheren Zustand" versetzen, das Thema hatten wir schon mal ("lock"). Ich nutze ein Backup-Programm, robocopy mit einer Batch-Datei, die den lock ausführt und danach wieder aufhebt, würde sicherlich auch gehen ...


Grüße,


Peter Quick

Hallo Herr Dr. Fiermann,

wie schon von Ihnen angedeutet, scheiterte auch nach meinem Kenntnisstand nicht das Archivieren selbst, sondern die zwingend erforderliche Neuinstallation der Exchange-Praxis.
Laut Ihrem Betreuer kam es bei dem Befehl Connect2RepServer zu einem unerwartet Abbruch (ggf. weil wie von Ihnen beschrieben, die Datenbank kaputt war). Der Wunsch mir ein davon selbst ein Bild zu machen blieb bis jetzt unerfüllt. Mit Ihrem Betreuer habe ich nun abgesprochen, dass wir den seinerzeit erstellten Datenbestand prüfen werden.
Ihr Datenbankgröße ist mit 53GB auf keinen Fall zu groß dafür. Wir haben Kunden mit mehr als 200 GB in der MEDOFF.GDB und zusätzlich mehr als 200 GB in der MEDOFFARC.GDB.

Viele Grüße

Michel Bechtatou

Hallo Herr Bechtatou,

schön, dass Sie sich melden. Leider hat sich seit August 2014 niemand diesbezüglich bei mir mehr gemeldet. Die besagten Datein - (nach Aktivierung der Replikation zerschossene Datenbank der Filiale) haben wir zwischenzeitlich gelöscht (löschen müssen! 100GB nur Schrott!). Gerne können wir wieder einen Versuch unternehmen. Da ich aber ahne wie das ausgeht, brauche ich erst einmal etwas Vorlauf. So was muss man planen. Schließlich muss ich die Datenbank
1. Sichern,
2. Kopieren (USB 3.0 dauert trotzdem!)
3. Die Datenbank auf einem externen Rechner (Intel I7) konvertieren (Server dafür viel zu langsam!) ,
4. dann eine Kopie der konvertieren medoff.gdb und medoffarc.gdb in der Haupt BS einspielen,
5. dann in die Filiale fahren, dort die Kopie einspielen,
6. dann per Fernwartung die Replikation anschieben und hoffen dass alles nach 10 Stunden Arbeit und zig Kilometer Fahrstrecke geklappt hat.

Falls nicht, kommen Sie ins Spiel. Und das bitte an einem Wochenende oder rein bayerischen Feiertag ;-)

Was machen Sie denn so an Ostern?...

TF

Wir haben auch durch die zahllosen eingescannten Arztbriefe eine stetig wachsende Datenbankgrösse.
In 2013 hat Herr Bechtatou unsere damalige MEDOFF.GDB teilweise in die MEDOFFARC.GDB ausgelagert,
damalige Größe aktiv danach ich glaube 10 GB, Archiv 49 GB. Dauerte auf dem Server rel. lange am Nachmittag.
Der Vorgang wurde von Ihm über die Fernwartung mittels TeamViewer durchgeführt.
Danach gab es zunächst ein Performanceproblem, nach dem nächtlichen Neustart der MO-Dienste wegen der
gelaufenen Datensicherung am Server musste MO die archivierte DAtendank jeweils gefühlte 2 min neu
organisieren, jeweils beim ersten Aufruf eines archivierten Dokumentes. Dies Problem hat Herr Bechtatou (Danke noch einmal )
durch einen komplexeren Eingriff an der Datenbank (ich glaube Reindizierung) jetzt aber beseitigt.

Ich fahre jetzt eine MEDOFF.GDB von 38 GB, eine MEDOFFARC.GDB vom 49 GB, im täglichen Betrieb merke
ich keinen Unterschied zu der Zeit vorher ohne Archivdatenbank. Allerdings ist das täglich zu sichernde
Volumen natürlich deutlich geringer. Ich kann keine Nachteile feststellen.

An ein damaliges Neuaufsetzen unseres Notfallservers oder der beiden Laptops kann ich mich nicht erinnern, ich meine
das dort lediglich die Dateien über die Netzwerkverbindung kopiert worden sind.

Vielleicht kann Herr Bechtatou ja nochmal den genauen Ablauf erläutern.

Hallo,

zur allgemeinen Erklärung:
Die Datenbank MEDOFFARC.GDB ist mit einem Schreibschutz versehen (datenbankseitig, nicht windowsseitig vom Dateisystem her!). Daher können archivierte Bilder/Dokumente nicht mehr bearbeitet werden und der Datenbestand in der MEDOFFARC.GDB ändert sich nicht. Darum muss die Datei nur einmal gesichert werden und die Menge der täglichen Datensicherung verringert sich.

Beim Auslagern werden die zu archivierenden Dokumente von der MEDOFF.GDB in die MEDOFFARC.GDB verschoben. Dabei werden sie aus der MEDOFF.GDB gelöscht, sonst würde kein Platz frei. Der Vorgang des Archivierens wird nicht per Replikation an die Mobilen/Notfallserver/Exchange-Server übertragen. Dieser Punkt macht es erforderlich, dass vor dem Archivieren alle Replikationsteilnehmer vollständig abgleichen und nach der Archivierung alle Mobilen etc. neu aufgesetzt werden. Ohne diesen Schritt sind die archivierten Dokumente auf den Mobilen weiterhin in der MEDOFF.GDB enthalten. Dies wäre an sich noch kein Problem, solange die Dokumente nicht bearbeitet werden. Alle Arbeitsplätze, die auf der Datenbank arbeiten, die archiviert wurde, können keine der archivierten Dokumente mehr bearbeiten (siehe oben), aber auf den Mobilen geht das weiterhin, da die Dokumente in der MEDOFF.GDB enthalten sind. Wird einer der Datensätze bearbeitet, so wird diese Information per Replikation verteilt, so dass die Bearbeitung an alle anderen übertragen werden soll. An der Stelle scheitert es dann am Hauptserver, da die Dokumente in der unveränderlichen MEDOFFARC.GDB liegen.

Beim Löschen der Dokumente wird die Dateigröße der Datenbank nicht automatisch reduziert. Man hat am Ende eine Datenbank MEDOFF.GDB gleicher Größe "mit Lücken". Um auch diesen Speicherplatz freizugeben, muss die Datenbank neu aufgebaut werden (Backup und Restore). Dies geschieht während des Archivierungsvorgangs automatisch, so dass am Ende im Dat-Ordner die MEDOFF.GDB ohne die Dokumente in Originalgröße vorliegt und eine Datei MEDOFF_RESTRORED.GDB. Letztere ist die Datenbank ohne die Dokumente mit reduzierter Größe. Diese muss dann nur noch zur MEDOFF.GDB umbenannt werden. Auch diese Größenreduzierung (Backup und Restore) wird nicht per Replikation an die Mobilen weitergeleitet, so dass das Kopieren der neuen MEDOFFARC.GDB zwar den aktuellen Archivdatenbestand auf die Mobilen bringen würde, aber dort die MEDOFF.GDB weiterhin in Ursprungszustand und -größe vorliegt.

Während der Archivierung darf auch keine Replikation und kein Programmzugriff laufen, da es sonst zu Datenverlust kommen wird.

Je nach Datenbankgröße, zu archivierender Menge und eingesetzter Hardware kann eine Archivierung mitunter sehr lange dauern. Daher ist wie von Dr. Fiermann schon erwähnt eine ausreichende Vorbereitung nötig. Außerdem sollte der Vorgang nicht "im Alleingang" durchgeführt werden, wie Herr Strübing schon schrieb. Datenverlust und Ungereimtheiten durch unsachgemäße Bedienung, die erst später auffallen, können später nicht mehr zu diesem Vorgang zugeordnet werden und man hat unerklärliche Phänomene. Die Archivierung ist kein Vorgang, der "eben mal schnell in der Mittagspause" durchgeführt werden kann und sollte. In Praxen mit Mobile/Exchange-Modul erhöht sich der Aufwand bei Vor- und Nachbereitung auch deutlich. Wie bei Dr. Overhage gehört anschließend natürlich auch der Test dazu. Soweit ich mich erinnere war dort ein Indexlauf nötig, damit es wieder wie gewohnt lief.

Zur Vorbereitung kann ich empfehlen, einen Testlauf auf einer Datensicherung durchzuführen, damit man eine Vorstellung von der Dauer des Archivierungsvorgangs bekommt. Wenn die Archivierung zum Beispiel länger als ein Wochenende dauert, muss man sich den Termin schon sehr genau überlegen

Soweit mir bekannt ist, muss der Datenbankdienst für die Archivierung laufen. Da nur Daten gesichert werden, die älter als 1 Jahr bzw. 90 Tage sind, stellt sich die Frage, warum zu diesem Zeitpunkt nicht auf dem MO-Arbeitsplatz gearbeitet werden darf (Werden neue Daten nicht automatisch mit dem aktuellen Datum hinzugefügt?).

Zitat von »G.Wingenbach«

Diese muss dann nur noch zur MEDOFF.GDB umbenannt werden.

Ich nehme an, dass der Datenbankdienst hier deaktiviert sein muss. Eine andere Möglichkeit wäre doch die direkte Wiederherstellung in die MEDOFF.GDB? Dann müsste man den Datenbankdienst nicht stoppen.

Wenn ich das richtig verstehe, darf man zu Beginn des Backups keine neuen Daten mehr in MO eintragen. Nach der Wiederherstellung ist das wieder erlaubt. Ist die Ausführung so korrekt?

Hallo vital,

meine Beschreibung war keine Anleitung zur Durchführung der Archivierung, sondern eine allgemeine Erklärung, was dabei geschieht. Sie galt auch für den Archivierungslauf, wie er zum damaligen Zeitpunkt gemacht werden musste. Mittlerweile wurde die Archivierung überarbeitet, so dass dass die Beschreibung nicht mehr in vollem Umfang gilt.

Damals musste vor dem Archivieren der Zugriff auf die Datenbank gestoppt werden, da nach dem Archivieren automatisch ein Backup und Restore durchgeführt wurde. Im dem Moment, in dem das Backup beginnt, wird von der Datenbank ein Snapshot erstellt und dieser Zustand gesichert. Bis zu diesem Zeitpunkt könnte theoretisch noch weitergearbeitet werden (wenn keine der zu archivierenden Datensätze betroffen sind), aber spätestens zu dem Zeitpunkt muss die Arbeit mit MO aufhören. Da aber weder sichergestellt ist, dass keiner der Datensätze bearbeitet wird, noch dass rechtzeitig aufgehört wird, wenn man die Weiterarbeit zulässt, war die Vorgabe, dass vor dem Archivieren jeglicher anderer Datenbankzugriff gestoppt werden muss.

Wenn ich mir das richtig zusammenreime, muss das wie folgt funktionieren:

1. leere Datei "STOP.MO" im INDAMED-Verzeichnis anlegen
2. 1 Minute warten bis alle Clients heruntergefahren sind
3. im INDAMED-Verzeichnis convert.exe Archiviere starten (Auslagerung alter Datensätze in die MEDOFFARC.GDB)
4. nach Beendigung im INDAMED-Verzeichnis convert.exe backuprestore starten (Löschen der ausgelagerten Datensätze in der MEDOFF.GDB)
5. nach Beendigung des Vorgangs Löschen der Datei "STOP.MO"

Sie können das ja bestätigen, verneinen oder verbessern.

Ich glaube diese Diskussion geht völlig in die falsche Richtung. In der Benutzeroberfläche von MO ist absichtlich kein Knopf für "ARCHIVIERE" vorhanden.

Warum wohl???

Es gibt bei diesem Thema einfach zu viele zu beachtende Variablen und ich glaube nicht, dass selbst EDV-affine Anwender in der Lage sind, diese in ihrer Gesamtheit zu überblicken.
Damit möchte ich niemandem zu nahe treten!
Die Diskussion hier zeigt allerdings recht deutlich (allerdings nur im Ansatz) was alles zu beachten ist. Gerade bei der Anbindung von Mobil und Exchange.

Auch wenn der Sparfuchs ein beliebtes Tier ist, sollte er hier gemieden werden.

Mein Appell an den SUPPORT, hier keine weiteren Handlungsanleitungen mehr zu geben, und an die Anwender, sich an Ihren Betreuer zu wenden.

Ich finde es sollte in diesem aktiven Forum keine Tabuthemen geben. Auch evtl. komplizierte Anfragen sollten in diesem aktiven Forum diskutiert werde können.
Oft helfen solche Anfragen wie diese das System noch besser zu verstehen.

Zitat von »micvost«

Ich finde es sollte in diesem aktiven Forum keine Tabuthemen geben. Auch evtl. komplizierte Anfragen sollten in diesem aktiven Forum diskutiert werde können.
Oft helfen solche Anfragen wie diese das System noch besser zu verstehen.

Stimmt !
Und jeder kann selbst entscheiden, was er macht und sich zutraut und ist letztlich selbst dafür verantwortlich.

viele Grüße

M.Meier

Sind wir für Sie nur Kunden oder möchten Sie lieber Fans haben?
https://www.youtube.com/watch?v=szY48loqgZs

??????

Was wollen Sie denn damit sagen? Ich glaube, dass wir im Gegensatz zu vielen anderen Kunden anderer Firmen schon sehr viele "Freiheiten" haben. Man muss sich immer nur wieder klar machen, was man eigentlich tut. Wenn sie in einem Anfall von forschem Vorgehen ihrer Datenbank schreddern, wird Ihnen ohne Backup keiner mehr helfen können.

O. k., ich mache auch das meiste selbst. Trotzdem habe ich ein Testsystem, auf dem ich erst einmal alle meine Errungenschaften und Versuche fahre. Wenn dann die Datenbank im Eimer ist, ist es kein großes Drama. Auf meinem Produktivsystem bin ich aber viel vorsichtiger.

Auf dem Jubiläums treffen von Indamed letzten September konnte ich mit einigen Programmierern diskutieren. Dort wurde noch einmal ganz klar gesagt, dass zum Beispiel bei einem Mobil Modul das Verlagern von Daten in das Archiv nicht funktioniert. Dann müssen Sie danach das Mobile Modul komplett neu aufsetzen. Ich weiß nicht, ob das jedem so klar ist.

Auf der einen Seite stimme ich Herrn Lange zu, dass nicht jeder in der Lage ist, das Komplettsystem zu beherrschen. Dafür gibt es ja auch einen Support. Trotzdem ist es ja bisher üblich und auch sicherlich nicht verboten, dass wir uns als erfahrene Nutzer austauschen und auch Dinge ohne Support bewältigen. Herr Lange hat dann sicherlich aber auch keine Lust, ein zerstörtes Datenbank System wiederherstellen zu sollen...

Grüße,
Peter Quick

Hallo,

erstmal, das ist ein tolles Video:

Zitat von »vital«

https://www.youtube.com/watch?v=szY48loqgZs

Aber ich denke, wir haben und brauchen beides: Kunden und Fans!

Wir wollen aber sicher keine Informationen für uns behalten. Aber leider spricht aus Herrn Langes Aussagen die Erfahrung. Es ist sich leider nicht jeder der Fragilität seiner Daten bewusst und es ist mehr als einmal passiert, dass es auch schmerzhafte Verluste gab. Deshalb können wir nur jedem Kunden und Fan, der sich selbst tiefer in den EDV-Sumpf begeben will, raten, immer nur das zu tun, was er auch vollends verstanden hat.
Man macht keine Experimente mit seiner Existenz, das sollte jedem klar sein!

Jeder der das hier liest sollte sich selbst mal fragen: Wann habe ich das letzte Mal die Funktionsfähigkeit meiner Datensicherung geprüft oder prüfen lassen?

Wir werden die Informationen zur Archivierung aktualisieren und dann auch hier bereitstellen. Aber es wird in der Beschreibung auch drin stehen "Nutzung auf eigene Gefahr" und "keine Garantie ohne vorhandene aktuelle Datensicherung".

mfg
Uwe Streit

Wenn Indamed keinen Archivierungsknopf einbaut, der das vollautomatisch oder per Menü erledigt (was eigentlich möglich sein sollte) dann mache ich das nicht selbst.
Auch wenn ich eigentlich das gerne machen können sollte.
Die Sicherung sollte aber eine solche sein, die den Namen verdient, die Sicherung zu prüfen ob sie denn o.k ist wäre ein Aufwand der mich störte.
Falls eine Prüfung notwendig ist, solte diese auch in der Indamedoberfläche vorhanden sein.

Oder ist das Datenbankkonzept so komplex, dass man da Großkonzernniveau erreicht?

Ich bin mit MO Super zufrieden was die Geschwindigkeit angeht. Ich brauche aber schon eine Sicherung, die ich mit nach Hause nehmen kann um täglich auch darauf gut zu schlafen, gleiches gilt für die Archivierung.

Ab welcher Datenbankgröße sollte man eigentlich archivieren?

Kann man mit Hardwareaufrüstung auf Archivierung verzichten ?

Intel I5 i7 36 GB Ram SSD auf allen Clients schneller Server.

Wären Spielpc eine Lösung schnelle Gravik ets ?

Ich will eigentlich mit 2000 Scheinen nur noch 14 Jahre die KV Lotterie spielen ohne Archiverungsgedöns.

Lösung möglich ?
JS