DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Moderator: Forum Moderatoren
Forumsregeln
TM-Startforum - "offen für alle Themen".
Beiträge, die in einen anderen Bereich passen, werden bei Bedarf verschoben.
TM-Startforum - "offen für alle Themen".
Beiträge, die in einen anderen Bereich passen, werden bei Bedarf verschoben.
-
- Beiträge: 86
- Registriert: Samstag 29. Dezember 2018, 20:15
- 5
- Hat sich bedankt: 13 times
- Bedankt: 2 times
DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Hallo zusammen,
bei uns wurde zufällig entdeckt, dass bei einem Kassenfall trotz Eingabe aller Abrechnungsziffern nicht alle in der Abrechnungsdatei übernommen wurden. In der Karteikarte sieht alles i.o. aus. Der TM-Techniker hat ewig gesucht und eigentlich nichts gefunden.
Nun sollen wir eine Reorganisation der Datenbank machen, dann eine Reparatur (mit einem speziellen, von der CGM-Hotline zu bekommenden Passwort) und dann eine Konsistenzprüfung. Als Ergebnis soll ich den Support-Ordner zippen und an TM schicken.
Sicherheitshalber wollte ich die Konsistenzprüfung auf der auf einen Laptop gespiegelten DB mal machen: die lief 9 Stunden! und es gab 61.000 Inkonsistenzen, die behoben wurden, dabei 3 Patienten und der Rest Karteizeilen.
Diese sieht z.B. bei uns so aus:
Patient PraxisDB§(0:0-386317#3274498, 258) Korrektur: Der letzte Behandlungsfall dieses Patienten wurde korrigiert.
Patient PraxisDB§(0:0-2080609#13516441, 258) Korrektur: Der letzte Behandlungsfall dieses Patienten wurde korrigiert.
Patient PraxisDB§(0:0-986866#6817128, 258) Korrektur: Bei dem Patienten wurden die Behandlungsfälle neu zugewiesen.
Karteikarte PraxisDB§(0:0-4329#45122, 237) Korrektur: Bei der Karteikarte wurden die Karteikartenzeilen neu zugewiesen.
Karteikarte PraxisDB§(0:0-5418#51639, 237) Korrektur: Bei der Karteikarte wurden die Karteikartenzeilen neu zugewiesen.
...
Hat Jemand schon Erfahrungen mit diesen Verfahren gemacht?
Kann man selber in der Ergebnisdatei "Konsistenspruefung" sich schlau machen, bei welchem Patienten hier etwas schief lief?
Wie kommt so eine hohe Zahl an Inkonsistenzen zustande?
Ich hatte die Hoffnung, dass man da selbst schon mal auf Fehlersuche gehen kann...
Danke sehr für jeden Hinweis.
bei uns wurde zufällig entdeckt, dass bei einem Kassenfall trotz Eingabe aller Abrechnungsziffern nicht alle in der Abrechnungsdatei übernommen wurden. In der Karteikarte sieht alles i.o. aus. Der TM-Techniker hat ewig gesucht und eigentlich nichts gefunden.
Nun sollen wir eine Reorganisation der Datenbank machen, dann eine Reparatur (mit einem speziellen, von der CGM-Hotline zu bekommenden Passwort) und dann eine Konsistenzprüfung. Als Ergebnis soll ich den Support-Ordner zippen und an TM schicken.
Sicherheitshalber wollte ich die Konsistenzprüfung auf der auf einen Laptop gespiegelten DB mal machen: die lief 9 Stunden! und es gab 61.000 Inkonsistenzen, die behoben wurden, dabei 3 Patienten und der Rest Karteizeilen.
Diese sieht z.B. bei uns so aus:
Patient PraxisDB§(0:0-386317#3274498, 258) Korrektur: Der letzte Behandlungsfall dieses Patienten wurde korrigiert.
Patient PraxisDB§(0:0-2080609#13516441, 258) Korrektur: Der letzte Behandlungsfall dieses Patienten wurde korrigiert.
Patient PraxisDB§(0:0-986866#6817128, 258) Korrektur: Bei dem Patienten wurden die Behandlungsfälle neu zugewiesen.
Karteikarte PraxisDB§(0:0-4329#45122, 237) Korrektur: Bei der Karteikarte wurden die Karteikartenzeilen neu zugewiesen.
Karteikarte PraxisDB§(0:0-5418#51639, 237) Korrektur: Bei der Karteikarte wurden die Karteikartenzeilen neu zugewiesen.
...
Hat Jemand schon Erfahrungen mit diesen Verfahren gemacht?
Kann man selber in der Ergebnisdatei "Konsistenspruefung" sich schlau machen, bei welchem Patienten hier etwas schief lief?
Wie kommt so eine hohe Zahl an Inkonsistenzen zustande?
Ich hatte die Hoffnung, dass man da selbst schon mal auf Fehlersuche gehen kann...
Danke sehr für jeden Hinweis.
- RAMöller
- Beiträge: 1311
- Registriert: Montag 4. Januar 2010, 20:42
- 14
- Hat sich bedankt: 3 times
- Bedankt: 13 times
Re: DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Ich kann nur sagen, dass wir eine Datenbankreparatur wg. 1 Fehlers durchführen lassen mussten.
Die komplette Datenbank wurde zur Reparatur übergeben, ich meine, es waren so um die 500€
Die komplette Datenbank wurde zur Reparatur übergeben, ich meine, es waren so um die 500€
-
- Beiträge: 86
- Registriert: Samstag 29. Dezember 2018, 20:15
- 5
- Hat sich bedankt: 13 times
- Bedankt: 2 times
Re: DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Danke schon mal für die Warnung. Aber hat es was gebracht? Und ist rausbekommen worden, wie es zu dem Fehler gekommen ist?RAMöller hat geschrieben:Ich kann nur sagen, dass wir eine Datenbankreparatur wg. 1 Fehlers durchführen lassen mussten.
Die komplette Datenbank wurde zur Reparatur übergeben, ich meine, es waren so um die 500€
- RAMöller
- Beiträge: 1311
- Registriert: Montag 4. Januar 2010, 20:42
- 14
- Hat sich bedankt: 3 times
- Bedankt: 13 times
Re: DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Danach war der Fehler behoben.
Ursache war ein umfangreiches Diagnoseupgrade durch ein TMUpdate, so ca. 600.000 Einträge, da ist dann ein Fall hängen geblieben. Ich hätte den Fall einfach gelöscht, aber die Fehlermeldung blieb.
Wenn sie sehr viele Meldungen haben, auch mal die Hardware incl Leitungen checken, damit man das nicht andauernd machen muss.
Das Problem bei Datenbankfehlern ist, dass Datensicherungen wenig bringen, da der Fehler mit gesichert wird. Es gibt wohl technische Lösungen, das zu verhindern, aber teuer.
Hätte ich nach dem Diagnoseupgrade eine Wartung gemacht, hätte ich es bemerkt.
Ursache war ein umfangreiches Diagnoseupgrade durch ein TMUpdate, so ca. 600.000 Einträge, da ist dann ein Fall hängen geblieben. Ich hätte den Fall einfach gelöscht, aber die Fehlermeldung blieb.
Wenn sie sehr viele Meldungen haben, auch mal die Hardware incl Leitungen checken, damit man das nicht andauernd machen muss.
Das Problem bei Datenbankfehlern ist, dass Datensicherungen wenig bringen, da der Fehler mit gesichert wird. Es gibt wohl technische Lösungen, das zu verhindern, aber teuer.
Hätte ich nach dem Diagnoseupgrade eine Wartung gemacht, hätte ich es bemerkt.
-
- Beiträge: 399
- Registriert: Montag 6. Februar 2012, 21:54
- 12
- Bedankt: 3 times
Re: DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
liebe Kollegen! ich habe einfach mal "zum Spaß" am Proberechner eine Konsistenzprüfung laufen lassen. Ergebnis: 4000 korrigierte Fehler. Ich merke aber im Tagesbetrieb nichts "Negatives". Meine Frage: MUSS und in welchen Abständen sollte man diese Prüfung durchführen. Was passiert, wenn man es auf Dauer lässt?? Genügt die regelmäßige Prüfung der Praxis-DB auf die man ja hingewiesen wird?? Gruß
-
- Beiträge: 399
- Registriert: Montag 6. Februar 2012, 21:54
- 12
- Bedankt: 3 times
- RAMöller
- Beiträge: 1311
- Registriert: Montag 4. Januar 2010, 20:42
- 14
- Hat sich bedankt: 3 times
- Bedankt: 13 times
Re: DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Wie gesagt: Nein.Heilberger hat geschrieben: Genügt die regelmäßige Prüfung der Praxis-DB auf die man ja hingewiesen wird?? Gruß
Man müsste es mindestens tgl. prüfen, da der Fehler mitgesichert wird. Vielleicht gibt etwas automatisches, ein Tool oder einen Befehl, den man regelmäßig ausführen kann?
-
- Beiträge: 86
- Registriert: Samstag 29. Dezember 2018, 20:15
- 5
- Hat sich bedankt: 13 times
- Bedankt: 2 times
Re: DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Die Reorganisation lief bei mir problemlos durch und hat auch nicht lange gedauert. Das Problem war die im zweiten Schritt durchzuführende Reparatur der DB, die leider mit der Fehlermeldung endete, dass die Probleme nicht behoben werden konnten und ich mich zwecks weiterer Krärung an meinen Vertriebs- und Servicepartner wenden solleHeilberger hat geschrieben:Nachtrag! Frage: wie oft Reorganisieren??
Die Frage ist doch: was können wir selber in der täglichen Arbeit prüfen, es gibt in Menü "Wartung" ja einige Prüfläufe. Leider bekommt man kaum Informationen, wie man mit dem Ergebnis umgehen soll.
Vielen Dank schon mal für die Antworten. Ich bin ab heute 2 Wochen unterwegs ohne Internet, bin aber sehr auf die weiteren Reaktionen gespannt.
-
- Beiträge: 574
- Registriert: Sonntag 26. Oktober 2008, 09:15
- 15
- Hat sich bedankt: 4 times
- Bedankt: 21 times
Re: DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Interessant wäre auch zu analysieren, was zu Fehlern führt. Mir fällt folgendes ein:
- Programmabstürze von Turbomed
- Rechner einfach hart ausschalten
- in der Software nicht korrekt abgefangene Fehler beim Datenbankzugriff
- Fehler in Update-Routinen
- Fehlerhaftes Caching der Datenbank
- RAM-Fehler (wird ECC verwendet?)
- inkonsistente Datensicherungen mit anschließender Wiederherstellung
Bedien- und Eingabefehler sollten nicht zu solchen Problemen führen.
Für die 3 der Punkte kann CGM nix
Grüße
lcer
- Programmabstürze von Turbomed
- Rechner einfach hart ausschalten
- in der Software nicht korrekt abgefangene Fehler beim Datenbankzugriff
- Fehler in Update-Routinen
- Fehlerhaftes Caching der Datenbank
- RAM-Fehler (wird ECC verwendet?)
- inkonsistente Datensicherungen mit anschließender Wiederherstellung
Bedien- und Eingabefehler sollten nicht zu solchen Problemen führen.
Für die 3 der Punkte kann CGM nix
Grüße
lcer
-
- Beiträge: 463
- Registriert: Dienstag 9. Februar 2016, 15:17
- 8
Re: DB-Reorganisation/-Reparatur/-Konsistenzprüfung?
Ich denke ein Turbomed.exe /reorg ist evtl. nicht der Richtige Ansatz.
Bitte mal die anderen Optionen in der TM Anleitung Sonstiges/Informationen/Gebrauchsanweisung Suchbegriff Turbomed.exe ansehen.
Ich denke /CheckDB prüft die FOS Intensiver, als sie nur neu zu reorganisieren.
Aber alles unter Ihrer eigenen Verantwortung und Ausschluss jeglicher Haftung meinerseits !
Bitte mal die anderen Optionen in der TM Anleitung Sonstiges/Informationen/Gebrauchsanweisung Suchbegriff Turbomed.exe ansehen.
Ich denke /CheckDB prüft die FOS Intensiver, als sie nur neu zu reorganisieren.
Aber alles unter Ihrer eigenen Verantwortung und Ausschluss jeglicher Haftung meinerseits !
Wer ist online?
Mitglieder in diesem Forum: Google [Bot], Semrush [Bot] und 40 Gäste