Datenbank bereinigen

Navision · Shopware · App

Die Navision-Datenbank kennt nur eine Richtung: Wachsen! Diesem Verhalten sollte (muss!) man aber auch einmal Einhalt gebieten.

Übrigens… Auch im ganz altem blauen DOS Navision 3.56 können Sie Daten löschen!

Warum Daten in Navision löschen?

Es gibt gute Gründe dafür, eine Navision-Datenbank zu bereinigen / komprimieren / verkleinern. Und auch zum Löschen nicht mehr benötigter Daten:

  • Suchgeschwindigkeit
    Je weniger Datensätze Navision durchsuchen muss, desto schneller können Suchen oder Filter ein Ergebnis liefern. Das macht in dem einzelnen Vorgang bei Navision pro Benutzer oft eine kaum erkennbare Verzögerung oder tolerierbare wenige Sekunden. Insgesamt aber bremst es den Business Central SQL Server insgesamt aus und verzögert für die ganze Firma, für alle Mitarbeiter immer wieder merklich oder unmerklich den Arbeitsfluss.
    Richtig nervig wird es, wenn man
    -den neuesten Lieferschein aus Navision
    -die aktuellste Bestellung aus Business Central
    -Die letzte Rechnung von Business Solutions NAV
    sucht: Eigentlich einfach nur STRG+Ende, und ich stehe auf dem neuesten Beleg. Nicht so, wenn man die Belegnummern nach Jahren formatiert (LS99.12345), und dann z.B. in 1999 angefangen hat. Dann versperren Belege, welche mit 99… anfangen, den Blick auf die aktuellen Belege! Unterschätzen sie den dabei anfallenden Suchaufwand (Zeitaufwand) Ihrer Anwender nicht! Dies kann die allgemeine Navision-Performance (Arbeitsgeschwindigkeit) noch wesentlich mehr verschlechtern als alle andere Bremsen in Ihrem SQL-Server!
  • Arbeitsfluss
    Hunderte oder gar tausende von nicht mehr / nie mehr benötigten Navision-Belegen (Lieferscheine, Rechnungen, Angebote) und nie wieder benötigten Business Central Stammdaten wie Kunden (Debitoren), Lieferanten (Kreditoren), Artikel und Sachkonten hindern den Arbeitsfluss. Ist jetzt der Müller Schulze oder der Müller Schultze der richtige Kunde? Ach, schon wieder den falschen ausgewählt… Und auch hier leidet die Performance ihrer Mitarbeiter viel mehr als durch kurze, oft nicht bemerkbare Wartezeiten auf die Navision-SQL-Datenbank.
  • Verwaltungszeit
    Bei Datenbank-reorganisationen von nativen Navision Datenbanken, beim Schlüssel optimieren von Business Central SQL-Datenbanken, bei Datensicherungen, Datenwiederherstellungen, Erstellen von Testumgebungen, replizieren von Datenbankänderungen bei Hochverfügbarkeitssystemen: Immer wieder werden Gigabyte-weise unnötige Daten über die meist eh schon chronisch überlasteten Netzwerkleitungen gequetscht. Auch das drückt die Performance ihrer Datenverarbeitung ganz enorm. Bandsicherungen brauchen immer länger, Festplattensicherungen immer mehr Kapazität. So macht sich eine unnötig große Navision (SQL) Datenbank oder Business Central SQL Datenbank auch in Heller und Pfennig bzw. Euro bemerkbar.
  • DSGVO
    Dieser Punkt wird praktisch immer vergessen. Ihre gesetzliche Archivierungspflicht für die Finanzbehörden (GDPdU) endet mit Ablauf des 10.Jahres nach der letzten steuerlich relevanten Buchung. Wird z.B. eine Rechnung vom 31.12.2010 am 2.1.2011 mit Skonto bezahlt, so läuft die Archivierungspflicht der Zahlung mit dem 31.12.2021 ab. Damit läuft auch die Archivierungspflicht für die Rechnung, und damit für die damit verbundenen personengebundenen Daten ab. Sie haben schlicht kein Recht mehr diesen Beleg mit den Personendaten weiter zu speichern! Entweder sie entfernen die Personendaten aus diesem Beleg (Rechnungsempfänger, IP-Adresse…) und allen damit verbundenen Belegen (Lieferscheine, Versandaufkleber, Warenstatistik, Verkäuferabrechnungen…), oder Sie löschen schlicht alle Belege spätestens nach Ende der Archivierungspflicht.
  • Fiskalisch
    Tatsächlich auch praktisch niemanden bekannt: Für die GdPdU müssen Sie -auf Anforderung- alle in ihrem Navision oder Business Central bereit stehenden Daten bereit stellen/ausgeben! Auch z.B. Rechnungsdaten zu Belegen/Vorgängen in Business Central, welche deutlich älter als 7 Jahre bei Lieferscheinen oder 10 Jahren bei Rechnungen und anderen Umsätzen sind! Ausnahme: Sie haben diese Daten nicht mehr vorrätig. Schon alleine aus diesem Grund sollten Sie eine gewisse Datenhygiene in ihrer Navision-Datenbank beachten.

