Optimering af tabeller i Navision
Optimering af tabeller i Navision sker via Filer, Database, Oplysninger. Tryk
på knappen Tabeller og dernæst på knappen Optimer
I Navision ligger data i 4K blokke. Betragtes de primære data (primærnøgle og
information om records) på en finansposttabel, vil det fremgå, at optimeringen
er tæt på 100%.
Dette skyldes, at records genereres sekventielt (d.v.s. en række af på hinanden
følgende numre), f.eks. har den første record post nr. 1, den anden nr. 2 osv.
Databasemanageren vil fylde blokken med record nr. 1, 2, 3 ... osv. indtil blokken
er fyldt, hvorefter den næste record skrives i en anden blok. På denne måde vil
optimeringen af pladsen i finansposttabellen ligge tæt på 100% .(Vedr. sekundære
nøgler se senere).
I tabeller, hvor records ikke oprettes sekventielt, som f.eks. i debitortabellen,
skrives data på basis af primærnøgle. Etableres f.eks. debitor 100, 200, 300.....
5000 sekventielt, vil optimeringen være næsten 100% . Databasemanageren udfylder
blok 1 af debitortabellen, indtil den løber tør for plads, hvorefter den anden
blok etableres. Indeholder blok 1 f.eks. debitorerne 100, 200, 300 og 400 og man
ønsker at indsætte debitor 150, vil databasemasemanageren forsøge at indpasse
debitor 150 mellem debitor 100 og 200 i den første blok. Er den første blok fyldt,
vil databasemanageren splitte denne første blok i to blokke og skrive f.eks. debitor
100, 150 og 200 i én blok mens debitor 300 og 400 skrives i en anden blok. Som
det fremgår, vil pladsudnyttelsen/optimeringen her kun være omkring 50%.
Forsøger man herefter at køre en optimering (ved at vælge Filer, Database, Informaton,
Tabeller, Optimer) på debitortabellen, vil databasemanageren nu etablere en ny
blok1 indeholdende f.eks. debitor 100, 150, 200 og 300 i den første blok, idet
blokken derved fyldes op til 100%, hvorefter der fortsættes med blok 2 etc.
Da sekundære nøgler typisk er tilfældige data som f.eks. varenummer og dato,
vil sekundær datainformation typisk kun være optimeret med ca 50% (se blot nøgler
og optimeringsprocenter under Filer, Database, Information, Tabeller, Nøgler).
Hvis sekundære nøgler optimeres, er det vigtigt at overveje følgende. Når mange
nye records indtastes, vil de indtastede sekundære nøgler forårsage opsplitning
af mange blokke, da blokkene ikke har nogen fri plads til ekstra nøgler. Dette
vil langsomt reducere optimeringen fra 100% til 50%.
Da opsplitningen i blokke tager tid, bør optimeringen kun anvendes på hhv. primære
nøgler og data i posttabeller for dermed at undgå et fald i performance. Desværre
er det ikke muligt at undgå optimeringen af de sekundære nøgler. Derfor bør det
altid undersøges, hvordan de sekundære nøgler er konstruerede. Hvis de sekundære
nøgler er mere eller mindre sekventielle (som f.eks. transaktionsnummer i finansposttabellen)
da vil en optimering ikke nødvendigvis have betydning for performance.
Til toppen af siden
Du skal være logget ind før du kan se eller skrive kommentarer til de forskellige indlæg. Klik her for at logge ind, eller oprette en bruger.
