Ryd op i databasen

Navision-databasen kender kun til én retning: Vækst! Men man bør (skal!) også sætte en stopper for denne adfærd på et tidspunkt. En databasereduktion er dog ikke lige til at gøre med et fingerknips. Og alt efter om du bruger en SQL server (allerede et krav fra Navision Dynamics 2013) eller den oprindelige databaseserver, så skal den fysiske databasereduktion også udføres forskelligt.

Men det gælder næsten altid, at du først skal slette data, før du kan formindske databasedata for overhovedet at muliggøre en mindre database. Ellers er det simpelthen ikke muligt at formindske databasen, for hvor skal alle datasættene gemmes?

For resten... Du kan også slette data i den helt gamle blå DOS Navision 3.56!

Leder du efter en måde at slette brugere i Navision / Business Central for f.eks. at få adgang til en databasesikkerhedskopi?

Hvorfor slette data i Navision?

Der er gode grunde til at rydde op / komprimere / reducere en Navision-database. Og også til at slette data, der ikke længere er nødvendige:

• Søgehastighed
  Jo færre datasæt Navision skal søge igennem, jo hurtigere kan søgninger eller filtre give et resultat. Det mærkes næppe for den enkelte bruger i Navision, da forsinkelsen ofte bare er et par sekunder. Samlet set bremser det dog Business Central SQL serveren og forsinker arbejdsgange mærkbart eller ikke mærkbart for hele firmaet, for alle medarbejdere, igen og igen.
  Det bliver rigtigt irriterende, når man søger
  -den seneste følgeseddel fra Navision
  -den seneste ordre fra Business Central
  -den sidste faktura fra Business Solutions NAV
  : Egentlig bare Ctrl+End, og jeg er på den seneste kvittering. Ikke når du formaterer kvitteringsnumrene efter år (LS99.12345) og så f.eks. startede i 1999. Så blokerer kvitteringer, der starter med 99..., udsynet til de aktuelle kvitteringer (20...21...22...)! Undervurder ikke den tid, dine brugere skal bruge på at søge (tidsforbrug)! Dette kan forringe den generelle Navision-ydeevne (arbejdshastighed) væsentligt mere end alle andre flaskehalse i din SQL-server!
• Arbejdsgang
  Hundreder, tusinder eller endda titusinder af ikke længere/aldrig-igen-nødvendige Navision-bilag (følgesedler, fakturaer, tilbud) og aldrig-igen-nødvendige Business Central-stamdata som kunder (debitorer), leverandører (kreditorer), varer og konti, hindrer arbejdsgangen. Er det nu Müller Schulze eller Müller Schultze der er den rigtige kunde? Åh, valgte forkert igen... Og også her lider dine medarbejderes performance meget mere end ved korte, ofte ikke mærkbare, ventetider på Navision SQL-databasen.
• Administrativ tid
  Ved databasereorganiseringer af oprindelige Navision-databaser, ved nøgleoptimering af Business Central SQL-databaser, ved backups, gendannelser, oprettelse af Testmiljøer, replikering af databaseændringer i systemer med høj tilgængelighed: Igen og igen bliver gigabytes af unødig data mast igennem de som regel allerede kronisk overbelastede netværkslinjer. Dette nedsætter også ydeevnen af din databehandling enormt. Båndbackups tager altid længere tid, diskbackups kræver altid mere kapacitet. En unødvendigt stor Navision (SQL) database eller Business Central SQL-database mærkes derfor også i kroner og øre eller euro.
• GDPR
  Dette punkt bliver praktisk talt altid glemt. GDPR er et sandt minefelt! Din lovmæssige opbevaringspligt for skattemyndighederne (GDPdU) udløber ved udgangen af det 10. år efter den seneste skattemæssigt relevante bogføring. Hvis en faktura fra 31.12.2010 for eksempel betales den 02.01.2011 med rabat, udløber opbevaringspligten for betalingen den 31.12.2021. Dermed udløber opbevaringspligten for fakturaen og dermed også for de tilknyttede personrelaterede data. Du har simpelthen ikke længere ret til at gemme personrelaterede data fra denne arbejdsgang! Enten fjerner du personrelaterede data fra dette dokument (fakturadeltager, IP-adresse osv.) og alle tilknyttede dokumenter (følgesedler, etiketter, salgsstatistik, sælgerregnskaber osv.), eller du sletter simpelthen alle dokumenter senest efter udløbet af opbevaringspligten. Jeg anbefaler den fuldstændige sletning, da dette også medfører de andre nævnte fordele.
