Ryd op i databasen

Navision-databasen kender kun é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 SQL Server (allerede et krav fra Navision Dynamics 2013) eller den native 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 databasedatabaserne for overhovedet at muliggøre en mindre database. Ellers er det simpelthen ikke muligt at formindske databasen, hvor skal alle datasættene gemmes?.

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

Søger du rent faktisk 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åhastighed
  Jo færre datasæt Navision skal søge igennem, jo hurtigere kan søgninger eller filtre give et resultat. Det resulterer i den enkelte Navision-operation for en bruger ofte i en næppe mærkbar forsinkelse eller et tåleligt par sekunder. Samlet set bremser det dog Business Central SQL Serveren og forsinker arbejdsgange mærkbart eller umærkeligt for hele firmaet, for alle medarbejdere, igen og igen.
  Det bliver rigtig irriterende, når man
  -den seneste følgeseddel fra Navision
  -den seneste ordre fra Business Central
  -den sidste faktura fra Business Solutions NAV
  søgning: 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), artikler og konti, hindrer arbejdsflowet. Er det nu tid til at Müller Schulze eller der Müller Schultze den rigtige kunde? Åh, valgte forkert igen... Og også her lider dine medarbejderes performance meget mere end ved korte, ofte umærkelige ventetider på Navision SQL-databasen.
• Administrativ tid
  Ved databasereorganiseringer af native Navision-databaser, ved nøgleoptimering af Business Central SQL-databaser, ved backups, gendannelser, oprettelse af Testmiljøer, replikering af databasens ændringer i systemer med høj tilgængelighed: Igen og igen bliver gigabytes af unødige data mast gennem 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 en sand minigang! Din lovpligtige 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 for de tilknyttede personrelaterede data. Du har simpelthen ikke længere ret til at gemme personrelaterede data fra denne proces! Enten fjerner du personrelaterede data fra dette dokument (fakturadeltager, IP-adresse osv.) og alle tilknyttede dokumenter (følgesedler, forsendelsesmærker, 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 her nævnte fordele.
• Fiskalisk
  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 ubrugte 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 Artikelausgleichsposten/Item Application Entry. I Navisionversioner 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. Row-komprimering 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 anvendelsestilfældet (der er ingen universel anvendelsesregel for row-komprimering eller sidekomprimering!) kan det endda få din databases forespørgsels hastighed og cache-udnyttelse til at eksplodere. Hemmeligheden bag det hele: Begge komprimeringer er også effektive i hukommelsen („Memory“), således at i samme mængde database-cache kan der nu indkvarteres 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ække komprimering & Side komprimering 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:
– Hot Tables som 36, 37, 38, 39, alle booking-ark og alle buffer-tabeller 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), gør 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 dårligt! Disse tabeller er *ikke* beregnet som arkivtabeller! De opfører sig ikke i overensstemmelse med Navision her. Hvis I har lange behandlingstider for „et eller andet“ her, så har I selv forårsaget det. Vi kan gerne kigge på jeres applikation sammen for at se, hvordan vi kan gøre det mere elegant.

Tabeller med måske mange data, 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. Artikkelposter, artikkeludligningsposter, ændringslog, bogførte dokumenter... Her kan man ofte gøre mirakler med rækkomprimering og sidekomprimering. Men også her gælder det: Forsøg gør klog. 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å på dit lagringssystem nemt og gerne spare 30 til ofte 50% lagerplads til dine databasesikkerhedskopier – og hurtigere går sikkerhedskopieringen og gendannelsen også… Sæt blot fluebenet under SQL Server Manager/Server/Højreklik/Egenskaber/“Databaseindstillinger“ ved „Sikkerhedskopier komprimeret“, og dine sikkerhedskopier vil kræve markant mindre lagerplads i fremtiden.

Hvordan renser man så en Navision-database?

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

