Maximum database partition size?

I’ve been digging around on Microsoft’s support site, but I’m having a hard time finding the info I need. Can someone here tell me what the maximum database partition size (i.e. one of the individual database.fdb files on a database divided across multiple disks) is for Navision 2.6b and for Navision 3.6? thanks Chris

2.6b was (I think 4 Gb). But I think by 2.6f it had gone up. Now it is pretty much unlimmited (I think you can go upto 64g). 2.60 is all well documented in the install guide, not sure how clear it is in the 3.60 manuals.

Hi. If You search this forum for threads about RAID You’ll get a lot of answers. But in short: Don’t use files larger than 2Gb and put them om separate disks in RAID1. This way You get very good performance out of Your Navision Server. //LArs

Hi Lars, I have found that since 3.10, using 4 Gb partitions seems to be OK. Though it may just be that the hardware is gettng faster.


When you are expanding the database it is important to remember that: · All of the database files must be approximately the same size. This improves performance. · The database can consist of up to 16 physical files. · Each database file can be between 1 KB and 128 GB. · All of the files together cannot exceed 128 GB.

So you can go upto 128 Gb per partion, but this is not recommended of course. By the way Chris did you RTFM ?[;)] Maybe in this case its best not to. Also just for fun, did anyone see this in the 3.60 ISM manual?


You must keep track of the status of the database, including how much space is left and how much database space you have purchased permission for.

Don’t we all rememember back in 98 or 99 when this was finished [:)]. I’ll bet 50% of the people reading this have no idea what I am talking about.

Yeah. Shame on You those days if You didn’t calculate the database growth correctly… That could cost money and customer realitionships! Nice abbrivation. Even a Swede understood it [:D] Then this issue about size. Does it really matter?? I must admit it does… The old limit of 2Gb wasn’t to bad as long as we are speaking performance. Of course it can be expensive to by a lot of 15k disks, and maybe someone want’s to store more than 32Gb. But one should be aware of the impact large db-files have on performance. As a rule of thumb: Don’t go over 4Gb if You can avoid it. The more data-> The more throughput You need in the disk system. /Lars

When they made the anouncement, I had one customer that had purchased 1Gb, Navision invoiced me for that and then sent an email to the client telling them it would be for free (I loose). Another customer was just about to buy 1 G and I obiously lost the sale (I loose), and one bought and paid for 1G just before the anouncement and hated me for ever (I loose). Was there anyway for anyone to win from that anouncement. I still love the product though. … here is where it should be.

The size of the files to use, the correct RAID and the number of files and how to split them across disks have always been tricky questions. The maximum size of the files has always been defined by the operating system and so then the file format. The best way it seems to me from experiance is to spread the files over all the disks except the disk the the operating system / temp directory is on. But memory seems to be more important than disk space always make sure that the navision service is not paging memory however much ram you have. All this will become irrelivent with Navision 4.00 as I have not doubt that will use SQL. Paul Baxter

It really isn’t that tricky. In any decent Navision implementation the minimum configuration is 5 hard disks. Disk 0 for the OS Disks 1 & 2 RAID 1 for the first 2-4 Gb database partition Disks 3 & 4 RAID 1 for the second 2-4 Gb database partition Then as needed add RAID 1 arrays for each 4 Gb increase. As for temp directory, this is stored on the client, so it is not so important for the server. As Paul says you must never page memory, but that is pretty easy to check and setup. My guess with the way both Navision and MS have worked, is that we should see 5 years of life (read support) for the Native database. So counting last year, lets say we have till 2006 to get everything moved to SQL. (IMHO of course. Its just a guess.) In any case by 2006 RAM will be so cheap that we will run our databases in RAM, and HD will just be a backup system. Navision actually had this working a couple of years ago, but it never came about [:(]