Performance Navision

Petra_Vriens

Navision is bij ons af en toe erg traag en dit lijkt de laatste tijd alleen maar erger te worden. We hebben een aparte server voor de database. Het databasegebruik is bijna 17 Gb, en de database is 25 Gb. We hebben 14 licenties.
Is het zinvol de database op te splitsen? En heeft iemand hier wat meer informatie over?

kriki

Is het een Navision of SQL-DB?
Deze regels zijn voor een Navision DB:
-laat de Database Used % niet boven de 80% gaan.
-split de DB op in 5 DB-files van 4GB. Met elk een eigen RAID1-systeem. Dit heeft als voordeel dat het schrijven/lezen verdeeld wordt over 5 verschillende disks in plaats van 1 enkele. (welke RAID gebruiken jullie eigenlijk? RAID5 IS EEN ABSOLUTE NO!!!!)
-Gebruik een DBcach van 850MB (in theorie gaat het tot 1GB,maar meestal is dat niet mogelijk)
-Gebruik commit-cache
-Op de clients is het best een voldoende grote object-cache te hebben.

PS zoek ook op het forum voor meer info. Er is heel wat info ivm performantie.

Marije_Brummel

Dit kan zinvol zijn, maar wat beter is is om eerst een analyse te doen van de performance problemen.

De problemen kunnen zeer diverse oorzaken hebben en kunnen daarom ook op verschillende manieren worden opgelost.

Heb je al zo'n analyse (laten) uitvoeren?

Poltergeist

De database is nu een deel van 25GB? Dan kun je een goede performance over het algemeen wel vergeten. Het heeft zeker zin om de database op te splitsen, maar dat betekend wel dat je een investering in de hardware moet doen. Je kunt namelijk niet zomaar 5 of 6 databasedelen aanmaken, en die op dezelfde schijf en/of partitie zetten. Dat maakt voor de performance zeer weinig uit.

Als je wilt opsplitsen, moet je voor elk databasedeel een aparte RAID1 set gebruiken (RAID10 mag ook, RAID0 ook, maar dat laatste is niet erg redundant). De databasedelen mogen niet groter worden dan 4 GB per stuk (uit eigen ervaring, daarna gaat de performance omlaag. Microsoft raad zelf databasedelen van 2GB aan). Dat houdt dus in dat je voor een database van 24 GB 6 RAID1 sets nodig hebt. Oftewel: 12 schijven voor alleen de database. Dan ook nog twee schijven voor het OS (RAID1), zodat je een server met 14 schijven nodig hebt.

RAID5 is inderdaad, zoals kriki zegt, volledig uit den boze.

Je zou ook naar SQL server kunnen kijken. Als je toch al een grote aanschaf moet gaan doen, is het voor de toekomst wellicht handiger om daarin te investeren: Performance wordt steeds beter, en het is beter schaalbaar, zonder dat je (na de initiele aanschaf) direct nieuwe hardware moet aanschaffen voor een uitbreiding. Ook is de locking beter geregeld, wat ook voor een betere performance zorgt. Nadeel van SQL is wel dat je, naast de hardware, ook SQL server + de SQL server CALs moet aanschaffen.

kriki

Poltergeist wrote:

Je zou ook naar SQL server kunnen kijken. Als je toch al een grote aanschaf moet gaan doen, is het voor de toekomst wellicht handiger om daarin te investeren: Performance wordt steeds beter, en het is beter schaalbaar, zonder dat je (na de initiele aanschaf) direct nieuwe hardware moet aanschaffen voor een uitbreiding. Ook is de locking beter geregeld, wat ook voor een betere performance zorgt. Nadeel van SQL is wel dat je, naast de hardware, ook SQL server + de SQL server CALs moet aanschaffen.

Maar je kunt niet zomaar een Navision DB op een SQL en denken dat je betere performantie zal hebben. (als je dit doet, zal de SQL-DB meestal 2 tot 2.5 keer groter zijn dan de Navision DB)
Eerst moeten de objecten (vooral indexen en SIFT-fields) ge-optimized worden voor gebruik met SQL. Dit vereist wel enige dagen werk door een specialist. Na dit werk is de DB meestal KLEINER dan de Navision DB doordat er veel Navision-keys/SIFT-fields niet op SQL worden bijgehouden.
Performance voor sommige dingen kan zelfs beter zijn dan op een Navision DB.

Marije_Brummel

Je kunt idd veel bereiken ook in C/SIDE. Je transacties moeten lekker snel lopen, zodat er weinig tablelocks zijn.

