sql-server-2008
Is it worth moving the SQL Server system databases master, model and msdb from the default install path on the main OS hard drive over to their own drive?
I've already moved TempDB on to 2 separate drives one for the log file and one for the data file and am just wondering if its worth doing the same to the other system database or if this is overkill and will see little to no benefit?
Assuming it's a user database, detach the database, move the .mdf / .ldf files to the new location and reattach the database. You might need to browse to the new location of the .ldf file when you choose your .mdf file in the reattach screen.
To detach a database, right-click on it in management studio and choose Tasks | Detach.
To reattach, right-click on Databases in management studio and choose Attach..., then browse to the new location of your .mdf and .ldf files.
For system databases it's a little more involved, especially the master db. Have a look at this MSDN article that gives you the steps. Pay attention to the info regarding the resources system db for SQL2005+.
This was actually fixed awhile (back in July '12) ago with a paid support call from Microsoft.
Since this has gotten so many views, I've decided to add a redacted version of our "email summary" of the call with Microsoft.
Posted is a link to pastebin: http://pastebin.com/QqNz7xYd
Hope this info will help anyone with this issue
Problem Description:
=============================
You Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) default instance on SERVERNAME server and you were trying to start the SQL SERVER service which was failing to start.
Analysis\Troubleshooting:
=============================
We checked the SQLS SERVER ERRORLOG
===========================
2012-06-20 19:33:41.48 Server Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)
Apr 2 2010 15:48:46
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.0 <X64> (Build 6001: Service Pack 1)
2012-06-20 19:33:41.50 Server (c) Microsoft Corporation.
2012-06-20 19:33:41.50 Server All rights reserved.
2012-06-20 19:33:41.50 Server Server process ID is 2596.
2012-06-20 19:33:41.51 Server System Manufacturer: 'HP', System Model: 'ProLiant DL360 G5'.
2012-06-20 19:33:41.51 Server Authentication mode is MIXED.
2012-06-20 19:33:41.51 Server Logging SQL Server messages in file 'D:\Mssql\Data\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG'.
2012-06-20 19:33:41.51 Server This instance of SQL Server last reported using a process ID of 2816 at 6/20/2012 6:10:15 PM (local) 6/20/2012 10:10:15 PM (UTC). This is an informational message only; no user action is required.
2012-06-20 19:33:41.51 Server Registry startup parameters:
-d D:\Mssql\Data\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\master.mdf
-e D:\Mssql\Data\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG
-l D:\Mssql\Data\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\mastlog.ldf
2012-06-20 19:33:41.56 Server SQL Server is starting at normal priority base (=7). This is an informational message only. No user action is required.
2012-06-20 19:33:41.56 Server Detected 4 CPUs. This is an informational message; no user action is required.
2012-06-20 19:33:41.65 Server Using locked pages for buffer pool.
2012-06-20 19:33:41.88 Server Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node. This is an informational message only. No user action is required.
2012-06-20 19:33:42.33 Server Node configuration: node 0: CPU mask: 0x000000000000000f:0 Active CPU mask: 0x000000000000000f:0. This message provides a description of the NUMA configuration for this computer. This is an informational message only. No user action is required.
2012-06-20 19:33:42.49 spid7s Starting up database 'master'.
2012-06-20 19:33:42.86 spid7s Resource governor reconfiguration succeeded.
2012-06-20 19:33:42.86 spid7s SQL Server Audit is starting the audits. This is an informational message. No user action is required.
2012-06-20 19:33:42.87 spid7s SQL Server Audit has started the audits. This is an informational message. No user action is required.
2012-06-20 19:33:42.87 spid7s FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'MSSQLSERVER'.
2012-06-20 19:33:43.02 spid7s SQL Trace ID 1 was started by login "sa".
2012-06-20 19:33:43.03 spid7s Starting up database 'mssqlsystemresource'.
2012-06-20 19:33:43.05 spid7s The resource database build version is 10.50.1600. This is an informational message only. No user action is required.
2012-06-20 19:33:43.24 spid10s Starting up database 'model'.
2012-06-20 19:33:43.24 spid7s Server name is 'SERVERNAME'. This is an informational message only. No user action is required.
2012-06-20 19:33:43.27 spid10s The database 'model' is marked RESTORING and is in a state that does not allow recovery to be run.
2012-06-20 19:33:43.28 spid10s Error: 927, Severity: 14, State: 2.
2012-06-20 19:33:43.28 spid10s Database 'model' cannot be opened. It is in the middle of a restore.
2012-06-20 19:33:43.36 spid10s Could not create tempdb. You may not have enough disk space available. Free additional disk space by deleting other files on the tempdb drive and then restart SQL Server. Check for additional errors in the event log that may indicate why the tempdb files could not be initialized.
2012-06-20 19:33:43.36 spid10s SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.
===========================
From ERRORLOG we can see that SQL SERVER trying to bring model database online but since model database in recovery state hence we were unable to run database recovery.
We also know that whenever SQL SERVER start we recreate TEMPDB database by coping the content from model database.
Now since model database didn’t started hence TEMPDB startup also failed which is one of critical system database and this caused SQL SERVER service to failed
Solution:
=====================================
· To fix this issue we started SQL SERVER EXE with following parameter from command prompt
SQLSERVR.EXE -c -T3608
· Then after we detached model database using following T-SQL
sp_detach_db model
· Then after we attach the model database using following T-SQL
================================
USE MASTER
GO
CREATE DATABASE MODEL
ON (FILENAME = 'C:\PROGRAM FILES\MICROSOFT SQL SERVER\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\MODEL.MDF')
FOR ATTACH ;
================================
· After that SQL SERVER service came online successfully
Best Answer
I see not reason for moving them at all -- they are small DBs that are cached in memory pretty much all the time. You are not going to make changes very often in those DBs (writes) to have them moved to another drive to gain some additional performance.