Comments on: Filegroups and Non-Clustered Indexes

By: Rob Farley

Rob Farley — Fri, 31 Oct 2014 21:24:35 +0000

Hi Vijay,
I wouldn’t worry. Separating indexes off is far less important than the things you’ve suggested around having separate disks for data files, log files, and tempdb. You could put your backups across the network even (if it’s fast enough). The biggest thing to consider here is that MDFs and LDFs and Tempdb have different styles of disk activity, and should use disk that’s configured to cater for that particular style.
If it’s easy to seperate stuff out even more, then maybe indexes, but it’s not a huge priority.
Rob

By: Vijay Anand Madhuranayagam

Vijay Anand Madhuranayagam — Thu, 30 Oct 2014 13:34:04 +0000

Rob,
We already have everything on a single filegroup for a small business standard edition of SQL Server 2008 R2 database. Database size is 30 GB approximately.
We are going to move the already existing SQL Server 2012 Standard Edition DB server to the new cloud environment. We are asked to suggest the partition of the disk storage for SQL Server DB Server. We allot one for MDF, 2nd one for LDF, Third one for Backups and the Fourth one for TempDB. Our Technical Director insists us to create another drive for Indexes voluntarily. Allotting a separate drive for Indexes is a good move?
If not in which situation we can do that. If yes, will this improve the performance for this much of small database?
Thanks & regards,
Vijay

By: Rob Farley

Rob Farley — Tue, 14 May 2013 06:45:30 +0000

Hi Andrew,
When the volumes are all part of the same drive, I do find myself wondering if it’s worth separating them out or not. Generally, multiple volumes that map to the same physical drive array are there for one of two reasons. One is ignorance, but the other is that it’s in anticipation of the configuration being used on a different server. I frequently see Dev/Play environments where the volumes are all on the same physical disk(s), but that the plan is to deploy to a machine where they are separate. So I don’t want to say "Yes, if it’s all part of the same RAID array, don’t bother separating it", but do make a conscious decision about what you want to do and why you want to go down that path.
Rob

By: Andrew Rowlings

Andrew Rowlings — Tue, 14 May 2013 06:16:32 +0000

Hey Rob, do you normally still go to the trouble of putting indexes in a separate filegroup on a separate disk when the disks presented to the server are all part of the same RAID array? Cheers.

By: Brad Schulz

Brad Schulz — Thu, 14 Mar 2013 17:26:44 +0000

Hi Rob…
As I understand it, the DEFAULT filegroup only comes into play when you do a CREATE TABLE. In other words, if no ON clause is specified with the CREATE TABLE command, it’s created on the DEFAULT filegroup. However, when you do a CREATE INDEX (without an ON clause), the index is created on the same filegroup as the table that’s being indexed… not the DEFAULT one.
I guess that makes sense… even though, as you say, it’s "almost never what [you] want."
(Love your date-population query, by the way)
–Brad

By: Rob Farley

Rob Farley — Tue, 12 Mar 2013 16:30:28 +0000

Well, if you have some "write this" commands, it can be better to involve multiple disk controllers, rather than having it all go through the one.

By: sheen81

sheen81 — Tue, 12 Mar 2013 15:24:01 +0000

Hi, Rob, good post. Can you explain more about "it can be nice to have transactions which update both the clustered and non-clustered indexes using different disks", better with a quick example? Just a few sentences. Thank you.

By: Rob Farley

Rob Farley — Tue, 12 Mar 2013 13:26:59 +0000

Yeah, there are a bunch of reasons to think carefully about index storage. I really think they deserve to be considered more carefully that they typically are.

By: tobi

tobi — Tue, 12 Mar 2013 13:22:02 +0000

Also, even append-only workloads might fragment a table and its index to 100% if both are on the same filegroup (even if nothing else is on that filegroup). They might get every other extent allocated. Using a FG per partition solves that (and AFAIK is the *only* thing that solves it proactively).
SQL Servers allocation algorithms are really awful and I have already complained about it on connect.