• Finans
  Faktisk også kendt af næsten ingen: Til GDPdU skal I - på anmodning - stille/udtrække alle data, der er tilgængelige i jeres Navision eller Business Central 365! Selv f.eks. fakturadata til kvitteringer/transaktioner i Business Central, som er betydeligt ældre end 7 år for følgesedler eller 10 år for fakturaer og andre omsætninger! Undtagelse: Du har ikke længere disse data på lager. Alene af denne grund bør du overveje en vis datahygiejne i din Navision-database.

Hvorfor ikke bare slette data?

Desværre kan du ikke bare slette en stor mængde ubrugt data i Navision/Business Central. For afsluttede ordrer findes der stadig færdige rutiner („Slet afsluttede ordrer“), det samme for indkøbsordrer („Slet afsluttede ordrer“). Navision tilbud og Business Central indkøbsanmodninger kan du stadig slette direkte via tabellerne ret nemt og hurtigt: Tabel 36 eller 38: Kør, sæt filter, marker alle og med Ctrl+a, slet. For debitorer og varer slettes de tilhørende posttabeller (21 debitorposter/Cust. Ledger Entry, 25 kreditorposter/Vendor Ledger Entry, 32 vareposter/Item Ledger Entry, 5802 værdiposter/Value Entry) desværre ikke længere med. Dette begrundes med statistik kontinuiteten.

Også gerne overset: Tabel 405 ændringsprotokolposter / Change Log Entry. Her er små fejl i opsætningen af ændringsprotokollen nok til at oversvømme Navision/Business Central-databasen med meningsløse data. I løbet af min tid som Navision-programmør og -konsulent har jeg opdaget mange systemer, hvor ændringsprotokollen fyldte 80% af en kæmpestor database – helt uden yderligere brug!

Og slet ikke påvirkelig af „normale“ brugere: 339 vareudligningsposter/Item Application Entry. I Navision-versioner før 2009 behøver man slet ikke denne tabel, man kan stort set slette dens indhold uden konsekvenser.

Afhængigt af Navision/Business Central-versionen skal nogle poster slettes, mens andre poster skal komprimeres (fortættes) for f.eks. at undgå at beskadige (holde konsistent) finanspostens saldi eller lagerbeholdninger. Rækkekomprimering eller endda sidekomprimering kan også være en reel hjælp til at tæmme især tabel 32 (finansposter) og tabel 5802 (lagerværdiposter) – og afhængigt af anvendelsen (der er ingen universel brugsregel for rækkekomprimering eller sidekomprimering!) kan det endda få din databases forespørgselshastighed og cache-udnyttelse til at eksplodere. Hemmeligheden bag det hele: Begge komprimeringer er også effektive i hukommelsen („Memory“), således at der i samme mængde database-cache nu kan opbevares omkring 10% mere („Row Compressing“) eller let op til 50% mere („Page compression“) data. Dette kan også reducere IO-gennemstrømningen på dine harddiske enormt (= Accelerere!).

Rækkekomprimering & sidekomprimering under Navision Dynamics eller Business Central 365 (BC365)

Et ofte stillet spørgsmål, der dykker meget dybt ned i SQL-teknikken... og som der ikke findes, eller mere præcist: kun få generelt korrekte svar på.

Som rettesnor kan man huske på:
– Hottables som 36, 37, 38, 39, alle bookingark og alle buffertabeller lader man bedst være ukomprimerede. Man kan eksperimentere med det, men allerede det faktum, at disse tabeller af natur er små (i betydningen af lavt lagerpladsbehov), er det ikke særlig meningsfuldt at bruge arbejdstid på komprimering her.

