Slave.exe og Server.exe

Mængden af RAM til serveren kan angives som et opstartsparameter, f.eks.  CACHE=800000. Hvis du ikke angiver noget er der en standard, som varierer fra version til version.
Der kører en slave.exe for hver databasedel - så du må have 3 databasedele. Det er i øvrigt en god ide at give Navision meget RAM. Den er ikke så processorkrævende, men mængden af RAM og antal databasedele (på hver sin fysiske disk) betyder meget for hastigheden.

Vi kører ganske rigtigt 3 databasedele på hver sin fysiske disk. Vi overvejer at flytte databasen til et SAN via fibernetkort. Vil du anbefale at de 3 databasedele også der ligger på 3 diske, eller må de ligge på een?

Hvis du har et SAN består det vel af flere diske, som kører i en RAID-konfiguration. Hvis din version af Navision kan håndtere 1 stor databasedel kan du lige så godt gøre det på dit SAN, da det ikke vil give nogen hastighedsforbedring at dele den op. Hvis Navision har sine egne diske kan du regne med ca. en fordobling af hastigheden fra 1 til 2 diske og igen fra 2 til 3. Op til ca. 6 diske får du en mærkbar forbedring hver gang, dog ikke en fordobling når du kommer over 3 diske. Jeg har set databaser køre på SAN som var lige så hurtige, så det er en temperamentssag, om man vil lægge Navision på særlige diske.

Hvorfor vil det ikke give en hastighedsforbedring at lave en databaseopdeling på mit SAN?

Hastighedsforbedringen i Navision kommer ved at fordele databasen på flere fysiske diske, så læsning og skrivning bliver fordelt på mange læse/skrivehoveder. Det styrer Navisionserveren. Et SAN består af flere diske, og her er det SAN - controlleren, der styrer fordelingen - uanset hvad Navision så foretager sig. For Navision ser SAN'et ud som én stor disk, og Navisions indbyggede controller bliver så at sige sat ud af kraft. Men dit SAN vil sørge for at fordele data ud over alle diskene, så selv om du kun har en databasedel vil du få samme effekt.