1 x RAID1 RPM10000 + 2 x RAID1 RPM15000:Native

kriki

A customer has a Navision DB (+-25GB) on a RAID1 with disks that are RPM10000.
They want to buy 4 more RPM15000-disks .
Now the idea is to divide the Navision DB over 3xRAID1.
I know that performance will improve with this setup.

The only thing I am not sure about is about mixing RPM10000-disks with RPM15000-disks (of course each RAID-pair will have the same RPM!).

Someone knows if that can give problems or that it is save to do with a Navision DB? (and now that I am asking:a SQL DB?)

ara3n

I don't think the RPM will have any technical effect except one will write slower.

One thing I want to mention is that make sure You create a new database split across the databases. do a backup from the existing database and then restore it in the new database. That way the data gets spread evenly across all the files.

kriki

ara3n wrote:

One thing I want to mention is that make sure You create a new database split across the databases. do a backup from the existing database and then restore it in the new database. That way the data gets spread evenly across all the files.

I hadn't forgotten this. But good idea to mention it in case someone else reads the topic. =D>

Waldo

IMHO,

I don't think you have to worry about this.

What about this theory: (just hypothetically)
Having 15K RPM as second and third set, will not be quicker then having 10K RPM for these sets.
When data is written, the data is devided over the 3 sets.
When that data has to be read, then the three parts will be read at the same time ... so the data is only complete when the slowest disk has read his part ... .

Again, this is only a theory, but makes sense to me.

DenSter

I was thinking about the chain that is as strong as its weakest link, but I don't know from personal experience. I would personally try to keep all disks at the same specifications.

Waldo

DenSter wrote:

... the chain that is as strong as its weakest link...

That is exactly what I was trying to explain ... but you have better words

Waldo

For an SQL db, I would do exactly the same.

for the record ... my "theory" only applies on the native db, when the files are divided onto seperate disks.

kriki

colin leversuch-roberts wrote:

15k disks support more io/sec thus they can read/write more data/sec. Depending how you plan to split your database I'd probably leave transaction logs or backups on the 10k disks and put data on the 15k disks
It also depends how you plan to use the arrays - files in the same filegroup , or seperate filegroups.

Where it for SQL, I would have put system+log on the RPM10000-RAID1 and the DB on the RPM15000 RAID10 with 4 disks).
But in this case I have a Navision-DB.

Waldo wrote:

IMHO,

I don't think you have to worry about this.

What about this theory: (just hypothetically)
Having 15K RPM as second and third set, will not be quicker then having 10K RPM for these sets.
When data is written, the data is devided over the 3 sets.
When that data has to be read, then the three parts will be read at the same time ... so the data is only complete when the slowest disk has read his part ... .

Again, this is only a theory, but makes sense to me.

My big problem is if I have to worry or not about the integrity of the DB. Less about performance.
If your theory is correct (actually I had the same theory), 3 x 10000RPM-RAID1 is faster then 2 x 15000RPM-RAID1. At least, I suppose so...

David_Singleton

kriki wrote:

A customer has a Navision DB (+-25GB) on a RAID1 with disks that are RPM10000.
They want to buy 4 more RPM15000-disks .
Now the idea is to divide the Navision DB over 3xRAID1.
I know that performance will improve with this setup.

The only thing I am not sure about is about mixing RPM10000-disks with RPM15000-disks (of course each RAID-pair will have the same RPM!).

Someone knows if that can give problems or that it is save to do with a Navision DB? (and now that I am asking:a SQL DB?)

Hmm: I think you confused this by mixing Native and SQL in the same thread, since they are very very different in these terms.

But to answer your actual question about Native. (And I wont comment about why a client with a 25 G system can not afford to go out and buy the 10 or 12 drives aka 5 or 6 RAID1 Arrays that they really should be using). So...

When you have three RAID1 arrays/spindles in Navision, the commit process attempts to evenly spread data across the separate arrays. This helps read performance, since statistically there is a good chance that reading will be fairly uniform across all the arrays. Assuming you are using commit cache, then each array will have its own commit cache, so Navision server must put the data into the correct cache for it to be split across the arrays correctly. If 2 arrays are faster than the other one, then those parts of commit cache will be committed (or flushed) before that other one.

Now drive write performance only really matters when the cache is full, so if one drive is still committing and the other two are free, then the next transactions will still work in cache, and wont be an issue until you run out of cache and get the dreaded "Commit cache is full warning message".

For reads, what will happen, is that things will slow down some times when the entire data set can not be read at the same speed. So statistically it should really be like the average speed, but in practice its actually lower, because its often likely to hit the slow drive.

Now if you want to cheat (and yes I have tried this, but do not recommend it), you can put a smaller db part on the slow drive than on the faster drives. Statistically this will put less data on that drive, and balance out the speed better.

In terms of your actual question then, there is no problem adding additional arrays/spindles, even if they are a different speed or size, but do make the db parts the same size on each array and never have more than one db part on one spindle if you are using commit cache. Even though you will get slightly better speed if you play with the sizes in ratio to the speed its not worth it.

Also though its not necessary to backup restore when adding an extra db Part say adding one more array when you already have 4), in this case I agree with Ahmed that you should do a backup restore to correctly share the data over the DB parts and get ideal spindle sharing.

PS the above is from actual experience, I first found out about the size speed balance when called in to do some performance tunning at a client who's IT dept had split the db over rather a bizarre combination of drives. And had to do a lot of testing to prove that they needed to redo the whole thing.

PPS sorry Eric for contradicting your comment about the weakest link, but my experience has not shown that to be the case.

kriki

David Singleton wrote:

But to answer your actual question about Native. (And I wont comment about why a client with a 25 G system can not afford to go out and buy the 10 or 12 drives aka 5 or 6 RAID1 Arrays that they really should be using). So...

All these things can be reduced to this:
Most companies in Italy can only see the "NOW" with a cost NOW and a gain NOW. If there isn't a gain NOW, it is a cost and not an investment.

David Singleton wrote:

until you run out of cache and get the dreaded "Commit cache is full warning message".

I think this is a message with the older versions of Navision (at least before 2.01). With 2.01 I have had a routine that filled up the commit cache (at a certain point it went to a crawl and I noticed the write-queue always around the same value).
But it never produced that message.

David Singleton wrote:

I have a NAV SQL system that I use often, that has the LOG file on the OS disk ... My Laptop I had very large task to run on a 50G DB, and to try this out, I moved the LOG file onto an external bus powered 4000rpm USB drive, just so it would be separate from the OS, and the performance difference was immediately noticeable. Even allowing for the time to move the file to the USB drive and back it was worth it.

Ok, but here (I suppose) you had the system, the DB, the log on the same physical drive. I was talking about the ONLY the system and the log on 1 drive and the DB on another.

Waldo wrote:

That's a good test .

May be one tip for your laptop ... you can change the recovery model to "simple" so it won't use a TL .

Not completely correct: each transaction is still writen to the TL, but after a "breakpoint", it is thrown away and the TL is reused without increasing it's size. (the prove : a restore is 1 transaction, so you need a TL +- as big as the DB).

David_Singleton

PS Alain, can you split this thread into a NATIVE thread and a SQL thread, its all a mess now.

kriki

Split the Topic into 2 topics: 1 for Native (this topic) and 1 for SQL : 1 x RAID1 RPM10000 + 2 x RAID1 RPM15000:SQL

gvolkov

get a SAN with fiber network adapters.

gvolkov

get a SAN with fiber network adapters. that will speed it up, and you will see the difference

colin_leversuch-roberts

not necesscarily!