Native DB and SAN - 1 or more LUNs?

pdj

Does the Native DB Server serialize DB calls to multiple database parts if they are placed on the same drive?
I have always been thought that MS-SQL did it, and it therefore is nessesary to create multiple LUNs.

But what about the Native Server?

David_Singleton

With Native you should create multiple LUNS, so that the Commitcache will do its stuff. But you need to balance the performance of the SAN to the number of LUNS. Obviously you must have more spindles than LUNS to get effect, so in the end better is just to configure the SAN as multiple dedicated RAID 1 per LUN.

SQL is a completely different story.

pdj

Hi David, thanks for you reply.

Say you are to setup new NAV db on a SAN with hundreds of spindles. None of the existing LUNs have dedicated spindles and the IT department reject to introduce it. Would it then make any difference if they create 1 new LUN at i.e. 500gb where I put 10 DB parts at 1gb. Or if they create 10 LUNs at 50GB where I place each of my 10 DB parts?

Basically the IT department claim that the SAN doesn't give any more ressources to the NAV server, just because it has 10 LUNs instead of 1. But I fear that NAV handles the DB parts differently if they are placed on the same LUN.

Are you saying that the commit cache is dependent on the number of drives and not the number of DB parts?

David_Singleton

pdj wrote:

Hi David, thanks for you reply.
...
Are you saying that the commit cache is dependent on the number of drives and not the number of DB parts?

Correct.

David_Singleton

pdj wrote:

Hi David, thanks for you reply.

Say you are to setup new NAV db on a SAN with hundreds of spindles. None of the existing LUNs have dedicated spindles and the IT department reject to introduce it. Would it then make any difference if they create 1 new LUN at i.e. 500gb where I put 10 DB parts at 1gb. Or if they create 10 LUNs at 50GB where I place each of my 10 DB parts?

Basically the IT department claim that the SAN doesn't give any more ressources to the NAV server, just because it has 10 LUNs instead of 1. But I fear that NAV handles the DB parts differently if they are placed on the same LUN.
...

This sort of stuff really is different for every client. There is no hard and fast rule. But personally I would create as few DB parts as possible. In your case probably 2 x 250gig.

Also what SAN is it?

rdebath

pdj wrote:

Say you are to setup new NAV db on a SAN with hundreds of spindles. None of the existing LUNs have dedicated spindles and the IT department reject to introduce it. Would it then make any difference if they create 1 new LUN at i.e. 500gb where I put 10 DB parts at 1gb. Or if they create 10 LUNs at 50GB where I place each of my 10 DB parts?

Basically the IT department claim that the SAN doesn't give any more ressources to the NAV server, just because it has 10 LUNs instead of 1. But I fear that NAV handles the DB parts differently if they are placed on the same LUN.

Are you saying that the commit cache is dependent on the number of drives and not the number of DB parts?

I want to stick my oar in here; it sounds like your IT department is making a problem for themselves. If you have more than two users, or you do any data warehouse sort reports Navision will hammer the LUNs it's given. Anything that happens to be assigned to the same physical spindle as the Navision DB will have it's performance completely trashed while it does the same to Navision.

It sounds like they believe that hard disks are fast, that RAID5 is good enough, that caching cures all ills. This is complete bullshit for any database, Navision native included. You need spindles, capacity per spindle is irrelevant but the more spindles the better. In fact with Navision native you're limited in the amount of memory that can be used as cache (about 800-1000MB) this make the disk speed even more important. By that I mean random access disk speed, not the headline figure of 100MB/s of a sequential read but the 2MB/s you get from a modern hard disk for random writes.

Sorry this reads like a rant, actually it is a rant, vendors tend to push SANs because they get a higher margin per disk and it's accepted because if you don't need fast disks it lets the customer use a smaller number of disks in the short term. They always setup the SAN as RAID5 too; this is the worst possible setup for a database as yet again it increases capacity at the cost of performance.

Quite frankly, with this sort of attitude your IT won't be able to give you disk performance and you'll be better off using a pile of small directly attached 15K disks and doing a hotcopy to the SAN for backup. Though you might be able to make everyone unhappy by getting your database drive made as a RAID10 LUN across every single drive in the SAN, that way in their book your load will be insignificant on every drive. (yea, right)

Anyway, your original question; I think NAV native puts out a request per DB part so a part per spindle is supposed to be correct even for a RAID10 array or a single SAN LUN. But, there is usually quite a large pipeline (disk queue) involved so the difference isn't actually that much and making multiple parts on one drive can increase average seek times. So best performance is normally gotten by putting one DB part per logical drive, however, in your case multiple parts is probably better.

BTW: NEVER EVER use more than one partition per database drive. Allocate as big a partition as you need from the start of the drive and leave the rest unallocated. (Can you see your IT doing that on the SAN?)

</rant>

David_Singleton

:thumbsup:

Hi Robert, you are pretty much on the money, and you will find many similar posts from the longer term members of this site and Dynamics User Group that have posted this information many times. Its just very very hard to get IT departments to listen.

I sat with one client once and explained this to their IT department, and then put it up as a blog here:

http://dynamicsuser.net/blogs/singleton/archive/2009/03/30/why-i-don-t-want-my-clients-to-use-sans-for-dynamics-nav-navision.aspx

The pictures are actual sketches I made during the session.

As to Native. The issue is that Navision generate one commitcache (slave.exe) for each drive is sees, so its very important to have one file part per drive per lun. Throughput as you point out in a good SAN is not going to be a lot different.

In reality though, once a database gets over 50gig and definitely at 100gig the client should move to SQL, and there the issues are completely different.

By the way, even though SANs are very difficult to set up correctly for a Database, virtually all of my larger clients use SANs, BUT with very close management. Fundamentally there is nothing wrong with a SAN, its just that it needs to be managed properly.

rdebath

The issue is that Navision generate one commitcache (slave.exe) for each drive is sees

David,
You've definitely got the right idea here, but you're a bit adrift on the terminology [-X .
The commitcache is a region of memory and the data structures contained therein, this memory is shared between the slave.exe processes there is only one single commitcache. Each of these processes is used to access an fdb file (Just count them, the MS page is not complete here.). I don't think there's a Navision name for the processes (except slave.exe) because their jobs is simply to be blocked on disk accesses so the main DB can continue to service other requests. What I'm uncertain about is how many writes each process will leave outstanding, there's a good chance that it used to be just one in the old days but it may have been changed.

http://msdn.microsoft.com/en-us/library/dd338661.aspx

Anyway love the Blog post, I done similar things myself (but more handwavey, my drawing sucks! ). And it's just the sort of ammunition that our friend needs to reopen the "Database must have dedicated spindles" debate with his IT. That's the main reason I've posted here; "pdj", don't give up on the spindles!