Sql-server – Allocating Filegroups and Storage

sql serverstorage

I have upto 10 databases running on a single SQL Server instance on a single server.

I have read about best practice for storage and concluded the following…

1) Transaction Log on own RAID array (Raid 10) or at least on own physical disk

2) Data files(secondary filegroup) on own disk array (Raid 10 or 5)

3) Indexes on own filegroup (Raid 5)

4) Primary on Raid 1 or 5 (only system dbs)

5) Tempdb on Raid 5 or 10

So each of the above will be on separate physical disks?

Should I then have a separate disk for each secondary filegroup of each database? Or can they reside on the same disk?
How would this impact on performance?

And similar again with each Primary filegroup – should each one be on its own disk? In this case 10 separate disks for each primary filegroup?

Thanks!

Best Answer

I just tried quickly to find an answer because there is a lot here, but this is a common question. Didn't find quite what I wanted yet so a few thoughts to guide you:

First: It depends is the default answer here.

It really depends on what the performance characteristics are of your system. You should review what your waits and filestats look like and consider where your pain points are and build according to that. There are sizing concerns and performance concerns.

A few thoughts to guide you:

RAID 5 can be fine for data files unless you are doing some heavy writes and performance becomes a concern. So this isn't always good, but a place I feel safe about RAID 5, again your mileage really varies based on your performance needs.
Mirroring or RAID 10 is where I tend to like to go with log files and TempDB.
In some environments, TempDB needs to be isolated onto it's own first because it is a shared resource and used when queries spill over from memory to disk as well.. In some environments, log files need to be isolated and get better performance because of the insert activity.. In some environments, data files need the best IO (heavy read/reporting).
You need to look at Filestats and Waitstats and Perfmon and really see where your pains are.

Using multiple file groups is a great approach/answer for certain workloads. Separating TempDB is usually a best practice though I'd never put TempDB on RAID 5 typically.

And if the environment is pushing no IO? Having no IO waits? I've seen and placed environments all one one big happy set of drives and things have been fine. It really depends on a lot.

I'd spend some time profiling your workload. Look at the PAL tool and run some perfmon scripts on your existing environment. Look at your SQL Server File Statistics. Read about some best practices in SQL Server IO, and make informed decisions and monitor to see how they look as you go.

Related Solutions

Sql-server – How to quantify TEMPDB usage in relation to other databases hosted on same hardware

Scott,

Check this statement out:

SELECT
    [Database] = DB_NAME ( qt.dbid ),
    [Execution Count] = SUM ( qs.execution_count ),
    [Total Execution Time] = SUM (qs.total_elapsed_time / 1000000.0 ),
    [Total CPU Consumption] = SUM ( qs.total_worker_time ),
    [Total Reads] = SUM ( qs.total_physical_reads ),
    [Total Writes] = SUM ( qs.total_logical_writes ),
    [Average Execution Time] = SUM ( qs.total_elapsed_time / qs.execution_count / 1000000.0 ),
    [Average CPU Consumption] = SUM ( qs.total_worker_time / qs.execution_count / 1000000.0 ),
    [Average Reads] = SUM ( qs.total_physical_reads / qs.execution_count ),
    [Average Writes] = SUM ( qs.total_logical_writes / qs.execution_count )
FROM sys.dm_exec_query_stats qs     
CROSS APPLY sys.dm_exec_sql_text ( qs.sql_handle ) qt     
LEFT JOIN sys.databases o ON qt.objectid = qt.dbid
GROUP BY qt.dbid

This should give you all of the information you need. If all you're interested in is disk usage just keep the total reads/writes and average reads/writes.

Sql-server – SQL Server 2012 Availability group disk configuration options

I would only use RAID 0 for the logs if you're okay with having reduced disaster recovery capability. You won't be able to make log tail backups in the event of a disk failure, and will only be able to restore to your most recent backup. However, this may be less of an issue if you're running Availability Groups, particularly with synchronous mirroring. You generally won't have any performance overhead for RAID 1 vs. a single non-RAID disk, but you will have better I/O performance with RAID 0 instead of RAID 1 for an equal number of disks.
Be aware that tempdb also has both data files and log files, and those could end up interfering with each other (performance wise) if placed on the same volume. You may want to consider foregoing the spare disk and using it for tempdb logs instead if performance still isn't acceptable. If your C: array is large enough, you might be able to get away with using it for on-disk backups, though you should probably partition it to prevent runaway backups from filling your OS disk.

Best Answer

Related Solutions

Sql-server – How to quantify TEMPDB usage in relation to other databases hosted on same hardware

Sql-server – SQL Server 2012 Availability group disk configuration options

Related Question