Indeholder dine salgs- og indkøbslinjer (tabel 37 og 39) også historiske data, f.eks. fordi I aldrig sletter ordrer og bestillinger? Det er skidt! Disse tabeller er *ikke* tænkt som arkivtabeller! Du forholder dig ikke Navision konform her. Hvis I har lange behandlingstider for „et eller andet“ her, så har I selv forårsaget det. Vi kan godt se på jeres applikation sammen for at se, hvordan vi kan gøre det mere elegant.

Tabeller med mange data måske, men som ikke ændres så ofte, såsom indkøbspriser og salgsrabatter og lignende, kan typisk komprimeres godt med sidekomprimering, hvis det betaler sig.

Det bliver spændende med posttabeller. Vareposter, vareudligningsposter, ændringslog, bogførte dokumenter... Her kan man ofte gøre mirakler med rækkekomprimering og sidekomprimering. Men også her gælder det: øvelse gør mester. For selvfølgelig er der også her dårlige programmer fra dårlige programmører, som laver grimme ting i disse tabeller.

I øvrigt… har du allerede i din SQL-server indstilling komprimeret databasesikkerhedskopier hhv. angivet dette som standard? Således kan du også nemt spare 30 til ofte 50% lagerplads på dit lagringssystem til dine databasesikkerhedskopier – og sikkerhedskopieringen og gendannelsen går også hurtigere… Sæt blot fluebenet under SQL-server Manager/Server/Højreklik/Egenskaber/“Databaseindstillinger“ ved „Sikkerhedskopi komprimeret“, og dine sikkerhedskopier vil kræve markant mindre lagerplads i fremtiden.

Hvordan rydder man så op i en Navision-database?

Jeg hjælper dig med at rydde op/nedskalere din Navision-database, normalt med følgende processer:

