Datenbank bereinigen

Die Navision-Datenbank kennt nur eine Richtung: Wachsen! Diesem Verhalten sollte (muss!) man aber auch einmal Einhalt gebieten. Eine Datenbankverkleinerung ist aber nicht so mit einem Fingerschnips gemacht. Und je nachdem ob Sie den SQL server einsetzen (Seit Navision Dynamics 2013 sowieso pflicht) oder den nativen Datenbankserver einsetzen, ist die physikalische Datenbankverkleinerung auch noch unterschiedlich durchzuführen.

Fast immer gilt aber, das Sie vor einer Verkleinerung der Datenbankdateien ohnehin erst einmal Daten löschen müssen, um überhaupt eine kleinere DAtenbank zu ermöglichen. Sonst ist das verkleinern der dAtenbank schlicht nicht möglich, irgendwo müssen die ganzen Datensätze ja abgelegt werden.

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

Suchen Sie eigentlich nach einer Möglichkeit, Benutzer in Navision / Business Central zu löschen um sich z.B. Zugang auf eine Datenbanksicherung zu verschaffen?

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 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 (20…21…22…)! Unterschätzen Sie den dabei anfallenden Suchaufwand (Zeitaufwand) Ihrer Anwender nicht! Dies kann die allgemeine Navision-Performance (Arbeitsgeschwindigkeit) noch wesentlich mehr verschlechtern als alle anderen Bremsen in Ihrem SQL-Server!
• Arbeitsfluss
  Hunderte, tausende oder gar 10-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. Dabei ist die DSGVO ein echtes Mienenfeld! 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 02.01.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, die Personendaten von diesem Vorgang weiter zu speichern! Entweder Sie entfernen die Personendaten aus diesem Beleg (Rechnungsempfänger, IP-Adresse…) und alle damit verbundenen Belege (Lieferscheine, Versandaufkleber, Warenstatistik, Verkäuferabrechnungen…), oder Sie löschen schlicht alle Belege spätestens nach Ende der Archivierungspflicht. Ich empfehle das komplette Löschen, weil dies auch die anderen hier aufgezählten Vorteile mit sich bringt.
• Fiskalisch
  Tatsächlich auch praktisch niemandem bekannt: Für die GDPdU müssen Sie -auf Anforderung- alle in Ihrem Navision oder Business Central 365 bereitstehenden 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 allein 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 belegt 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 soll man denn dann eine Navision-Datenbank bereinigen?

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

• Ausgeben von Deb/Kred/SK-SuSa & Lagerbestandslisten, für die spätere Kontrolle, ob nicht zu viel gelöscht wurde
• Änderung der Programmlogik in Ihrem Navision bzw. Business Central, damit auch Postentabellen bei den folgenden Bereinigungen wirklich abgebaut / entfernt / gelöscht 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 als 3 Jahre, 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 als 7 Jahre werden automatisiert gelöscht. Dabei sorgen meine Änderungen dafür das auch ungedruckte gelöscht werden. Hierdurch können Sie oft endlich wieder mit STRG+Ende sofort und ohne Suchen wieder den neuesten Navision-Lieferschein – wenn Sie z.B. mit Nummernserien wie L99xxxx gearbeitet haben, die das bisher verhinderten.
• Rechnungen älter als 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/aktuelle gebuchte Business Central Rechnung finden – wenn Sie z.B. mit Nummernserien wie R99-xxxx gearbeitet haben, die das bisher verhinderten.
• Debitorenposten, Kreditorenposten, Sachposten älter als 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 vorhandenen 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. Alle Zeiträume werden noch einmal mit Ihnen abgestimmt! Hierbei wird auch stichprobenartig überprüft, ob Ihre Gebuchten Belege danach noch ausgedruckt werden können. Schlechte Programmierung verhindert das überraschend oft. In diesem Fall ist abzustimmen ob der Belegdruck angepasst wird oder der Lösch-Horizont. Gerade hier ist Ihre Mitarbeit sehr wichtig: Benutzen Sie virtuelle Artikel, Sachkonten oder Kunden? Z.B. als Dachgesellschaften, Notizsammler oder für Preisgruppen? Bei diesen Sätzen kann ich ohne ihre Hinweise nicht automatisiert feststellen, ob ich die löschen darf, weil uralt und keine Bewegungen drauf, oder ob diese wichtige Daten tragen, die nicht gelöscht werden dürfen.
• Je nach Version werden hierbei auch die Artikelausgleichsposten generell gelöscht (verschiedene Navisionversionen benötigen diese gar nicht – Business Central hingegen benötigt diese generell für existierende Artikel).
• 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!
• Beim ersten Komprimieren erfolgt noch ein (bei Bedarf mehrere) Testlauf, so dass Sie über das Ergebnis einmal drüber sehen können, bevor ich Ihre Echtdaten reduziere. Inkl. erneutem Druck und vergleich der eingangs erwähnten SuSa-Listen. Die nötigen Programme bleiben danach Bestandteil Ihrer Datenbank! Auf diese Weise kann ich dann zukünftig, wenn Sie das möchten, regelmäßig (jährlich) Ihre Datenbank erneut aufräumen.

