New SQL Install help

By philldmc ·
I'm fairly new to SQL and my company is going over to a new software package that requires SQL. We are a small company, at first we will only have 3 users.

I tried finding a "best practice" or installation guide and could not find much. I originally configured the Dell PE2900 with two RAID 1's, The first RAID 1 would be for the OS and support files, (146GB x 2, drives 0,1) and the second RAID 1, (146GBx2, drives 2,3) for the SQL and Data base, with a global hot spare (drive 4, 146GB). All drives are SCSI.

However, where I seem to have an issue is knowing where to install the SQL program and database. Originally I wanted to install it on the second RAID set, seperate from the C drive, however SQL wants to install itself on the C drive, therefore making me think that the database will install there as well.

In addition I've read that a RAID 10 is optimal for SQL, should I go ahead and configure my 5 hard drives in a RAID 10 with a hot spare? if so, how do I partition the SQL...or is it designed to be installed only on the C drive?

Any wisdom would help.



This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

MS SQL I presume

by LarryD4 In reply to New SQL Install help

If I remember cleary during our install the SQL engine itself wants to install on the C Drive, but you can put a SQL database anywhere you want.

Check out technet it will show you the install options for which ever SQL server your using..


Collapse -

SQL Engine

by philldmc In reply to MS SQL I presume

So from what you said, the SQL engine itself needs to stay on the root drive, "C" drive.

Database files can be installed on a seperate partition.

So basically, allow the SQL setup wizard to install all defaults and when I go to install the software package that requires SQL that can be installed on a seperate section of the drive?

Collapse -

I want to say yes

by LarryD4 In reply to SQL Engine

I'm pretty sure that was the end result when I installed SQL 2000.

But if its one of the newer version you may want to check technet.

Collapse -

By default

by Tony Hopkinson In reply to SQL Engine

The executables etc, go on C.
The system database Master, MSDB etc will be created there too.

You can move them if you wish. As for putting different databases (or event arts of databases on different drives, there is no 'ideal' generic solution. Aside from basics like putting the log file on one drive and the data file on another, alot depends on how you use the data.

One of the things you can do is spread a database across a set of drives, so if generally the users will be looking at a coherent section of the database say by department, and rarely do cross department work...

Another trick is to put you most used tables on your highest spec/speed drives.

Like any optimisation there are objectives and limits where it's not worth the effort of doing more.

Try a generic set up, monitor and then twiddle. It should all be completely transparent from the client side, so personally I wouldn't sweat getting it right first time too much, just avoid the obviously dumb for your first go.


Collapse -

Thanks for your reply

by philldmc In reply to By default

This is going to be a single SQL database, as of now only 3 users will be accesing the data, all the HDD's are the same, SATA SCSI, 146GB 15K, I'm still unsure if I want to go with two RAID 1's or a RAID 10, either way I still have a hot spare.

I'm confused as to the benifit if the SQL engine is on C but the data or log files in on E, doesn't everything still have to travel through the SQL engine on C?

Collapse -

I would be too

by Tony Hopkinson In reply to Thanks for your reply

I will explain better.

A SQL Server database consists of a minimum of two files.
The MDB (data) and the ldb (log). They are what you want to put on separate drives if available.

The exe's you might as well keep on the 'system' drive with winders and such.

The meta databases Master, MSDB and such, I personally haven't seen a valid argument for moving in terms of performance.

Master among other things holds the names locations and layout of your 'user' databases', can't see much point in moving them 'further' away, and even less in splitting log and data as it's not as if they are going to be changing often or rapidly.

Related Discussions

Related Forums