• Udskriv Deb/Kred/Saldo- og lagerstatuslister til senere kontrol for at sikre, at der ikke er blevet slettet for meget.
• Ændring af programlogik i din Navision eller Business Central, så posteringstabeller også reelt bliver ryddet/fjernet/slettet ved efterfølgende oprydninger.
• Heraf følger, at afhængige tabeller som f.eks. 379 Detailed Debitorposter / Detailed Cust. Ledg. Entry og 380 Detailed Kreditorposter / Detailed Vendor Ledg. Entry også bliver ryddet op.
• Tilbud ældre end 3 år, afsluttede ordrer bliver slettet. Mine rutiner går ud over standard Navision rutinerne og genkender flere afsluttede ordrer. Det samme sker i indkøb. Tommelfingerregel: Ordrer ældre end 2 år bør ikke længere leveres, de ville snarere forårsage irritation eller latter fra kundens side..
• Indkøbs- og salgsfølgesedler ældre end 7 år slettes automatisk. Mine ændringer sikrer, at også utrykte slettes. Dette giver dig ofte mulighed for igen at finde den seneste Navision følgeseddel med det samme med Ctrl+End uden at skulle søge – f.eks. hvis du har arbejdet med nummerserier som L99xxxx, der hidtil har forhindret dette.
• Fakturaer ældre end 11 år slettes (Du har en arkiveringspligt / GDPdU-pligt for skatterelevante transaktioner i 10 år efter afslutningen af regnskabsperioden! Heraf kommer de 11 år). Hermed kan du også endelig igen finde den sidste/aktuelle bogførte Business Central faktura med Ctrl+End – hvis du f.eks. har arbejdet med nummerserier som R99-xxxx, der forhindrede dette hidtil.
• Debitorposter, kreditorposter og sagsposter, der er ældre end 11 år, bliver komprimeret. Afhængigt af Navision-versionen korrigeres komprimeringen for dette. Dette gælder også for vareposter, hvis din Navision stadig tillader det. Ellers spares der også meget plads ved den reelle sletning af vareposter og værdiposter for varer, der ikke længere findes.
• Efter ovenstående komprimering vil forældede (ikke brugte) kunder/leverandører/konti/varer inkl. deres poster også blive fjernet fra databasen. For kunder/leverandører/varer antager jeg 5 år. Finanskonti kan naturligvis først slettes efter 11 år, hvis der altså ikke er eller kun er komprimerede poster til stede. Alle tidsperioder vil blive aftalt med dig igen! Her vil der også blive foretaget stikprøvekontrol for at se, om dine bogførte bilag stadig kan udskrives derefter. Dårlig programmering forhindrer dette overraskende ofte. I dette tilfælde skal det aftales, om bilagsudskriften skal tilpasses eller slettehorisonten. Netop her er dit bidrag meget vigtigt: Bruger du virtuelle varer, finanskonti eller kunder? F.eks. som moderselskaber, notatsamlere eller til prisgrupper? Med disse poster kan jeg ikke automatisk afgøre uden dine oplysninger, om jeg må slette dem, fordi de er gamle og ingen bevægelser har på dem, eller om de indeholder vigtige data, der ikke må slettes.
• Alt efter version bliver vareudligninsposter generelt slettet her (forskellige Navision-versioner behøver slet ikke disse – Business Central derimod behøver generelt disse for eksisterende varer).
• Ved brug af Microsoft SQL-server skal TransactionLOG også kontrolleres. Desværre er der stadig mange systemhuse og/eller hobbyprogrammører, som „sikkerhedskopierer“ en Navision-database (eller mere generelt: en SQL-database) ved at sikkerhedskopiere hele serveren, f.eks. med Microsoft Backup eller Veeam. Eller ved at tage backup af den komplette virtualiserede SQL-server som helhed eller - super intelligent - „trinvist“. Dette er ikke en data-backup, som er godkendt eller anbefalet af Microsoft til en MS SQL-database. Uanset om det er til Navision, Business Central eller en hvilken som helst anden applikation på SQL-serveren! Hvis du så også indstiller gendannelsesmodellen til at være komplet (hvilket anbefales af mange grunde, f.eks. for alle 5-minutters backups i miljøer med høj tilgængelighed), vil transaktionsloggen blive fyldt op. Ikke så mærkeligt: Den bliver aldrig tømt på en kontrolleret måde! Min personlige rekord var en Navision-database med 7 GB brugerdata (ikke ryddet op) og 67 GB transaktionslog. Det er måske ikke længere brugbart, men måske hensigten!
• Ved den første komprimering udføres der en (om nødvendigt flere) testkørsel, så du kan se resultatet igennem, inden jeg reducerer dine rigtige data. Inklusive genudskrivning og sammenligning af de nævnte saldolister. De nødvendige programmer forbliver derefter en del af din database! På denne måde kan jeg fremadrettet, hvis du ønsker det, regelmæssigt (årligt) rydde op i din database igen.

Og hvis det ikke passer mig?

Kort sagt: Som regel passer det, og (virkelig) unødvendige bekymringer er ofte på sin plads. Men selvfølgelig kan enhver tidsperiode, enhver stamdata, enhver sletning i Navision eller Business Central 365 tilpasses individuelt til dine behov.

Det er særligt vigtigt at tage hensyn til jeres specielle behov! Har du debitorer/kreditorer/konti/varer, der er statistiske eller af andre grunde relevante og kun har få eller gamle bevægelser, og som alligevel ikke kan slettes? Eller andre bemærkelsesværdige afvigelser fra „standarden“, der skal tages i betragtning ved ikke-sletning ?

Hvordan finder jeg ud af, hvad der fylder mest?

Antallet af poster pr. tabel kan meget nemt findes i den oprindelige Navision op til version 2009R2: ny side (Page), tabel 2000000028 Tabelinformation / Table Information, forhåndsvisning (gemme er ikke nødvendigt). Filtrer på størrelse (KB) > 1000000 (1 GB, mindre tabeller behøver man normalt ikke at beskæftige sig med). Og se der, Microsoft har efter 16 år også erkendt dette som en nødvendighed for Business Central BC 365! Siden 8700 viser nu omtrent de samme oplysninger, særligt antallet af poster pr. tabel.

Med alle SQL Navisions og BC365 (Business Central 365) imellem, altså 2009R2 RTC (men også 2009R2 native client, ligesom 4.0, 2005 osv., hvis disse kører på SQL), 2013, bc14/Navision2018 osv., kan du få vist antallet af poster per tabel i MS Microsoft SQL med dette SQL script:

