March 12, 2010 at 11:56 am
GSquared (3/12/2010)
I'm working on a book on my experiences with learning how to DBA. It'll definitely be written to take this kind of thing into account.
When do we get to see this book?
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
March 15, 2010 at 6:18 am
CirquedeSQLeil (3/12/2010)
GSquared (3/12/2010)
I'm working on a book on my experiences with learning how to DBA. It'll definitely be written to take this kind of thing into account.
When do we get to see this book?
I'm hoping to finish it later this year. After that, who knows? Might self-publish if I have to, but anything else is beyond my control.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
March 16, 2010 at 1:06 pm
Andy Warren (3/11/2010)
Not knowing but guessing, my thought is that auto-shrink makes a lot of sense for businesses (like cheap web hosting) that want to conserve disk space and aren't hugely worried about performance.
It's not just cheap web-hosting, it's any scenario in which the benefits of reduced size are greater than the performance cost of bad organisation on the disc. For small (but not extremely small) databases and for databases with a small, well-defined working set using auto-shrink can ensure that the discs are (for performance measurement purposes) write-only, and in fact the only disc activity is writing the log and lazily pushing dirty pages back to disc: if a very large proportion of the workload is read-only, this is a massive performance gain.
For SQLS 2000, it would probably be better if the advice not to use auto-shrink was sometimes qualified by explaining that circumstances in which it is useful do exist but are extremely rare and explaining what theose circumstances are, instead of just giving a blanket don't use it statement and pointing out the problems it causes (I'm not sure whether SQLS 2008 is the same, haven't enough experience of it yet). But I've been guilty of the blanket ban myself - telling my juniors not to use autoshrink while quietly introducing it into a couple of production systems myself - because it really is difficult to explain it properly.
Shifting from the side-issue (the particlar example used in the editorial) to my main point: it's a very good editorial, it explains an important point of editorial policy which in my view makes SQL Server Central much more useful than it would otherwise be. Thanks, Steve, and please keep up the good work.
Tom
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply