Database Server Requirement

podolly

Hi experts,

My company is planning a server for running database server with NAV5.0 W1 SP1. Thinking if below configurations are too much (?!) for only running this application. We will run Native database at the beginning, depends on the needs to upgrade to SQL Server. Any suggestions are welcome and will help a lot.

CPU: Quad Core E5504 Xeon 2.0GHz
RAM: 2X2GB 1066MHz, Dual Rank
OS: Windows Server 2008
HDD: 146GB, 10K RPM SAS x 2 (RAID 1)

One more concerns, we will run this application in close loop network, could this serve as file server as well? What I want is good enough for future 3 years.

Thank you very much.

David_Singleton

There is no way anyone can advise you on this if you don't give any information. Any replies you get will be pure guess work until you give details of what you are doing.

One point though, I would suggest going straight to SQL, you will be wanting to upgrade very soon, so its much easier to start with SQL than to have to upgrade later. (Not from the Navision side, but from the server side).

Fisherman

I can tell you that RAID 1 is generally not a good idea for database servers... not enough redundancy = too much risk for loss.

My SQL Server for NAV is set up on 3 RAID 10 volumes. One for database files (mdf, ndf), one for tempdb, and one for log files (ldf).

I would suggest that, in general, 2GB of RAM is not sufficient if you want to go forward with SQL Server at some point and you're going to have any kind of transaction load at all. RAM is cheap. If you're going to go with SQL Server, load it up.

Also - from a general perspective, if you're going to use this box as a file server as well, I would put the file shares on a wholly separate volume on a completely separate RAID controller. You don't want your file shares competing for disk I/O with your database - whether that database is SQL or native.

Those are general recommendations. Without knowing the specifics of your situation, that's all I can offer.

David_Singleton

<edit> naah just not worth it.

Fisherman

?

Might be?

themave

it is overkill for a native server, it takes very little resources, can't use more then a single processor so the quad core will basically have 3 cores sitting idle, the 4 gig of ram is fine.

Fisherman

Cool... good to know.

I haven't worked with Native before, but from a disk management/data loss perspective, RAID 10 might still be desirable. Better fault tolerance. RAID 10 degrades more gracefully than 1...

David_Singleton

Fisherman wrote:

Cool... good to know.

I haven't worked with Native before, but from a disk management/data loss perspective, RAID 10 might still be desirable. Better fault tolerance. RAID 10 degrades more gracefully than 1...

Only if you are very lucky and its the correct drives that fail. And you can not every rely on chance as a backup strategy, thus you must make the assumption that if a second drive fails it will be one that takes down the array, so in that case RAID 10 offers no additional safety net.

In terms of performance though, RAID 1 will always out perform RAID 10, so RAID 1 makes the most sense.

DenSter

Just FYI Fisherman... on native NAV database server, the optimum setup is to have multiple database files, one file per RAID 1 pair. This will always outperform having one big file on a RAID10 or multiple files on RAID10. NAV's internal striping can clash with RAID10's striping, so in that case it's better to have pairs of RAID1 with one database file each.

For SQL Server this is much different of course, but SQL Server best practices do not apply to the NAV database server.

Fisherman

Den -

interesting. i didn't realize that.

David -

That's true. I would never recommend someone rely solely on RAID to save them from data loss. an appropriate backup strategy is always important.

The nice thing about RAID 10 is that if a drive goes out in the middle of a production day, the degradation is much more graceful, and with many modern controllers, rebuilds can be performed hot with minimal interruption.

Just FYI - MS does make a recommendation for RAID 1 on highly-fault tolerant SQL Server database files or databases that are not mission critical, but RAID 10 for databases that are not as tolerant. I have my logs on 10 as well because of our use of replication for multiple purposes.

[EDIT]

Den - actually I just remembered something.

Microsoft has been recommending separating high-volume/traffic tables in SQL Server off onto separate filegroups, preferably on separate volumes, for a long time. This is concurrent with what you're saying about NAV and multiple files on multiple RAID 1 volumes. SQL server will open separate I/O threads with each file, thus increasing throughput. SQL 2005 also introduced the idea of table partitioning, where a single table can be split across multiple physical filegroups based on some value, also on separate volumes if necessary. This allows really high-volume tables (maybe ILE or GLE) to have a separate I/O thread to be assigned per physical file.

DenSter

It might feel like there is concurrency there, because it looks like it's a similar concept, but there is factually no relationship between the two. The NAV database server was built long before Microsoft was in the picture.

Fisherman

?

I... know? I just meant that there is equivalent functionality...

DenSter

Ah my bad, I thought you were implying that there was a relationship, as in "yes that makes sense because that the same in SQL Server, which is also a Microsoft product"

Fisherman

NP -

I'm honestly surprised that the NAV database has it's own striping mechanism to write across multiple volumes.

I need to look into it, because I've been thinking about it overnight, and I'm actually confused. When you say striping, do you mean block striping across multiple volumes, or do you mean data partitioning?

If you mean striping across multiple volumes, then I'm really confused.

Please excuse the elementary stuff here - I'm just thinking out loud to try to explain my thought process.

RAID 1 is mirroring. RAID 0 is JBOD (or striping). If you stripe across mirrors, then that's RAID 0+1. If you Mirror stripes, then that's RAID 1+0 (or RAID 10).

If the Native database is striping blocks across RAID 1 volumes, then it's essentially taking a series of RAID 1 volumes and turning them into RAID 0+1. The thing is, though, that RAID is normally a heck of a lot faster when handled by a hardware controller than it is when handled by software.

Is it a price concern since hardware RAID controllers capable of compound/complex volumes are relatively expensive? Is there a specific advantage to using the Native DB's striping mechanism across mirrored volumes vs. placing the NAV database on a RAID 0+1 volume managed by hardware?

I'm just curious - for my own edification

David_Singleton

Fisherman wrote:

NP -

I'm honestly surprised that the NAV database has it's own striping mechanism to write across multiple volumes.

I need to look into it, because I've been thinking about it overnight, and I'm actually confused. When you say striping, do you mean block striping across multiple volumes, or do you mean data partitioning?

If you mean striping across multiple volumes, then I'm really confused.

Please excuse the elementary stuff here - I'm just thinking out loud to try to explain my thought process.

RAID 1 is mirroring. RAID 0 is JBOD (or striping). If you stripe across mirrors, then that's RAID 0+1. If you Mirror stripes, then that's RAID 1+0 (or RAID 10).

If the Native database is striping blocks across RAID 1 volumes, then it's essentially taking a series of RAID 1 volumes and turning them into RAID 0+1. The thing is, though, that RAID is normally a heck of a lot faster when handled by a hardware controller than it is when handled by software.

Is it a price concern since hardware RAID controllers capable of compound/complex volumes are relatively expensive? Is there a specific advantage to using the Native DB's striping mechanism across mirrored volumes vs. placing the NAV database on a RAID 0+1 volume managed by hardware?

I'm just curious - for my own edification

I may be stepping out on a limb here, but I feel confident to say that prior to SQL becoming mainstream on NAV (say 2005/2006) this would have been the most discussed topic on both MiBuSo and The Dynamics User Group.

There must be hundreds of threads discussing this.

Please forget SQL, what Navision does internally is not striping, we just use that word as an analogy. Learn first about commitcache to understand why disks are important.

Fisherman

David -

OK. I appreciate your clearing that up. I didn't think it would actually be striping - it just wouldn't make sense to do that. Disregarding SQL altogether, hardware RAID managers are just simply better at managing mirroring/striping/parity, and all combinations thereof, than software. If the NAV database isn't actually block striping, but is instead partitioning the data (either by index or by table), then it makes more sense.

DenSter

I think we're stuck in semantics here. The fact is that for NAV database server, the best performance comes from having multiple RAID1 arrays (mirrored pairs of disks) with individual database files on them, one file per volume. MUCH better than having one file on a RAID10, and also MUCH better than multiple files on RAID10 (either 1+0, or 0+1, or x+y, or whatever other technical numerical enumeration you wish to use).

Unlike SQL Server, you don't have any control over what gets partitioned where (or striped, or whatever technical term you want to throw at it), so semantics over which technical term to use is really not relevant, and you don't want to confuse logic that applies to SQL Server, and apply that to the NAV DBMS, because they are two different species. The NAV DBMS takes care of what gets written to what file, all you have to do is put each file on its own physical volume, whether that is a mirrored pair in case you want redundancy, or individual physical disks. Just don't set up any kind of striping at the same time that there are multiple database files.

Fisherman

Yep. I was just trying to get a better handle on what the NAV DBMS was doing that gave it that performance advantage when configured that way. Like I said, if it was truly striping blocks across volumes, then it would make no sense whatsoever for the NAV DBMS to manage that - that's a physical I/O issue that's better dealt with at the physical/controller level. However, if it is partitioning the database - either by simply splitting the database into groups of tables with a group per file, or by carving individual tables up and splitting them across files - then it makes complete sense for the DBMS to handle it.