Logical Drives on a Solid State Platter

Question

Logical Drives on a Solid State Platter

rchantler

SSCrazy

Points: 2128
More actions
December 7, 2018 at 7:47 am

#380965

In the olden days we meticulously separated the system files from data files from log files and from tempdb. So we would configure a server with C: D: L: and T: logical drives, where each was implemented separately as some form of RAID array built with spinning drives.
Now, in the current century we still create the logical drives but they all reside on top of a single RAID array built with solid state drives. The rationale is that the latency of spinning drives is gone and all access is via random (direct) methods at electronic switching speeds rather than sequential and mechanical.
Any comments on this? I know it violates a long-established canon of DBA lore but is the separation principle still valid in the solid state world?
Thanks for any comments.

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply

ChrisM@Work SSC Guru Points: 186127 More actions · Answer 1

rchantler - Friday, December 7, 2018 7:47 AM
In the olden days we meticulously separated the system files from data files from log files and from tempdb. So we would configure a server with C: D: L: and T: logical drives, where each was implemented separately as some form of RAID array built with spinning drives.
Now, in the current century we still create the logical drives but they all reside on top of a single RAID array built with solid state drives. The rationale is that the latency of spinning drives is gone and all access is via random (direct) methods at electronic switching speeds rather than sequential and mechanical.
Any comments on this? I know it violates a long-established canon of DBA lore but is the separation principle still valid in the solid state world?
Thanks for any comments.

One or two of our servers from 5 years ago were configured exactly like this. They've not been exposed to significant io pressure, and I suspect that if they were, the bottleneck would be the either the storage controller or the channels within it (I think ours are 8-channel and we only use 1 or 2).

^{“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw}

For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

Jeff Moden SSC Guru Points: 1004311 More actions · Answer 2

rchantler - Friday, December 7, 2018 7:47 AM
In the olden days we meticulously separated the system files from data files from log files and from tempdb. So we would configure a server with C: D: L: and T: logical drives, where each was implemented separately as some form of RAID array built with spinning drives.
Now, in the current century we still create the logical drives but they all reside on top of a single RAID array built with solid state drives. The rationale is that the latency of spinning drives is gone and all access is via random (direct) methods at electronic switching speeds rather than sequential and mechanical.
Any comments on this? I know it violates a long-established canon of DBA lore but is the separation principle still valid in the solid state world?
Thanks for any comments.

I still do the separation just for the sanity sake. It also keeps a runaway TempDB from getting too big. Just a mental form of logical separation these days, though.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Michael L John One Orange Chip Points: 27054 More actions · Answer 3

I still create separate drives, only because it's easy to see things.

Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/

ZZartin SSC-Dedicated Points: 30920 More actions · Answer 4

Maybe in some extreme use cases you might get some benefit from separate physical SSD's but for most system compared to spinning drives it would probably never matter.

Eric M Russell SSC Guru Points: 125560 More actions · Answer 5

rchantler - Friday, December 7, 2018 7:47 AM
In the olden days we meticulously separated the system files from data files from log files and from tempdb. So we would configure a server with C: D: L: and T: logical drives, where each was implemented separately as some form of RAID array built with spinning drives.
Now, in the current century we still create the logical drives but they all reside on top of a single RAID array built with solid state drives. The rationale is that the latency of spinning drives is gone and all access is via random (direct) methods at electronic switching speeds rather than sequential and mechanical.
Any comments on this? I know it violates a long-established canon of DBA lore but is the separation principle still valid in the solid state world?
Thanks for any comments.

If you're working in Azure SQL, then the concept of logical drives and placement of files is entirely gone.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

goher2000 SSCertifiable Points: 5479 More actions · Answer 6

spend some time and you will find out, I use separate drives regardless of SSD or spin drive just to maintain standard in environment. it does make things easier, I don't have to logon to box to find out if log drive is full or data,

here is an example https://www.sqlskills.com/blogs/paul/benchmarking-multiple-data-files-on-ssds-plus-the-latest-fusion-io-driver/ , it talks about files not drives.

Jeffrey Williams SSC Guru Points: 90303 More actions · Answer 7

goher2000 - Friday, December 7, 2018 12:34 PM
spend some time and you will find out, I use separate drives regardless of SSD or spin drive just to maintain standard in environment. it does make things easier, I don't have to logon to box to find out if log drive is full or data,
here is an example https://www.sqlskills.com/blogs/paul/benchmarking-multiple-data-files-on-ssds-plus-the-latest-fusion-io-driver/ , it talks about files not drives.

Agreed - it is still valuable for managing space on the drives to have them separated...I prefer having a dedicated drive for system databases/logs, user databases and tempdb at a minimum. For larger systems I separate tempdb and transaction logs - and for very large databases I will separate out individual database files to dedicated mount points for all data and log files.

Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”

― Charles R. Swindoll

How to post questions to get better answers faster
Managing Transaction Logs

Ed Wagner SSC Guru Points: 287026 More actions · Answer 8

I also maintain different drives for data and log files. I take advantage of the separation and track total and free space per drive daily. It lets me measure growth over time and project drive space shortages. Being able to anticipate lets me give my SAN admin notice when I'll need more space allocated...they hate surprises.

Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions

Andy DBA SSCommitted Points: 1776 More actions · Answer 9

Michael L John - Friday, December 7, 2018 11:16 AM
I still create separate drives, only because it's easy to see things.

Agreed! With separate drives one can quickly create a performance counter for each drive and then tell at a glance where the high io is.

rchantler SSCrazy Points: 2128 More actions · Answer 10

rchantler

SSCrazy

Points: 2128

December 10, 2018 at 2:12 pm

#2015940

Separate logical or physical drives?

Andy DBA SSCommitted Points: 1776 More actions · Answer 11

rchantler - Monday, December 10, 2018 2:12 PM
Separate logical or physical drives?

Not sure who you're asking, but I meant "logical". We use VMware Virtual disks. I've never confirmed it, but I've been told performance would be exactly the same if we just put everything on one big C: drive as opposed to having separate logical drives.

rchantler SSCrazy Points: 2128 More actions · Answer 12

Andy DBA - Monday, December 10, 2018 2:33 PM
rchantler - Monday, December 10, 2018 2:12 PM
Separate logical or physical drives?
Not sure who you're asking, but I meant "logical". We use VMware Virtual disks. I've never confirmed it, but I've been told performance would be exactly the same if we just put everything on one big C: drive as opposed to having separate logical drives.

Thanks. I think most of the comments that still like having separate drives actually meant separate logical drives as opposed to separate physical drives. Even without VMare, where you can have a big physical RAID array and distribute the space over a set of drives if you wish.

Jeffrey Williams SSC Guru Points: 90303 More actions · Answer 13

rchantler - Monday, December 10, 2018 2:54 PM
Andy DBA - Monday, December 10, 2018 2:33 PM
rchantler - Monday, December 10, 2018 2:12 PM
Separate logical or physical drives?
Not sure who you're asking, but I meant "logical". We use VMware Virtual disks. I've never confirmed it, but I've been told performance would be exactly the same if we just put everything on one big C: drive as opposed to having separate logical drives.
Thanks. I think most of the comments that still like having separate drives actually meant separate logical drives as opposed to separate physical drives. Even without VMare, where you can have a big physical RAID array and distribute the space over a set of drives if you wish.

Actually - my preference is separate physical drives as seen by the host. The volumes can then be mounted to a drive letter or to a mount point - but each volume is a separate unit presented to the server(s) from the SAN.