SQL Madness / Server Build Config

[MuttsNutts]

Building a new SQL server now i have been provided a Dell R620, 2x 8Core Xeons, 128Gb Ram, Perc710m with 1Gb Cache Controller

It has 6 558Gb SAS drives but are only 10K so im looking at replacing these with 15K drives and the server has 8 disk slots

 

Obviously Server 2016 Stn & SQL 2016 Std now im looking to get best i can from it.

it's coming from an old oracle DB and being converted to SQL (out sourced that task lol) approx 40Gb

 

so im thinking of 8x 300Gb 15K disks and become mindbent on the options to do it all

 

Option 1

Raid 10 all 8 disks and then just partition into for disks for O/S, Logs, DB & TempDB?

 

Option2

4 disks Raid 10 for O/S & TempDB

4 disks Raid 10 for DB & Logs

 

or any variant anyone would advise like O/S and logs on said Raid Set

 

Option3

2 disks Raid 1 for O/S

2 disks Raid 1 for Logs

2 disks Raid 1 for tembDB

2 disks Raid 1 for DB

(No hot spares here i know)

 

Any other config you'd like to advise

Edited January 26, 2018 by MuttsNutts

[3s-gtech]

From memory of the last time I set this up, I think option 2 is your best bet. Partitioning alone isn't enough - the DB and other services want to be on separate arrays for the best performance. Our SIMS server (MSSQL) is virtualised and the DB is still on a separate array of RAIDed SSDs.

[JackCPickup]

OBR10 would be the modern recommendation, split arrays is an old approach unless you're doing properly tiered storage with SSDs for cache.

[MuttsNutts]

OBR10 would be the modern recommendation, split arrays is an old approach unless you're doing properly tiered storage with SSDs for cache.

 

Thanks - This is what i thought these days one big raid 10 - it's what i did for my recent mail server exchange and exchange logs on OBR10 (I still stuck the O/S on a Raid1 though) but with SQL the concept of seperate raids was not just access speed it's the fail point of a raid, if it fails you have to recover the whole server i know it's unlikly to fail but it does happen, as if its on separate raids then only need to recover which ever raid fails and with SQL it's more likely be the raid that holds the DB that fails and pretty easy to recover with good backups.

 

And

 

3s-gtech

From memory of the last time I set this up, I think option 2 is your best bet. Partitioning alone isn't enough - the DB and other services want to be on separate arrays for the best performance. Our SIMS server (MSSQL) is virtualised and the DB is still on a separate array of RAIDed SSDs.

 

Thanks - this is why i was thinkin 2x Raid 10's almost the benefit of OBR10 but with the protection of the O/S and Logs on one and DB and tempDB on the other.

 

Tobe totally honest i would of spec-ed up a better server storage wise one that could hold more disks for starters and then SSD the **** out of it lol - but i get "heres a server make a new SQL out of it"

 

Any more advise would be good - i have time to play but not too much