SQL databases on M: drive?

[Jim Spear]

My server admin created my SQL box with 2 drives. Unfortunately he made a
small C drive and and a larger M: drive where he expects the databases to be
created. Isn't this backward? Can MSP Server handle a non-root drive for the
databases?
Thanks.

 

[Jim Spear]

Sorry, this is MSP Server 2007 and the installation will be on 3 boxes: SQL,
App, WFE.

 

[Paul Conroy]

If you are deploying a medium farm, you might even want to consider different
drives for databases, log & tempdb as it is expected that SQL data is NOT
stored on any system volumes.

Have you considered two WFE/App servers instead of a WFE and App split ?
This would give you improved performance and extra application resilience.

--
Please rate this post if it has helped

http://www.fundraiseonline.co.nz/TheProjectServerGuru/

http://theprojectserverguru.spaces.live.com

 

[James Fraser]

Sorry, this is MSP Server 2007 and the installation will be on 3 boxes: SQL,
App, WFE.

Fine and normal. Also, Project Server doesn't care where the DB files
are located. It talks to SQL and SQL Server needs to find the files.
SQL Server is fine with any drive. Be careful if the data files are on
a network device (such as a SAN.) Access delays here cause delays
everywhere else in the system.


James Fraser

 

[Paul Conroy]

Sure SAN's can cause delays when poorly specified/configured, as can every
aspect of the solution. A well configured SAN with multiple paths and well
defined fibre partitions will always be preferable to direct attached storage
which is limited by the number of spindles and therefore the number of disk
iops.

--
Please rate this post if it has helped

http://www.fundraiseonline.co.nz/TheProjectServerGuru/

http://theprojectserverguru.spaces.live.com

 

[James Fraser]

Sure SAN's can cause delays when poorly specified/configured, as can every
aspect of the solution. A well configured SAN with multiple paths and well
defined fibre partitions will always be preferable to direct attached storage
which is limited by the number of spindles and therefore the number of disk
iops. ....

Certainly, a decent SAN can outperform a small number of directly
attached hard drives. But it is easier to mis-configure or over
utilize a SAN compared with directly attached storage. I didn't mean
to imply that SANs are bad. I did mean to say that SANs can be bad,
and deserve extra attention.

When someone asks where they should put the database files, it
deserves a "Don't put them on a network because of latency." If they
know enough to minimize latency, then they can ignore the advice.


James Fraser