Solved

user and system DB on system drive

Posted on 2014-10-28
2
97 Views
Last Modified: 2014-11-12
Do any of you store your system and user databases on your servers system drive, or do you store them on non system drives? Are there any risks in keeping them on the system drive, or any benefits in moving them to non system drives?
0
Comment
Question by:pma111
2 Comments
 
LVL 22

Accepted Solution

by:
Steve Wales earned 250 total points
ID: 40408609
By default, Microsoft puts the system databases on the C: drive.

The major risk is that if something happens where one of the databases starts growing uncontrollably (which shouldn't happen with a system database but you never now) and the OS drive fills, then Windows grinds to a halt.

If tempdb is on your OS drive and your app or developers create huge temp tables frequently, that could cause it too.

Microsoft provides this note for moving system databases: http://msdn.microsoft.com/en-us/library/ms345408.aspx
0
 
LVL 29

Assisted Solution

by:Rich Weissler
Rich Weissler earned 250 total points
ID: 40408611
On small servers, especially single purpose / express edition servers... I sometimes only have a single volume/drive to work with.

On slightly larger servers, the hardware guys will split out a system drive from the data drive, but it uses the same physical RAID set.  At that point, I believe I have a disadvantage of separating anything, and I put all the databases on the data drive.  (If the data drive fills up, that's bad, but it doesn't prevent the system from patching or cause operating system problems.)

On larger systems, I usually have a system volume, which will only have the database executables.  On different volumes I have the (1) database files, (2) transaction log files, and (3) [slowest disks] backup files.  But all that only applies when the different disks aren't on common physical disks... usually when I have volumes on the SAN.  If I had even large systems still, I'd split off the tempdb to it's own volume as well.

In my environment, the benefit to splitting the databases to a non-system volume is (hopefully) decreased I/O contention.  (Page file, OS Logs, and patching operations are written to the system volume.  All the database stuff should only have to contend with I/O traffic on it's own set of disks.)
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Everyone has problem when going to load data into Data warehouse (EDW). They all need to confirm that data quality is good but they don't no how to proceed. Microsoft has provided new task within SSIS 2008 called "Data Profiler Task". It solve th…
In this article I will describe the Backup & Restore method as one possible migration process and I will add the extra tasks needed for an upgrade when and where is applied so it will cover all.
Familiarize people with the process of utilizing SQL Server functions from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Ac…
Via a live example, show how to shrink a transaction log file down to a reasonable size.

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now