Aufruf der Maske:
Anwendung - Optionen - Reorganisations-Nachtlauf
Eine Auflistung aller relevanten Firmenparameter für diese Maske erhalten Sie über die Tastenkombination <Alt+F1>. Wenn Sie Änderungen an den Einstellungen der Parameter vornehmen möchten erreichen Sie die Tabelle über Anwendung - Stammdaten – Parameter – Firmen-Parameter-Standard:
LIVEPATCH |
Download Methode für den Patch-Download |
Trägt man im Firmenparameter LIVEPATCH im numerischen Wert 1 eine "3" ein, so wird der Reorg via HTTPS ausgeführt. |
REORG01 |
Version der Daten-Reorganisation |
Die Datenreorganisation wurde überarbeitet und steht ab sofort in 2 Varianten zur Verfügung. Über den Firmenparameter REORG01 kann pro Mandant entschieden werden, welche Reorg-Variante genutzt wird.
Variante 1: Wie bisher, allerdings wurden sämtliche Meldungen angepasst und werden nun nach dem Abschluss aller Reorganisationen als Tabelle angezeigt.
Variante 2: Neuer Ablauf, hierbei kommt dem dbfsReorg-Ordner nur eine untergeordnete Rolle. Diese Form des Reorgs läuft sowohl schneller als auch sicherer. Über ein externes Programm kann der Parameter für alle Mandanten auf den erwünschten Wert eingestellt werden. Wenden Sie sich hierfür bitte an unsere Hotline! Vor dem Start der Maske werden viele mögliche Probleme geprüft, so dass während der Reorganisation keine Rückfragen beim Anwender auftreten. Zudem gibt es die Möglichkeit, eine beschleunigte Reorganisation durchzuführen, indem die Datensatzüberprüfung bzw. Lagerneuermittlung komplett deaktiviert wird.
Wenn der Firmenparameter REORG01 im numerischen Wert auf 1 (Klassische Reorganisation) eingestellt ist, werden in Zukunft die Sicherungen des Mandantenverzeichnisses nicht mehr in den Ordner "Alt"+Mandantennummer verschoben, sondern in ein Verzeichnis mit dem Aufbau "Alt"+Mandantennummer+Datumsstempel.
Reorganisations-Nachtlauf: Die neue Version des Reorganisationsnachtlaufs wurde aufgrund diverser Probleme ab der Version 34.0 deaktiviert, es wird standardmäßig wieder der "alte" Reorganisationslauf verwendet, unabhängig der Einstellung im Firmenparameter REORG01. |
REORG02
|
Speicherplatzprüfung vor Reorg |
Über den Parameter REORG02 kann gesteuert werden, ob vor dem Reorg eine Speicherplatzprüfung durchgeführt wird, ob ausreichend Festplattenspeicher für eine Reorganisation vorhanden ist. |
REORG03 |
Vor Reorg: Prüfung auf akt. Patch |
Der Firmenparameter REORG03 steuert, ob vor dem Start der Reorganisation immer geprüft wird, ob der aktuellste Majesty-Patchstand installiert ist. |
Automatische Reorganisation nach Update bzw. Patch:
Die Majesty Version 39.2 ist die letzte Version, bei der nach einem Update ein Reorganisations-Nachtlauf durchgeführt werden muss. Für alle Patches und Updates nach dieser Version findet nach Installation ein vollautomatischer Datenbankupdate für alle Tabellen statt, die Änderungen seit dem letzten Update/Patch erfahren haben. Zwar müssen hierfür auch alle Anwender das System verlassen, aber die Datenbankaktualisierung dauert nur recht kurz und erspart einen aufwändigen Reorganisations-Nachtlauf.
Wir empfehlen für zukünftige Updates/Patches folgende Vorgehensweise:
1. Beenden aller Majesty-Instanzen aller User, z.B. durch die Zwangsbeendigung.
2. Installation des Updates/Patches durch einen Administrator.
3. Start von Majesty -> Die Datenbankaktualisierung wird gestartet.
4. Wechsel in alle häufig benötigten Mandanten, damit diese auch sofort aktualisiert sind.
5. Aufheben der Zwangsbeendigung.
Ein Reorganisations-Nachtlauf ist weiterhin sinnvoll und empfiehlt sich von Zeit zu Zeit bzw. wenn gelöschte Sätze endgültig entfernt werden sollen oder wenn Datenbankprobleme auftreten. Er ist jedoch nicht mehr bei einem Update/Patch nötig.
Die technische Funktionsweise hierbei ist, dass im Firmenparameter REORG04 im "Wert 1" steht, welches Aktualisierungs-Skript zuletzt ausgeführt wurde. Der Parameter wird automatisch vom System verwaltet und darf nicht vom Anwender geändert werden (außer nach Rücksprache mit der Hotline).
Steht hier z.B. eine 3, bedeutet dies, dass das 3. Aktualisierungs-Skript zuletzt durchgeführt wurde. Die Skripts selbst stehen in der Tabelle INSTALL11, die im Majesty-Server-Stammordner liegt und bei jedem Update/Patch aktualisiert ausgeliefert wird. Wird nun durch ein Update/Patch die INSTALL11-Tabelle aktualisiert, prüft Majesty beim Aufruf eines Mandanten, ob neue (noch nicht ausgeführte Skripts) hinzugekommen sind, die noch abgearbeitet werden müssen. Die Abarbeitung/Durchführung der Skripts geschieht vollautomatisch, indem der entsprechende Datenbankordner zunächst umbenannt wird, eine Sicherung der betroffenen Tabelle erstellt wird, das Skript ausgeführt wird und danach der Datenbankordner wieder zurückbenannt wird.
Datensicherung:
Im jeweiligen Mandantenordner wird eine ZIP-Datei mit nur denjenigen Tabellen angelegt, die durch dieses Datenbankskript verändert wurden. Ein Beispiel für eine Zip-Datei ist wie folgt:
kostst_backup3_20241023.zip
Hierbei ist kostst die Kostenstellentabelle, backup3 bedeutet dass dies eine Datensicherung ist, BEVOR das Skript Nummer 3 ausgeführt wurde und 20241023 ist das Datum der Sicherung.
Protokollierung:
Eine Logdatei mit den Namen reorglog_skripts_xxxx.txt wird automatisch im Majesty-Server-Stammordner angelegt, wobei xxxx für das Jahr steht. In dieser Textdatei ist ersichtlich, ob Datenbankskripts erfolgreich ausgeführt wurden oder nicht. Ein Skript ist dann nicht erfolgreich ausgeführt, wenn z.B. die Tabelle oder neue Datenbankfelder bereits existieren. Dies deutet darauf hin, dass im Firmenparameter REORG04 ein zu geringer Wert stand oder dass ein Anwender einen Reorganisations-Nachtlauf durchgeführt hat und deswegen die Skripts nicht mehr erforderlich waren. Im Protokoll stehen neben Datum, Uhrzeit, Usernummer und Username auch die Mandantennummer und das Ergebnis.
Vorgehensweise/Ablauf:
Von Zeit zu Zeit, es gibt hier keine festen Regeln, können alle Dateien des Systems reorganisiert werden; d. h., die Indexdateien, über die der Suchvorgang in Datenbankabfragen gesteuert wird, werden neu aufgebaut. Gleichzeitig werden temporäre Dateien, die aufgrund von Systemabstürzen entstehen, gelöscht.
Die Zugriffsgeschwindigkeit wird dadurch erhöht und das System ein wenig schneller als zuvor. Aber es ist nicht nur wegen der Geschwindigkeit, dass Reorganisationen notwendig sind; die Datensicherheit wird dadurch auch erhöht und Zugriffsfehler vermieden.
ACHTUNG: Die Reorganisation der Dateien kann nur durchgeführt werden, wenn alle anderen Teilnehmer außer Ihnen abgemeldet sind!
Dies muss vor jeder Reorganisation unbedingt gewährleistet sein, da sonst DATENVERLUSTE auftreten können, weil die Reorganisation nicht korrekt durchgeführt werden kann. Sollte ein Benutzer während eines Reorganisationslaufes versuchen Majesty zu starten erscheint die Meldung, dass Majesty wegen Wartungsarbeiten gesperrt ist.
ACHTUNG: Ab der Version 31.0 von Majesty kann eine Reorganisation außerdem nur gestartet werden, wenn zuvor der aktuellste Patch installiert wurde, siehe Patches für MAJESTY suchen
Über den Parameter REORG01 können Sie zwischen zwei Arten wählen:
der neue Reorganisationslauf benötigt eine kürzere Laufzeit, vor allem bei reinem Update und die Stabislität wird erhöht.
Es erfolgen umfangreichere Prüfungen vor und während des Reorgs, Sie können entscheiden, ob einzelne Bestandteile des Reorgs durchgeführt werden sollen (Dateiprüflauf, Lagerneuermittlung, Index neu schreiben).
Meldungen zum Reorg werden nicht mehr einzeln angezeigt sondert gesammelt am Ende des Laufes.
Da eine Reorganisation je nach Datenbestand auch sehr lange dauern kann, empfiehlt es sich, die Reorganisation nach Feierabend durchzuführen.
Die Einzelne Reorganisation ist wichtig, wenn Sie z.B. einen Stromausfall oder einen Absturz hatten, während Sie in einer Datei arbeiteten (z.B. LIEFKO, AUFKO usw.) oder das Programm nicht ordnungsgemäß beendet haben. In den meisten Fällen wird diese Datei dann unbrauchbar und kann vom System nicht mehr gelesen werden. Sie erhalten dann eine Meldung „keine Tabelle/DBF...." und Majesty wird abgebrochen. Um nun keinen Nachtlauf durchführen zu müssen (der unter Umständen sehr lange dauert) können Sie diese eine Datei auch einzeln reorganisieren. Meist kann eine defekte Datei problemlos repariert werden, allerdings fehlen oftmals die letzten Datensätze - das sollten Sie anschließend manuell überprüfen.
Bei beiden Reorganisationsmöglichkeiten findet eine Prüfung statt, ob die Datenbank(en) im Zugriff ist (sind), damit Probleme dadurch ausgeschlossen werden können.
Der Reorganisations-Nachtlauf dient der Komplettreorganisation ALLER Majesty-Dateien. Gelöschte Datensätze werden hierbei endgültig entfernt, wodurch Speicherplatz frei wird und Dateizugriffe wieder schneller werden.
Nach einer Update-Installation ist IMMER eine Komplett-Reorganisation nötig!
Bei aktiver Majesty.APP (separates Modul) erscheint im Vorfeld ein Hinweis mit der Empfehlung den Majesty-Query-Service während des Reorganisations-Nachtlaufs zu deaktivieren.
Button "Nur Neuindizierung":
Eine reine Neuindizierung geht schneller und wird nur benötigt, wenn Indexfehler gemeldet werden.
Checkbox "Vor Reorg. Datensicherung als ZIP-Datei durchführen (empfohlen)":
Das Häkchen ist standardmäßig gesetzt beim Start eines Reorganisations-Nachtlaufes. Es wird empfohlen eine zip-Datei zu erstellen um eine aktuelle Datensicherung des Mandanten vorliegen zu haben.
Ist bei einem Reorganisations-Nachtlauf der Haken für die Datensicherung gesetzt wird überprüft, ob die DASI-Datei erstellt wurde und ob sie evtl. zu klein ist. Ist die DASI-Datei nicht vorhanden oder liegt deren Größe unter 1 MB, so wird der Reorganisations-Nachtlauf nicht gestartet.
Die erstellten Datensicherungsdateien (Zip-Dateien) werden nach einem Zeitraum von 31 Tagen vom System automatisch gelöscht.
Checkbox "Reorg. nach Update - Keine Reparaturfunktion!": Hier kann der Reorganisations-Nachtlauf ohne ausführliche Reparaturfunktion gestartet werden, was zu einen schneller Ablauf der Reorganisation führt. Dies bietet sich immer an, wenn z.B. auf Grund eines Updates reorganisiert werden muss.
Checkbox "nur neue Indices schreiben":
Diese Option ermöglicht eine schnellere Reorganisation der Daten. Falls ein Index defekt ist, sollte eine Reorganisation ohne dieses Häkchen erfolgen, ansonsten kann das Häkchen gesetzt werden, um Zeit zu sparen.
Diese Option ist nur verfügbar, wenn der Firmenparameter REORG01 auf 2 steht.
Pfad für Sicherungsdateien: Hier wird der Pfad für die Datensicherungen angezeigt. Über den Button "Öffnen" kann der Ordner direkt geöffnet werden. Der Pfad für die Datensicherung lässt sich über den Button "..." ändern.
Button "Reorg.: aktiver Mandant(xxx).
Hier folgt eine Komplett-Reorganisation und eine Neu-Indizierung des aktiven Mandanten.
Button "Reorg.: nach Update - alle unreorganisierten Mandanten.
Über diesen Button werden alle vorhanden Mandanten, bei denen nach einem Update noch keine Reorganisation erfolgte, komplett reorganisiert.
Button "Reorg.: mit Mandantenauswahl.
Es erscheint eine Tabelle mit allen Mandanten, in der Sie tabellarisch in der Spalte "Reorganisieren" entscheiden können, für welche Mandanten der Lauf gestartet werden soll.
Button "Nur Neuindizierung":
Bildet neue Indexdateien für schneller Zugriffe.
Wenn Sie die Reorganisation starten, folgen Sie den Anweisungen auf dem Bildschirm. Sobald die einzelnen Dateinamen angezeigt werden (beim Nachtlauf), hat die Reorganisation begonnen und es werden keine Eingaben mehr von Ihnen erwartet.
ACHTUNG: Eine einmal gestartete Reorganisation darf nicht abgebrochen werden!!!
Wenn die Reorganisation im Stapel für alle Mandanten durchgeführt wird und bei der Lagerneuermittlung Fehler auftreten, werden diese am Ende der gesamten Reorganisation angezeigt.
Ebenso wird in der Titelleiste der Reorganisations-Maske der Mandant, der aktuell bearbeitet wird, angezeigt.
Der Reorganisations-Nachtlauf wurde ab der Version 37.0 dahingehend angepasst, dass Majesty den Hauptordner (dbfs.xxx) in einen Temp-Ordner (dbfstemp.xxx) umbenennt. So wird sichergestellt, das während der Reorganisation keine Fremdsoftware auf die Datenbank zugreifen und es dadurch zu Problemen kommen kann. Nachdem die Reorganisation beendet ist, wird der Temp-Ordner wieder in den ursprünglichen dbfs-Ordner umbenannt.
Besonderheiten:
Ab Version 26.8:
Bisher wurde immer ein ALT-Ordner angelegt, wenn sich ZIP-Dateien in den dbfs-Datenordnern befanden. ZIP, RAR und Bilddateien werden nun bei der Reorganisation als gültige Dateien erkannt und mit in den reorganisierten Ordner übernommen.
Maschinendatenerfassung mit unserem Partner FS:
Beim Starten des Reorganisationslaufes wird überprüft, ob MDE vorhanden ist. Wenn ja wird zunächst abgefragt, ob die Schnittstelle im MDE-System abgeschaltet ist. Wenn dies mit Nein beantwortet wird, wird der Reorganisationslauf abgebrochen.
Bemerkung: Es ist wichtig, dass die MDE-Schnittstelle während eines Reorgs nicht aktiv ist, da es sonst zu Datenverlusten kommen kann.
Die Kompressionsrate der Datensicherungsroutine kann nun über den Firmenparameter DASI01 konfiguriert werden, so dass die Datensicherung schneller performanter ablaufen kann.
Ab der Version 30.0 von Majesty wird in der Mandantentabelle protokolliert, welcher Mandant mit welcher Majesty-Version reorganisiert wurde.
Vor dem Start der Maske werden viele möglichen Probleme geprüft, so dass während der Reorganisation keine Rückfragen beim Anwender auftreten.
Zudem gibt es die Möglichkeit eine beschleunigte Reorganisation durchzuführen, indem die Datensatzüberprüfung komplett deaktiviert wird.
Falls die Zwangsbeendigung gestartet wurde, erscheint nach einem erfolgreichem Reorganisationslauf die Abfrage, ob die Zwangsbeendigung ebenfalls beendet werden soll.
Links: Fehler-Protokoll, Daten-Integritätsprüflauf,
11/2024