October 27, 2014 at 2:41 pm
The documentation says put log files and tempdb on separate database partitions. We use raid 5 using C for the O/S and the SQL front end and D for all of our databases and log files. Is their a better way?
When the snows fall and the white winds blow,The lone wolf dies but the pack survives.
Once you've accepted your flaws, no one can use them against you.
October 27, 2014 at 2:49 pm
October 27, 2014 at 3:56 pm
Um, thanks sqlVogel for that utterly useless link. Slightly funny, but utterly useless.
fizzleme (10/27/2014)
The documentation says put log files and tempdb on separate database partitions. We use raid 5 using C for the O/S and the SQL front end and D for all of our databases and log files. Is their a better way?
The reason you want log files on a separate partition comes from back when you had more direct physical control over what went on each drive. Logs are write forward events. For best throughput, you want dedicated spindles for each unique log file so that the head never has to move except when writing your log, giving you the most efficient I/O. The more often the head moves from that spot, the more time spent waiting to write your logs.
Tempdb is a very bouncy (spindle wise) database, precisely because of how it's used. Thus, they don't necessarily play nice with each other. Even worse, tempdb also has its own log!
So, that's why the documentation says that.
Sure there are better ways, but they're more expensive. Without knowing more specifics about the hardware you have (# of Raid Controllers, # of drive slots, drives themselves, # of dbs, expected data churn, etc) noone here can give you a default "better way" without throwing you a pie in the sky "Best of the Best" kind of plan... which noone can usually afford. 😉
So, approach this from the other side. Why is your front end on the same server as the database? Are you encountering I/O difficulties in data calls? Have you reviewed the plans of the problem queries and determined it's simply cost of doing business or are there places they can be repaired or use alternate approaches? Is something slow and are you watching your baseline spike at times for I/O? Have you determined what causes the I/O spikes?
That's a lot of questions, I know, and I surely don't expect you to immediately answer them. However, to answer your original question, you'll want to start looking at these questions. It'll help you get the knowledge you need to find your answer, or come back to us with enough specifics that we may be able to offer more solid ideas of what to do than "Um, maybe this?"
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply