March 12, 2008 at 4:45 am
I have always installed SQL Server (2000 and 2005) on the c drive of the server, and placed the data and log files on seperate disks.
Our network administrator says it should be installed on the d drive and c should be left just for the windows install. Is there any benefit in this? It seems to be causing a problem with our SAN having SQL Server installed on the c drive. Anyone else had similar problems?
Thanks
Danny
March 12, 2008 at 4:51 am
Danny (3/12/2008)
I have always installed SQL Server (2000 and 2005) on the c drive of the server, and placed the data and log files on seperate disks.Our network administrator says it should be installed on the d drive and c should be left just for the windows install. Is there any benefit in this? It seems to be causing a problem with our SAN having SQL Server installed on the c drive. Anyone else had similar problems?
Thanks
Danny
When you say that you place the data and the log files to separate disks, do you also mean the temp, model, master ... databases or just the user databases?
Regards,
Andras
March 12, 2008 at 5:21 am
Just the user databases.
Regards
Danny
March 12, 2008 at 6:08 am
Hi Danny, depends on your system but it can be goodpractice to put tempdb on a seperate RAID Configuration of its own and the other system databases on a different set of disks.
As for SQL installation. I have worked in places where its on the c with the OS and sepreated on a different partition. Doesn't make too much difference in my opinion. Serpeating keeps the SQL install off the OS partition.
Gethyn Elliswww.gethynellis.com
March 12, 2008 at 6:15 am
Only issue is space on the C: drive. Lots of stuff wants to be there, including SQL patches. The error logs can grow, so potentially you'd move them (service parameter), but otherwise no issue with the install on C.
March 12, 2008 at 6:18 am
I have installed SQL Server and the data files in C Drive in the past, and no at least one reason for it.
Windows has its own temp files and page files. By default they are created in C: Drive. When you have your dta and log files (specially temp db) you tend to fill the drive faster than expected. Now if you dont monitor the disks and do a planned cleanup, then may fill the hard disk and as a result Windows may fail to start. Its a painful process of restarting and cleaning the disks when such things happen. If your data files are not in the same drive, ebven if your drive gets full, it will not affect windows
As a best practice, i suggest not to touch SQL server. You may install the program files there but make sure that you dont even take the backups in that drive.
Cheers,
Prithiviraj Kulasingham
http://preethiviraj.blogspot.com/
March 12, 2008 at 9:09 am
Additionally, you can not completely avoid a SQL footprint on C. Shared tools, among other files, will be installed on C regardless of what you set up during the install process to do otherwise.
What sorts of problems are being caused in the SAN from SQL being installed on C versus D?
- Tim Ford, SQL Server MVPhttp://www.sqlcruise.comhttp://www.thesqlagentman.com http://www.linkedin.com/in/timothyford
March 12, 2008 at 10:03 am
SQL was installed on the d drive on another server by a third party. Our network administrator seems to think it is best practice to do so. For consistency he wants the SQL installations to be the same, therefore the files are picked up in the same way by the SAN. From what I seen there is no problem having SQL server installed on c:, looks like this is the default and most common way.
Thanks
Danny
March 12, 2008 at 10:25 pm
Danny (3/12/2008)
From what I seen there is no problem having SQL server installed on c:, looks like this is the default and most common way.
Have you ever tried to get the disk activity of the drive where data fiels are. If you have them on a different drive, it is easy to identify them otherwise, the counters will be the combination of all (windows and SQL Server) operations.
Cheers,
Prithiviraj Kulasingham
http://preethiviraj.blogspot.com/
March 13, 2008 at 2:28 am
I always place the user data and log files on a seperate disk. I may start doing this for the system databases aswell. But I think I will keep the SQL install on c:
Thanks
Danny
March 14, 2008 at 3:27 am
A lot of Windows Administrators like to keep the system drive reserved for the OS as far as possible. If this is happening at your place it is a site standards thing, and you should accept it. (Would you like it if your users wanted to do things outside your DBA standards?)
The Windows people should give you another drive where you can put the SQL binaries. However, SQL will always use some space on the system drive, as it puts a lot of things into the GAC which always lives on the system drive. You should assume that after 3 years of patches, SQL will have filled 2.5 GB on the system drive, with about 0.5 GB extra needed while fixes are applied.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
March 14, 2008 at 4:49 am
I can see your point and would follow policy on a new install (this has just been introduced). The problem is SQL Server is installed on the system drive with live databases running. Is it worth the effort re-building just so SQL Server is not on the system drive, with no massive benefits?
Thanks
Danny
March 14, 2008 at 5:43 am
My take is that if the Windows admins want it moved for existing installs, they need to show the costs, downtime, risks and benefits involved in the move. If presented with this information, most managers (even some pointy-haired ones) would say leave SQL where it is until the server needs to be rebuilt - the benefits are not worth the hassle of the move.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
March 24, 2008 at 1:03 pm
I stumbled upon this post searching for a solution on how to restrict access to the C:\ drive from SQL Server.
My immediate issue is I have Dev, QA and UAT SQL servers have most of my users have Admin access to. They need to be able to restore new DB's to these servers all day. The problem comes in if the user incorrectly restores the DB to the C:\ Drive consuming its valuable resources.
Any suggestions?
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply