Solved

user and system DB on system drive

Posted on 2014-10-28
2
114 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
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 30

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

Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The Delta outage: 650 cancelled flights, more than 1200 delayed flights, thousands of frustrated customers, tens of millions of dollars in damages – plus untold reputational damage to one of the world’s most trusted airlines. All due to a catastroph…
It is possible to export the data of a SQL Table in SSMS and generate INSERT statements. It's neatly tucked away in the generate scripts option of a database.
This video shows, step by step, how to configure Oracle Heterogeneous Services via the Generic Gateway Agent in order to make a connection from an Oracle session and access a remote SQL Server database table.
Via a live example, show how to set up a backup for SQL Server using a Maintenance Plan and how to schedule the job into SQL Server Agent.

624 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