This article has been archived. It is offered "as is" and will no longer be updated.
Navision Server Hardware Recommendations
Your hardware has a big effect on the performance you can expect and determining the hardware requirements is not an exact science. Performance depends on many different factors including number of users, activity of users, number of transactions, volume of data, when and how certain tasks are performed, and how the program is written.
Follow the hints below to help you make decisions on the hardware for the Navision Financials server. The recommendations are very different for the native (C/SIDE) Navision server compared to the SQL Server Option. This information supplements the Installation and System Setup manual.
A. The performance of the server depends on the following resources in this order: 1. Disk system 2. Memory 3. CPU 4. Network
Note See for a IBM Performance Report detailing the same findings.
B. HDD subsystem recommendations: 1. Use SCSI/RAID controller with as many SCSI channels as possible. 2. If the disk controller has memory (caching), make sure that there is a battery on the controller. 3. Use RAID1 (disk mirroring), if you require extra resilience. 4. NEVER use RAID5. 5. NEVER use software RAID; you must use hardware RAID. 6. Turn off write back cache on the controller. Use all controller memory for read cache. 7. Use 4GB SCSI disks for building your storage space. See paragraph (C) for details.
C. Disk organization: - Disk0 - System disk 4GB partition, Windows, programs, binaries, utilities, Navision client - Use NTFS file system format. NEVER put the Windows pagefile on the database disk(s). - Disk1 - Database(s) disk 1 2 x 2GB partitions. - Disk2 - Database(s) disk 2 2 x 2GB partitions. - DiskN - Database(s) disk N 2 x 2GB partitions.
On the database disks ( Disk1 to DiskN), the first partition is used for a "life" database part. The second partition is not used or can be used for "backup" database part or for test system or any other non-busy usage.
If you want to have a system that can store up to a 6GB Navision database, you will want 4 x 4GB disks (or 8 x 4GB disks if RAID1 is used).
See for an explanation on how to use the "unattended backup" database partition.
Database files must be the SAME SIZE on all disks. For example, if a 2.1 GB database is placed over 3 disks, use 3 * 700MB parts. If the same database is expanded to 2.4 GB, expand 100MB per partition, making it 3 * 800MB parts.
If you change the number of disks (database parts) you MUST do the following: 1. Make a backup. 2. Delete the database. 3. Create a new database with the same database file parts sizes. 4. Restore the backup.
D. Allocate all available memory to the Navision Server cache. Use commitcache to speed up insert transactions. 1. The installation program allocates approximately 2/3 of physical memory to the server cache. You must change the server parameter CACHE. 2. The installation program does not activate the commitcache. You must change the server parameter COMMITCACHE. 3. If you activate commitcache, make sure that you use UPS to back up power failures (you may lose transactions from commitcache that have not been flushed to the disks).
Memory is a way to decrease the harddisks' bottleneck. 1. Use as much RAM as possible. Generally, use at least 4 - 8 MB of memory per user for cache. Plan for approximately 200MB cache for a 30 user system (256MB system RAM at least) or more, because memory is rather inexpensive. 2. The maximum Navision Server cache is 1GB. Therefore, there is no advantage to purchasing more than 2048MB of RAM, leaving 1GB for Windows and 1GB for Navision. 3. MAKE SURE that the computer is not swapping, for example, after you increase the cache size.
E. Use a DEDICATED Navision server that is a stand-alone server (not PDC or BDC). If you have a non-dedicated Navision server computer, make sure that the programs are not competing for resources. NEVER run SQL server or Exchange server on the same computer with Navision server.
F. Use a single processor computer. Allow Windows NT to use processor cache fully.
G. See for information on low bandwidth constraints.
Note Allowing low bandwidth connections for some users can impose the risk of very bad performance, but if you must do this, do NOT allow those users to modify/insert records. If a low bandwidth client processes data, tables may be locked for a longer period of time, locking every other user and slowing down the whole system.