• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 410
  • Last Modified:

SQL install paths for 2008 R2

When installing SQL I have seperated the data directories as atatched.  

Basically i'm using:  S for data and L for Logs.  

Is it ok to gorup user database lops and temp DB logs into the same L partion?

Any other comments/observatins on the directories I've used.  This is my first SQL install.
SQL-install.docx
0
DHPBilcare
Asked:
DHPBilcare
  • 2
  • 2
1 Solution
 
Lee SavidgeCommented:
There is no reason why you shouldn't put the logs in the same partition. Basic installs will often see the database and logs in the same folder in the same partition. Larger scale system will separate these out onto different drives for performance.

If you've got a very high load on the system, then you could consider separating out the logs and data files onto separate drives but you need to balance performance out with cost and available hardware.
0
 
DHPBilcareAuthor Commented:
It's a system which could grow but at the start the load wont be that high.

I'm just deciding if there is any reason why I would not want to group user logs and temp DB logs into the same partition and likewise for the user database and TempDB.
0
 
Lee SavidgeCommented:
I personally can't think of a reason why you shouldn't.

With regards to growth and loadl this is a complex assessment to decide immediately. However, these things can be changed later so don't worry as nothing is st in stone and you probably won't get it dead on straight away anyway.
0
 
DHPBilcareAuthor Commented:
Thanks!
0
 
Kevin CrossChief Technology OfficerCommented:
I agree.  If it helps, a deciding factor for separating logs/data and, similarly, system databases from user ones is separate drive spindles and controllers.  If you have one set of physical drives partitioned into multiple volumes (logical drives), there really is not a difference in splitting up the data because you have not increased I/O capabilities in any way.  With multiple controllers, splitting up data files allows you to segment I/O of log away from data, system away from user, et cetera.

As stated, you likely will not guess right upfront, but do try to establish an initial size for tempDB and your databases that makes sense in a longer term.  In addition, take care with setting the file growth to something that will make sense as your data and usage grows.  In other words, growing a database in 1MB increments rarely makes sense in production.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now