Warum nicht einfach Daten löschen?

Leider können Sie in Navision/Business Central nicht einfach so eine große Menge nicht mehr benötigter Daten löschen. Für erledigte Aufträge gibt es noch fertige Routinen („Erledigte Aufträge löschen“), das gleiche für Einkaufsbestellungen („Erledigte Bestellungen löschen“). Navision Angebote und Business Central Einkauf Anfragen können Sie noch direkt über die Tabellen recht einfach und schnell löschen: Tabelle 36 bzw. 38: Run, Filter setzen, alle markieren & mit STRG+a, Löschen. Bei Debitoren & Artikeln werden die zugehörigen Postentabellen (21 Debitorenposten/Cust. Ledger Entry, 25 Kreditorenposten/Vendor Ledger Entry, 32 Artikelposten/Item Ledger Entry, 5802 Wertposten/Value Entry) leider schon lange nicht mehr mitgelöscht. Dies wird mit der Statistik-Kontinuität begründet.

Auch gerne übersehen: Tabelle 405 Änderungsprotokollposten/Change Log Entry. Hier genügen schon kleine Fehler bei der Einrichtung des Änderungsprotokolls, um die Navision/Business Central Datenbank mit sinnlosen Daten regelrecht zu fluten. Ich habe im laufe meiner Navision Programmierer und Beraterzeit wirklich viele Systeme entdeckt, bei denen das Changelog mal eben 80% einer Riesendatenbank beelgt hat – ganz ohne weitere Verwendung!

Und von „Normalen“ Anwendern gar nicht beeinflussbar: 339 Artikelausgleichsposten/Item Application Entry. In Navisionversionen vor 2009 braucht man diese Tabelle gar nicht, man kann ihren Inhalt praktisch folgenlos komplett entfernen.

Je nach Navision/Business Central Version müssen die einen Einträge gelöscht, die anderen Einträge aber komprimiert (verdichtet) werden, um z.B. die Sachkontensalden oder Artikelbestände nicht zu beschädigen (konsistent zu halten).

Wie denn dann eine Navision-Datenbank bereinigen?

Ich unterstütze Sie beim Aufräumen/Verkleinern/Bereinigen Ihrer Navision-Datenbank mit folgenden Vorgängen:

  • Änderung der Programmlogik in ihrem Navision / Business Central, damit auch Postentabellen bei den folgenden Bereinigungen wirklich abgebaut werden.
  • Dabei werden auch abhängige Tabellen wie z.B. 379 Detaillierte Debitorenposten / Detailed Cust. Ledg. Entry und 380 Detaillierte Kreditorenposten / Detailed Vendor Ledg. Entry mit bereinigt.
  • Angebote älter 3 Jahren, erledigte Aufträge werden gelöscht. Dabei gehen meine Routinen weiter als die Standard-Navision Routinen und erkennen mehr erledigte Aufträge. Das gleiche findet auch im Einkauf statt. Faustformel: Aufträge älter als 2 Jahre sollten nicht mehr geliefert werden, sie würden eher für Irritationen oder Lacher auf Kundenseite sorgen…
  • Einkauf- und Verkauf Lieferscheine älter 7 Jahre werden automatisiert gelöscht, dabei ist es irrelevant ob Sie schon gedruckt wurden oder nicht. Hierdurch können Sie dann auch endlich wieder mit STRG+Ende sofort und ohne Suchen wieder den neuesten Navision-Lieferschein finden – wenn Sie z.B. mit Nummernserien wie L99xxxx gearbeitet haben, die das bisher verhinderten.
  • Rechnungen älter 11 Jahre werden gelöscht (Sie haben eine Archivierungspflicht / GdPdU-Pflicht für fiskalisch relevante Bewegungen für 10 Jahre nach Abschluss der Buchungsperiode! Daraus ergeben sich die 11 Jahre). Hiermit können Sie dann auch endlich wieder mit STRG+Ende sofort wieder die letzte/aktuellste gebuchte Rechnung finden – wenn Sie z.B. mit Nummernserien wie R99-xxxx gearbeitet haben, die das bisher verhinderten.
  • Debitorenposten, Kreditorenposten, Sachposten älter 11 Jahre werden komprimiert. Dafür wird, je nach Navision-version, die Komprimierung korrigiert. Dies gilt auch für die Artikelposten, wenn Ihr Navision das noch zulässt. Ansonsten wird aber auch schon über die echte Löschung der Artikelposten und Wertposten bei nicht mehr relevanten Artikeln viel Platz gespart.
  • Nach den obigen Verdichtungen werden veraltete (lange nicht genutzte) Kunden/Lieferanten/Sachkonten/Artikel ebenfalls inkl. ihrer Posten aus der Datenbank entfernt. Bei Kunden/Lieferanten/Artikeln gehe ich dabei von 5 Jahren aus. Sachkonten können natürlich erst nach den 11 Jahren gelöscht werden, wenn also keine oder nur komprimierte Posten dazu vorhanden sind.
  • Beim Einsatz des Microsoft SQL Servers kommt noch die Überprüfung des TransactionLOG hinzu. Es gibt -leider- noch immer viele Systemhäuser und/oder Hobbyprogrammierer, die eine Navision-Datenbank (oder genereller: Eine SQL-Datenbank) „Sichern“, indem sie den ganzen Server, z.B. mit dem Microsoft Backup oder mit Veeam sichern. Oder den kompletten virtualisierten SQL Server als ganzes oder -super intelligent- „inkrementell“ sichern. Das ist keine von Microsoft autorisierte oder auch nur empfehlenswerte Datensicherung für eine MS-SQL-Datenbank. Ganz egal ob für Navision, Business Central oder jede andere Applikation auf dem SQL Server! Wenn man dann auch noch das Wiederherstellungsmodel auf Vollständig stellt (was aus vielen Gründen durchaus empfehlenswert ist, z.B. für alle 5 Minuten-Backups in Hochverfügbarkeitsumgebungen), dann läuft einem das Transaction-Log voll. Kein Wunder: Es wird ja nie kontrolliert geleert! Mein persönlicher Rekord war eine Navision-Datenbank mit 7 Gb Nutzdaten (unbereinigt) und 67 Gb Transaction-Log. Das ist dann vielleicht schon nicht mehr fahrlässig, sondern vielleicht Vorsatz!

Und wenn das bei mir so nicht passt?

In Kurz: In aller Regel passt das, und (wirklich) unnötige Befürchtungen sind schlicht fehl am Platz. Aber natürlich kann jeder Zeitraum, jeder Stammsatz, jede Löschung individuell an ihren Bedarf angepasst werden.

Wie finde ich die größten Platzverschwender heraus?

Im nativen Navision bis Version 2009R2 ganz einfach: neue Form (Page), Table 2000000028 Tabelleninformation / Table Information, Preview (Speichern nicht nötig). filtern auf Größe (KB) > 1000000 (1Gb, mit kleineren Tabellen muss man sich in der Regel nicht beschäftigen).
Unter MS-SQL (Navision / Business Central mit dem SQL Server) mit diesem kleinen Script zur Abfrage der Tabellengröße:

USE Name-Der-Navision-Datenbank
GO
SELECT TOP 50 
  used AS "Pages",
  rows AS "Saetze",
  (used * 8) / 1024 AS "MB",
  CAST(OBJECT_NAME(id) AS CHAR(100)) AS Table
  FROM sysindexes WHERE indid IN(1,2,255) ORDER BY used DESC

Die Größe des Transaction-Logs findet man im MSSMS unter den Eigenschaften der jeweiligen Datenbank. Faustformel: Transaction-Logs mit einer Größe über 1 Gb oder einer Größe > 2 % der Nutzdatenbank sind ein Zeichen von Pfusch. Das stimmt nicht immer, z.B. kann das Transactionlog auch einmal bei einer größeren Aktion aufgebläht worden sein, und wurde dann später nicht reduziert. Aber so gut wie immer. Hier hilft dann die „Used“ oder „Genutzt“ Information weiter. In Navision bis 2009R2 findet man die Datenbankgrößen für den SQL Server auch noch unter Datei/Datenbank/Ändern.

Screenshot Navision/Business Central SQL Datenbank Datenbankgröße und Transactionlog Größe
Abfrage Navision/Business Central SQL Datenbank Datenbankgröße und Transactionlog Größe
Screenshot vom Aufruf der SQL_Datenbank Informationen unter Navision 2009R2
Aufrufen der SQL_Datenbank Informationen unter Navision 2009R2

Anzeige der Datenbankgröße einer MS-SQL Datenbank unter Navision 2009R2
Anzeige Datenbankgröße einer MS-SQL Datenbank unter Navision 2009R2
Screenshot Transactionlog einer MS-SQL Datenbank unter Navision 2009R2
Anzeige der Transactionlog Größe einer MS-SQL Datenbank unter Navision 2009R2

Verkleinern der Datenbank-Dateien

Nach den Löschaktionen sind in den Datenbank Dateien oft mehr als 50% „Luft“.

Bei der Nativen Datenbank sollte nicht mehr als 15-20% leerer Platz aktiv sein. Je kleiner die Datenbank ist, desto schneller und kompakter sind die HotCopy Datensicherungen (Bei der logischen macht dies keinen Unterschied). Der Leere Platz sollte natürlich auch nicht ZU wenig sein, da die Datenbank ja wieder wachsen wird.

Bei der SQL-Datenbank kann Navision bzw. der SQL-Datenbankserver selber bei Bedarf die Navision Datenbankdateien oder die Transaction-Log Dateien erweitern. Daher können diese ruhig bis an das untere Limit verkleinert werden. Auch hier sorgt die Verkleinerung für schnellere und kompaktere Datensicherungen. Das Defragmentieren der der Indzies (Index Defrag) gehört u jeder Datenbankverkleinerung dazu! Aber in einer sauberen Navision-Datenbank haben Sie ohnehin periodische Prozesse zum Rebuild der Indizes (Index-Aktualisierung) und damit verbunden einen Index-Defrag (Defragmentieren der Indizes).

Aktivieren Sie bitte niemals die Option „Automatisch verkleinern“! Diese Option ist absolut Kontraproduktiv! Durch diese Option wird ihre Datenbank sehr stark fragmentiert – sie wird regelrecht „zerfleddert“ (zerfetzt)., die Indizes (Schlüssel) können dabei so stark defragmentiert werden das der SQL-Server auf deren Verwendung verzichtet!

Liegt die Datenbank auf Magnetfestplatten (Ich empfehle seit 2008 nur noch SSD’s), so beschleunigt sich bei kleineren (verkleinerten) Datenbankdateien auch der effektive Datenzugriff von Navision oder Business Central, da die Festplattenköpfe nun kürzere Wege zurück legen müssen. „Defrag“ nicht vergessen 🙂 . Wobei hier eher Einrichtungssünden (Raid5, mehrere Datenbankteile auf einer Platte, Transactionlog nicht auf einer separaten Platte…) für ein gebremstes Dynamics NAV/Navision/Business Central mit einer miserablen Performance sorgen. Praktisch kein Navision-Programmierer (oder Business Central Verwalter oder auch jeder andere Datenbank-Guru) hat damals, beim Einführen neuer und schnellerer und größerer Magnetfestplatten (So um das Jahr 2000 rum) verstanden warum die neue, ultramoderne 15.000er Festplatte mit 120 Gbyte soooo viel langsamer war als die 3 uralten 2 Gb HD’s mit 5.400 U/Min…. Bei dem Nativen Datenbankserver unter Navision konnten 5 oder 6 uralt HDD’s noch um Größenordnungen schneller sein als weniger/eine ultramoderne Fesxtplatte. Das hing mit den Tabellenaufbauten zusammen. Aber grundsätzlich gilt dieses Verhalten für jeden Datenbankprozess (Stichwort I/O Durchsatz).

Wie oft sollte man die Datenbank verkleinern?

Hier heist es nicht: „Viel hilf viel“. Die jährliche Verkleinerung und Defragmentierung im Rahmen der Datenhygiene reicht normalerweise aus. Ausnahme: In Ihrer Datenbank wurde echter Bockmist, z.B. im Zusammenhang mit dem Changelog (Änderungsprotokollposten) oder dem Transactionlog gemacht. Dann gehört das verkleinern (shrinken) und das Index-defragmentieren zu den Reparaturaufgaben dazu.

Ablauf der Datenbereinigung

Konkret sieht der Ablauf wie folgt aus:

  1. Ändern der Programmlogik, so das beim Löschen von Stammdaten auch die zugehörigen Posten gelöscht (und nicht nur auf Kontonummer „Leer“ werden.
  2. Drucken einer SuSa SK, Deb, Kred, Druck Lagerbewertung
  3. Aufrufen der Komprimierung für Sachposten (98), Debitorenposten (198), Kreditorenposten (398) und, wenn noch möglich, der Artikelposten.
  4. Lagerregulierung laufen lassen (Alternativ: Code anpassen das unregulierte Posten ignoriert werden)
  5. Klären was mit ungebuchten Artikelbuchblattzeilen passieren soll (-> Löschen)
  6. Anpassen (Lösch-Horizont) & Aufruf der (neuen) Funktion „Alte Daten löschen“