Er is meerdere malen aangetoond dat SQL sneller is, maar tunen van SQL kost veel tijd(=geld). Blind overgaan op SQL is sowieso niet verstandig.

kriki

Mark Brummel wrote:

Blind overgaan op SQL is sowieso niet verstandig.

Vooral dat een Navision DB een Install-and-forget is, maar SQL moet je blijven controleren en onderhouden. Dus het is aan te raden dat de IT-guy bij de klant iets van SQL afweet.

Petra_Vriens

Afgelopen woensdag is onze database gesplitst in 3 delen. Het is echter moeilijk te zeggen wat dit voor invloed op de performance heeft, omdat gisteren ook het 'direct boeken' bij de analyseweergaven is uitgezet. Het is wel zo dat deze 2 wijzigingen samen de performance enorm verbeterd hebben.
Wel een opmerkelijk punt: de database-grootte is van ruim 17 Gb naar ruim 11 Gb gegaan door het splitsen, heel vreemd, maar we lijken toch niets te missen in de database.

Marije_Brummel

Waren je tabellen gefragmenteerd?

Petra_Vriens

De tabellen waren idd gefragmenteerd, en nu gedefragmenteerd. Kan dit zo'n groot verschil in de grootte van de database veroorzaken? Is het dan handig om regelmatig de tabellen te defragmenteren? De laatste maanden was de database namelijk gegroeid van 13 GB naar 17 GB, is toch veel 4 GB in een paar maanden tijd.

DenSter

Zelfs op de C/SIDE database maakt het uit of je SIFT levels bijhoudt of niet. Ik heb voor de grap in een klant database alle secondaire sleutels van de Item Ledger Entry tabel uitgezet, en die database ging van 8GB naar net iets meer dan 5GB, da's een verschil van bijna 3 GIEG!

Of het veel in performance uitmaakt heb ik niet onderzocht, maar het lijkt mij logisch dat zoeken in minder data sneller gaat, alhoewel met de SIFT in de C/SIDE database maar om 3 lees operaties per query gaat.

Als je na de splitsing nog steeds problemen hebt, dan raad ik aan om een analyse te laten uitvoeren op de specifieke processen waar je de problemen mee ondervindt.

Petra_Vriens

Misschien een stomme vraag, maar wat zijn SIFT levels? Waarvoor, hoe, wat.....

Secondaire sleutels uitzetten voor een aantal tabellen is misschien wel een goed idee als dit zoveel scheelt in de grootte van de database. Die secundaire sleutels worden toch waarschijnlijk nauwelijks gebruikt, en als er gebruikers zijn die ze wel gebruiken hoor ik het vanzelf wel...

Marije_Brummel

Van secundaire sleutels heb je alleen last bij het aanmaken van records, lezen wordt juist sneller.

OLAP vs OLTP

When it comes to indexes you are balancing with optimizing reading to the database as well as writing to the database. (OLAP vs. OLTP).

Natuurlijk kun je blind vannalles uitzetten maar wil je dat.

Tunen is een vak appart. O:)

Beter gewoon een keertje goed naar laten kijken.

DenSter

Petra Vriens wrote:

Misschien een stomme vraag, maar wat zijn SIFT levels? Waarvoor, hoe, wat.....

Secondaire sleutels uitzetten voor een aantal tabellen is misschien wel een goed idee als dit zoveel scheelt in de grootte van de database. Die secundaire sleutels worden toch waarschijnlijk nauwelijks gebruikt, en als er gebruikers zijn die ze wel gebruiken hoor ik het vanzelf wel...

:shock: nee joh! niet zo maar alles uitzetten. Ik heb dat voor de grap gedaan om te kijken wat er zou gebeuren. Als gevolg deed het hele systeem het nauwelijks meer, want je hebt secondaire sleutels nodig voor rapportage en flowfields en sorterings volgorde, en nog veel meer.

SIFT levels zijn de niveaus waarvoor sumindex velden worden bijgehouden in de tabellen. Als je een secondaire sleutel hebt met veld1, veld2 en veld3, dan worden standaard de sumindex velden voor alledrie de velden bijgehouden. Als je echter altijd filters zet op alle drie de velden, dan heb je geen totalen nodig voor alleen Veld1 waarde bijvoorbeeld. In de tabel designer kan je aangeven voor welke niveaus je SIFT velden wil bij laten houden. In de C/SIDE database maakt het vrij weinig uit, maar als je hele grote problemen hebt kan het misschien net een beetje verschil maken dat je nodig hebt.