Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Sql2k, Performance and Junction Points

Status
Not open for further replies.

CallwaveEmp

Technical User
Aug 30, 2002
106
Hi All.
We have been configuring our Larger SQL Servers with the following disk
layout:
c:\ OS
d:\ SQL Server Executables
e:\ Database Files, tempdb.
f:\ Database Logs.

I would like to adjust this a bit by using junction points to link folders
on E and F back to the D:\...\MSSql, then place the database files in these
folders. The files will still be on different disks, however, as far as SQL
Server is concerned, the files will be stored in D:\...\mssql\TDATA an
D:\...\mssql\TLog. This will alow us to standardize our configurations
better - we can move files to a SAN, or other DAS, but the SQL Server
configurations are the same.

A developer in our group claims that without the files explicitly being on a
different drive ("E:/F:") SQL Server will not paralellize the queries, and
we will lose performance. I am hoping that this is incorrect, can anyone
confirm?

Dave

 
Dave,
I'm not sure if that will slow you down or not. However I'm not sure what you will be gaining by doing this. I do know that you will be loosing some CPU power because every call that is made to the virtual folder on the disk will need to be redirected to the correct disk by Windows, which could cut down on the amount of CPU available to SQL.

I don't see how doing this will assist you with keeping your configs the same if you move to a SAN or DAS. When you mount drives from a SAN to a server you mount them as new drive letters on the server. We have several servers here on SANs and DASs and the SAN/DAS drives are all mounted as drive letters.

Denny

--Anything is possible. All it takes is a little research. (Me)

[noevil]
(My very old site)
 
When a database moved from DAS to SAN (which will begin happening in the near future), I can just down the server, copy the files to the new volume, and relink the disk to the same location. I don't need to engage a DBA to do this.

Also, we use smaller, 1U servers for development. The databases and logs can go in the same directories on D, without linking. We then have consistent configurations across dev and production.

Dave
 
You can do the same thing with drive letters. When you move databases from one drive to another and especially from DAS to SAN you should have the DBA envolved. The'll need to do backups, let you know what drive config will be best for the database and log files based on the system needs.

If you link the drives, what happens if you end up with a couple of database drives? I wouldn't worry about drive letters being the same between dev and production. SQL Server doesn't care what the drive letters are. And having different drive letters between dev and production will have little effect.

How will linking the data drives to the d drive effect monitoring drive performance and disk capacity? How will disk queueing, wait times, data written to disk be displayed in perf mon?

Denny

--Anything is possible. All it takes is a little research. (Me)

[noevil]
(My very old site)
 
Good point about Drive performance, although junction points are *not* included in drive capacity - I still monitor the capacity of E and F separately.

I did find a QA Whitepaper on configuring Seibel with Sql Server on a SAN. It indicates that there is no performance impact of using SQL Server on Mount Points (
D
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top