NAV-Databasenavn
GÅ
VÆLG TOP 50
brugt SOM „Sider“,
rækker SOM „Sætninger“,
(brugt * 8) / 1024 SOM „MB“,
CAST(OBJECT_NAME(id) SOM CHAR(100)) SOM TabelNavn
FRA sysindexes HVOR indid I (1,2,255) SORTÉR EFTER used DESC

Meget, meget, meget gerne vil ændringsprotokolposter her vises meget højt oppe. Tommelfingerregel: Ændringsprotokolposter bør kun bruges på stamdata. F.eks. på varestamdata (tabel 27), debitorstamdata (tabel 21), betalingsbetingelser, leveringsbetingelser osv.
Det klassiske spørgsmål, som ændringsprotokollen skal og kan besvare, er af typen: „Hvem har ændret telefonnummeret hos Müller?“ eller „Hvem har ændret salgsprisen på vare 4711 fra 6,90 til 5,80?“. Standard Navision ville kun gemme „ændret den“ og „ændret af“ i forskellige, få stamdatatabeller.
Hvis man bruger ændringsloggen forkert, f.eks. til at logge transaktionsdata, så vil ændringsloggen hurtigt sprænge alle rammer, og dermed også din database.

Størrelsen af transaktionsloggen finder man i MSSMS under egenskaberne for den respektive database. Der er ingen transaktionslog, hvis du arbejder med den oprindelige database i Navision op til version 20090R2. Tommelfingerregel: Transaktionslogfiler, der er større end 1 GB, eller en størrelse > 2 % af databasens størrelse, er det tegn på sjusk. Dette er ikke altid sandt, f.eks. kan transaktionsloggen være blevet oppustet af en større handling og derefter ikke være blevet reduceret. Men næsten altid gælder denne regel. Her hjælper „used“ eller „brugt“ informationen dig videre. I Navision op til 2009R2 finder man også databasestørrelserne for SQL serveren under fil/database/ret.

Formindskelse af databasefilerne

Efter sletteaktionerne er der ofte mere end 50% „luft“ i databasefilerne.

Ved den oprindelige database (Classic Client) bør der ikke være mere end 15-20% ledig aktiv plads. Jo mindre databasen er, jo hurtigere og mere kompakt er HotCopy-sikkerhedskopieringerne (for den logiske gør dette ingen forskel). Den ledige plads bør naturligvis heller ikke være FOR lille, da databasen jo vil vokse igen.

Med SQL-databasen kan Navision eller selve SQL-databaseserveren om nødvendigt udvide Navision-databasefilerne eller transaktionslogfilerne. Derfor kan disse uden problemer reduceres til den nedre grænse. Også her sørger denne formindskelse for hurtigere og mere kompakte datasikkerheder. Defragmentering af indekser (Index Defrag) er en del af enhver databaseformindskelse! Men i en ren Navision-database har du alligevel periodiske processer til at genopbygge indeksene (Index-aktualisering) og dermed forbundet en Index-Defrag (defragmentering af indeksene).

Aktiver venligst aldrig funktionen „formindsk automatisk“ (Auto Shrink)! Denne funktion er absolut kontraproduktiv! Gennem denne funktion fragmenteres din database kraftigt – den bliver reelt „slidt fra hinanden“ (flænset). Indeksene (nøglerne) kan derved blive så fragmenterede, at SQL-serveren opgiver at bruge dem!

Hvis databasen ligger på magnetiske harddiske (siden 2008 anbefaler jeg kun SSD'er), bliver den effektive dataadgang fra Navision eller Business Central også hurtigere med mindre (reducerede) databasefiler, da harddiskenes hoveder nu skal tilbagelægge kortere afstande. Glem ikke „Defrag“ 🙂 . Det er dog mere sandsynligt, at det er opsætningssjusk (Raid5, flere databasedele på en disk, transaktionslog ikke på en separat disk ...), der bremser Dynamics NAV/Navision/Business Central og sørger for elendig performance. Næsten ingen Navision-programmør (eller Business Central-administrator eller nogen anden database-guru) forstod dengang, da nye og hurtigere og større magnetiske harddiske blev introduceret (omkring år 2000), hvorfor den nye, ultramoderne 15.000 harddisk med 120 Gbyte var sååå meget langsommere end de 3 gamle 2 Gb HD'er med 5.400 rpm.... Med den oprindelige databaseserver i Navision kunne 5 eller 6 gamle harddiske stadig være størrelsesordener hurtigere end færre/en ultramoderne harddisk. Det havde noget at gøre med tabelstrukturerne. Men grundlæggende gælder denne adfærd for alle databaseprocesser (nøgleord I/U-gennemstrømning).

Hvor ofte bør man komprimere databasen?

Her hedder det ikke: „mere vil have mere“. Den årlige formindskelse og defragmentering som led i dataoprydning er normalt tilstrækkelig. Undtagelse: Der er sket reel rod i din database, f.eks. i forbindelse med ændringsprotokollen eller transaktionsloggen. Så hører formindskelse og indekseringsdefragmentering til reparationsopgaverne.

Dataoprydningsproces

Konkret ser forløbet således ud:

1. Ændring af programlogikken, således at når stamdata slettes, slettes de tilhørende poster også (og sættes ikke kun til kontonummer „tom“).
2. Udskrivning af en saldoliste, deb, kred, udskriv lagerbeholdning.
3. Hent komprimering af posteringer for varer (98), debitorer (198), kreditorer (398) og, hvis det stadig er muligt, vareposteringer.
4. Kør lagerregulering (Alternativ: Tilpas kode for at ignorere uregulerede poster).
5. Afklar, hvad der skal ske med ikke-reserverede varelinjer (-> Slet).
6. Tilpas (slettehorisont) og hent (ny) funktion „slet gamle data“.

Das Löschen der Funktion „Alte Daten löschen“ in Navision bzw. BC365 startet z.B. folgende Vorgänge:

A) Löschen aller komplett abfakturierten VK & EK Lieferscheine älter als „x“
B) Löschen aller Verkauf (VK) und Einkauf (EK) Gutschriften & Rechnungen älter als „x“
C) Löschen aller Mahnungen älter als „x“
D) Löschen aller Debitoren und Kreditoren ohne offene Posten, bei denen die letzte Bewegung älter ist als „x“ *
E) Löschen aller Artikel ohne Bestände, ohne offene Posten, bei denen die letzte Bewegung älter ist als „x“ *
F) Löschen aller Changelog-Einträge älter als 3 Jahre
G) Löschen der Artikelausgleichsposten (je nach Navision-Version)
H) Löschen aller Sachkonten ohne Saldo und ohne Bewegungen in den letzten „x“ Jahren **

Für die Stammdatenlöschungen * ist dabei die Änderung wichtig, das die zugehörigen Posten auch wirklich gelöscht werden. Standardmäßig will Navision und Business Central 365 bei den zugehörigen Posten nur die entsprechende Stammdatennummer entfernen (also z.B. die Debitorennummer oder die Artikelnummer), und den Posten ansonsten in der Datenbank belassen… das macht nur wenig Sinn. Zu wenig Sinn, um das so zu belassen, wie sich das Microsoft vorgestellt hat.
Bei den Sachkonten ** würde ich das nur auf Wunsch so machen. I.d.R. ergibt sich hier wenig Löschpotential, und es könnte den optischen Eindruck des Kontenrahmens negativ verändern, z.B. weil leere Zeilen, welche die Lesbarkeit erhöhen, entfernt werden. Hier können wir anhand von konkreten Beispielen einmal ausprobieren, ob Ihnen der Effekt gefällt.

Dabei ist „x“ meist einheitlich 8 Jahre, durch die Novellierung der Gesetzeslage vom 1. Januar 2025. So könnten Mahnungen & Lieferscheine z.B. bereits nach 6 Jahren gelöscht werden… ich empfehle dies aber nicht, um einheitliche Horizonte zu haben.

Estimeret læsetid: 15 minutter