Und wenn das bei mir so nicht passt?

In kurz: In aller Regel passt das, und (wirklich) unnötige Befürchtungen sind oft am Platz. Aber natürlich kann jeder Zeitraum, jeder Stammsatz, jede Löschung in Navision oder Business Central 365 individuell an Ihren Bedarf angepasst werden.

Hierbei ist es ganz besonders wichtig ihre Besonderheiten zu beachten! Haben Sie statistische oder aus anderen gründen relevante Debitoren/Kreditoren/Sachkonten/Artikel, welche keine oder nur alte Bewegungen haben, und trotzdem nicht gelöscht werden? Oder andere auffällige Abweichungen vom „Standard“, die bei nicht-löschen berücksichtigt werden müssen?

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 und 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 TableName
  FROM sysindexes WHERE indid IN(1,2,255) ORDER BY used DESC

Sehr sehr sehr gerne werden hier die Änderungsprotokollposten sehr weit oben angezeigt. Faustformel: Änderungsprokollposten sollten nur auf Stammdaten benutzt werden. Z.B. auf Artikelstammdaten (Tabelle 27), Debitorenstamm (Tabelle 21), Zahlungsbedingungen, Lieferbedingungen usw.
Die klassische Fragestellung, welche das Änderungsprotokoll beantworten soll und kann, ist in der Art: „Wer hat bei Müller die Rufnummer geändert?“ oder „Wer hat bei Artikel 4711 den VK-Preis von 6,90 auf 5,80 geändert?“. Standard Navision würde nur „Geändert am“ und „Geändert von“ in verschiedenen, wenigen Stammdatentabellen speichern.
Benutzt man die Änderungsprotokollposten falsch, z.B. um Bewegungsdaten zu protokolieren, dann platzt Ihnen das Änderungsprotokoll schnell aus allen Nähten, und damit auch Ihre Datenbank.

Die Größe des Transaction-Logs findet man im MSSMS unter den Eigenschaften der jeweiligen Datenbank. Es gibt kein transactionlog, wenn Sie mit der nativen Datenbank von Navision bis zur Version 20090R2 arbeiten. 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 passt diese Regel. 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.

Verkleinern der Datenbank-Dateien

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

Bei der nativen Datenbank (Classic Client) 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 selbst bei Bedarf die Navision Datenbank-Dateien 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 Indizes (Index Defrag) gehört zu 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, dass 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) Datenbank-Dateien auch der effektive Datenzugriff von Navision oder Business Central, da die Festplattenköpfe nun kürzere Wege zurücklegen 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 Festplatte. 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 heißt es nicht: „Viel hilft 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 dass 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“.

Voraussichtliche Lesedauer: 15 Minuten