• Udskriv Deb/Kred/SK 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å posterings-tabeller også reelt bliver ryddet/fjernet/slettet ved følgende rensninger.
• Heraf følger, at afhængige tabeller som f.eks. 379 Detailed Debitorenposten / Detailed Cust. Ledg. Entry og 380 Detailed Kreditorenposten / Detailed Vendor Ledg. Entry også bliver opryddet.
• 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øbet. Tommelfingerregel: Ordrer ældre end 2 år bør ikke længere leveres, de ville snarere forårsage irritation eller latter på 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 – for eksempel hvis du har arbejdet med nummerserier som L99xxxx, der hidtil har forhindret dette.
• Regninger ældre end 11 år slettes (Du har en arkiveringspligt / GDPdU-pligt for skatterevante transaktioner i 10 år efter afslutningen af regnskabsperioden! Heraf følger de 11 år). Hermed kan du også endelig igen finde den sidste/aktuelle bogførte Business Central-regning med CTRL+End – hvis du f.eks. har arbejdet med nummerserier som R99-xxxx, der forhindrede dette hidtil.
• Debitorposter, Kreditorposter og Sachposter, 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 artikler, der ikke længere findes.
• Efter ovenstående kompakteringer vil forældede (længe ikke brugte) kunder/leverandører/konti/artikler også blive inkl. deres poster fjernet fra databasen. For kunder/leverandører/artikler antager jeg 5 år. Finanskonti kan naturligvis først slettes efter 11 år, hvis der så 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 artikler, 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 artikelafstemningsposter generelt slettet her (forskellige Navision-versioner behøver slet ikke disse – Business Central derimod behøver generelt disse for eksisterende artikler).
• 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 (ujusteret) og 67 Gb transaktionslog. Det er måske ikke længere uagtsomt, men måske forsæt!
• 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 SuSa-lister. 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å plads. Men selvfølgelig kan enhver tidsperiode, enhver stammeoversigt, enhver sletning i Navision eller Business Central 365 tilpasses individuelt til dine behov.

Det er særligt vigtigt at tage hensyn til deres særegenheder! Har du debitorer/kreditorer/konti/artikler, der er statistisk 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 hos ikke-slette skal tages i betragtning?

Hvordan finder jeg ud af, hvad der fylder mest?

Antallet af poster pr. tabel kan findes i den native Navision op til version 2009R2 meget nemt: ny side (Page), tabel 2000000028 Tabelinformation / Table Information, forhåndsvisning (gemme er ikke nødvendigt). Filtrer på størrelse (KB) > 1000000 (1 GB, med 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, især 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 AS „Sætninger“,
(brugt * 8) / 1024 SOM „MB“,
CAST(OBJECT_NAME(id) AS CHAR(100)) AS TabelNavn
FRA sysindexes HVOR indid I (1,2,255) SORTÉR EFTER used DESC

Meget, meget, meget gerne vil ændringsprotokolposter vises meget højt oppe her. 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å artikel 4711 fra 6,90 til 5,80?“. Standard Navision ville kun gemme „Ændret den“ og „Ændret af“ i forskellige, få master datatabeller.
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 native database i Navision op til version 20090R2. Tommelfingerregel: Transaktionslogfiler, der er større end 1 GB, eller en størrelse > 2 % af databasens datastørrelse, er et tegn på sjusk. Dette er ikke altid sandt, f.eks. kan transaktionsloggen være blevet oppustet af en større handling og derefter ikke blevet reduceret. Men næsten altid gælder denne regel. Her hjælper „Brugt“ eller „Genutzt“ informationen videre. I Navision op til 2009R2 finder man også databasestørrelserne for SQL Server under Fil/Database/Skift.

Formindskelse af databasefilerne

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

Ved den native database (Classic Client) bør der ikke være mere end 15-20% ledig plads aktiv. Jo mindre databasen er, jo hurtigere og mere kompakt er HotCopy-sikkerhedskopieringerne (ved den logiske gør dette ingen forskel). Den ledige plads bør naturligvis heller ikke ZU 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 reducerer denne formindskelse 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 indekserne (Index-aktualisering) og dermed forbundet en Index-Defrag (defragmentering af indekserne).

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

Hvis databasen ligger på magnetiske harddiske (jeg anbefaler kun SSD'er siden 2008), bliver den effektive dataadgang fra Navision eller Business Central også hurtigere med mindre (reducerede) databasefiler, da harddiskens hoveder nu skal tilbagelægge kortere afstande. Glem ikke „Defrag“ 🙂 . Det er dog mere sandsynligt, at det er opsætningssynder (Raid5, flere databasedele på en disk, transaktionslog ikke på en separat disk ...), der bremser Dynamics NAV/Navision/Business Central med 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 under 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: „Meget hjælper meget“. Den årlige formindskelse og defragmentering som led i datarenhed 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.

Datarensningsproces

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 ikke kun sættes til konto nummer „tom“).
2. Udskrivning af en SuSa SK, Deb, Kred, Udskriv lagerbeholdning.
3. Kald komprimering af posteringer for varer (98), debitorer (198), kreditorer (398) og, hvis det stadig er muligt, af vareposteringer.
4. Kør lagerregulering (Alternativ: Tilpas kode for at ignorere uregulerede indlæg).
5. Afklar, hvad der skal ske med ikke-reserverede vare linjer (-> Slet).
6. Tilpas (slettehorisont) og kald (ny) funktion „Slet gamle data“.

Anslået læsetid: 15 minutter