March 26, 2011 at 8:35 pm
Lynn Pettis (3/26/2011)
Okay, poll time. How many of you are getting tired of Celko and his high horse?I may be wrong, but I think I could count on one hand the number of times any of his posts were truely helpful to the OP.
I haven't been around here as long as many of you, but I do find him annoying. I wouldn't have as much of a problem with him if it weren't for his frequently being wrong in the service of his cross-platform fetish.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
March 26, 2011 at 9:19 pm
Lynn Pettis (3/26/2011)
Okay, poll time. How many of you are getting tired of Celko and his high horse?I may be wrong, but I think I could count on one hand the number of times any of his posts were truely helpful to the OP.
I'm all for spirited debate, but he's probably the one person that I regularly wish Steve would finally just ban, permanently.
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
March 27, 2011 at 4:43 am
Lynn Pettis (3/26/2011)
Okay, poll time. How many of you are getting tired of Celko and his high horse?I may be wrong, but I think I could count on one hand the number of times any of his posts were truely helpful to the OP.
[raisehand]
While I think one should follow the ANSI SQL language where possible (if for no other reason than it makes it easier for others (say, from a non-T-SQL background) to quickly pick up what the code is doing), I also believe that one should utilize all of the tools available to you in solving problems. When you are in a box (let's just call it T-SQL), you should use everything in that box to solve your problems. Not just that little box packed inside (let's call that one ANSI). That bigger, T-SQL box includes things like the QU.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
March 27, 2011 at 7:41 am
Jeff Moden (3/22/2011)
Brandie Tarvin (3/22/2011)
<groan> Why oh why do the same "bad" solutions keep popping up when there are tons and tons and tons of articles telling people why it's a bad idea to follow the bad solution?<headdesk>
Where away?! I need to try launching some of my brand new "politically correct", high velocity, wire guided, directed blast with no collateral damage pork chops. 😀
It was this post that triggered Brandie. Mainly a language problem I think, Muthukkumaran was pointing out that shrinking the log is not the same as truncating it and that shrinking it is usually a very bad thing and should be reserved as an act of desperation, but he was doing this in the sort of Indian English that is completely opaque to most westerners (including both Brandie and Gail, who both thought that he meant just the opposite of what he did mean - not surprising, I would have thought the same if I hadn't been working with a lot of Indians in the last 10 years) and also in a context where it was fairly irrelevant (the recovery mode was simple so there was no chain for shrinking the log to break, and the log really had been expanded by an unusual event). I guess the simple solution would have been to checkpoint, shrink the DB (vast chunks of data had been deleted - tables dropped I think - and that was what had cause the log to grow ridiculously; why people don't lean to batch their massive deletes and call checkpoint after each batch I will never understand; but maybe the DB didn't need to be shrunk, only the log, in which case that step and the following checkpoint weren't needed), checkpoint again, reindex everything, checkpoint again, shrink the log to somewhere sensible. All sorts of other things were going on, one Indian (Sachin) quoted BoL on log truncation claiming that this showed that truncation and shrinking were the same (and got helpful comments pointing out the error of his ways, to which he reacted well) and various other idiocies continued. The OP solved his problem by doing some completely irrelevant things plus (eventually) roughly the right thing. I haven't yet read to the end of the thread - it's quite long, but also quite amusing. I wouldn't dream of joining in, especially at this late stage.
Tom
March 27, 2011 at 7:53 am
Tom.Thomson (3/27/2011)
Mainly a language problem I think, Muthukkumaran was pointing out that shrinking the log is not the same as truncating it and that shrinking it is usually a very bad thing and should be reserved as an act of desperation, but he was doing this in the sort of Indian English that is completely opaque to most westerners (including both Brandie and Gail, who both thought that he meant just the opposite of what he did mean
I went and read his blog post before jumping in, and the blog post was comprehensible. I only jumped in when other inaccuracies started getting tossed around
(the recovery mode was simple so there was no chain for shrinking the log to break, and the log really had been expanded by an unusual event)
.
Not that shrink ever truncates the transaction log...
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 27, 2011 at 9:05 am
Jan Van der Eecken (3/23/2011)
Craig Farrell (3/23/2011)
Jack Corbett (3/23/2011)
I'm not going to make the duck tour, but I am planning on getting into Boston somehow for the dinner. I hate driving in any city and Boston is always the worst. Any recommendations for parking?On the sidewalk or two lanes from the curb, like everyone else...
Boston: The only city I've ever seen where the drivers daily play 'Invent a Lane'...
Did they EVER finish the Big Dig?
Craig, 'Inventing a Lane' did not originate in Boston, it was first registered as a purely South African invention. Our "communal" taxis (can't call them bl@ck taxis) surely hold the copyright to that. Ask Gail if you don't believe me. :w00t:
You should visit Chennai some time (or Mumbai; or...)
Think of a pack of autorickshaws on the highway, mixed with heavy trucks, all sorts of car, a variety of motor bikes and scooters .... and no two drivers agree on how many lanes there are, or which lanes go in which direction, or even whether there are any lanes.
I very soon decided that I would never under any circumstances drive anything without top rate armour and massive stability on an Indian road; and as none of the car hire places do tanks, I never drove there.
Tom
March 27, 2011 at 12:00 pm
Jeff Moden (3/26/2011)
Koen Verbeeck (3/25/2011)
Maybe an article on why it is not necessary to maintain indexes. Who needs them right?(but maybe again, someone picks this up not realizing it is a joke)
Oddly enough, I've seen a couple of posts on SSC and a fair number more on other forums where people say index maintenance is not important if your {GUI} queries usually pick up on one row at a time because a scan won't be involved. Very spooky stuff and I can't believe that anyone would even say such a thing especially where a GUID or a customer account number is being used as the clustered index. I'm sure that some of the folks that listened to that advice will be back in a couple of months wondering how to shrink their database files.
Oh heck. You can just cut all the maintenance plans now. We only need to prop up these old style databases for another year or two. Then everything will be on the cloud and all our problems will be solved.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 27, 2011 at 12:50 pm
Grant Fritchey (3/27/2011)
Jeff Moden (3/26/2011)
Koen Verbeeck (3/25/2011)
Maybe an article on why it is not necessary to maintain indexes. Who needs them right?(but maybe again, someone picks this up not realizing it is a joke)
Oddly enough, I've seen a couple of posts on SSC and a fair number more on other forums where people say index maintenance is not important if your {GUI} queries usually pick up on one row at a time because a scan won't be involved. Very spooky stuff and I can't believe that anyone would even say such a thing especially where a GUID or a customer account number is being used as the clustered index. I'm sure that some of the folks that listened to that advice will be back in a couple of months wondering how to shrink their database files.
Oh heck. You can just cut all the maintenance plans now. We only need to prop up these old style databases for another year or two. Then everything will be on the cloud and all our problems will be solved.
(I have to ask...).... and does Red Gate have a product for that yet?
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
March 27, 2011 at 1:12 pm
Grant Fritchey (3/27/2011)
Oh heck. You can just cut all the maintenance plans now. We only need to prop up these old style databases for another year or two. Then everything will be on the cloud and all our problems will be solved.
All hail the mighty cloud! (or is that "smoke"?) 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 1:14 pm
WayneS (3/27/2011)
Grant Fritchey (3/27/2011)
Jeff Moden (3/26/2011)
Koen Verbeeck (3/25/2011)
Maybe an article on why it is not necessary to maintain indexes. Who needs them right?(but maybe again, someone picks this up not realizing it is a joke)
Oddly enough, I've seen a couple of posts on SSC and a fair number more on other forums where people say index maintenance is not important if your {GUI} queries usually pick up on one row at a time because a scan won't be involved. Very spooky stuff and I can't believe that anyone would even say such a thing especially where a GUID or a customer account number is being used as the clustered index. I'm sure that some of the folks that listened to that advice will be back in a couple of months wondering how to shrink their database files.
Oh heck. You can just cut all the maintenance plans now. We only need to prop up these old style databases for another year or two. Then everything will be on the cloud and all our problems will be solved.
(I have to ask...).... and does Red Gate have a product for that yet?
Sure... matches were invented a long time ago. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 1:18 pm
Tom.Thomson (3/27/2011)
I wouldn't dream of joining in, especially at this late stage.
Sage advice. I won't even look. Thanks Tom.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 1:22 pm
GilaMonster (3/26/2011)
Jeff Moden (3/26/2011)
Oddly enough, I've seen a couple of posts on SSC and a fair number more on other forums where people say index maintenance is not important if your {GUI} queries usually pick up on one row at a time because a scan won't be involved.That's actually correct (partially).
The only thing that fragmentation affects are range scans (largish ones) from disk. If all the DB is ever doing are singleton seeks, then fragmentation is not a concern and it's immaterial whether the index is 0% or 99% fragmented.
However very few systems only ever do singleton seeks.
In addition, index rebuilds don't just fragmentation, they also can compact the index if there's been page splits and the index pages are now only half full (on average). Rebuild with a higher fill factor.
Oh yes... I know it's partially correct. I just couldn't understand why anyone who knows of SQL would bring it up even as partial justification for not performing index maintenance.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 1:27 pm
Jeff Moden (3/27/2011)
Oh yes... I know it's partially correct. I just couldn't understand why anyone who knows of SQL would bring it up even as partial justification for not performing index maintenance.
Agreed. It's applicable in such a narrow set of circumstances.
I had someone at a usergroup meeting a couple years back argue for auto_create and auto_update stats off and a job to delete any stats created on the grounds that they're a waste if you're only ever doing single row selects and updates. It's true, but so, so, so few systems are going to be that way that it's dangerous advice because most people aren't going to understand the conditions.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 27, 2011 at 1:30 pm
WayneS (3/27/2011)
Grant Fritchey (3/27/2011)
Jeff Moden (3/26/2011)
Koen Verbeeck (3/25/2011)
Maybe an article on why it is not necessary to maintain indexes. Who needs them right?(but maybe again, someone picks this up not realizing it is a joke)
Oddly enough, I've seen a couple of posts on SSC and a fair number more on other forums where people say index maintenance is not important if your {GUI} queries usually pick up on one row at a time because a scan won't be involved. Very spooky stuff and I can't believe that anyone would even say such a thing especially where a GUID or a customer account number is being used as the clustered index. I'm sure that some of the folks that listened to that advice will be back in a couple of months wondering how to shrink their database files.
Oh heck. You can just cut all the maintenance plans now. We only need to prop up these old style databases for another year or two. Then everything will be on the cloud and all our problems will be solved.
(I have to ask...).... and does Red Gate have a product for that yet?
Well, since you asked, yes, Red Gate is starting to come out with Cloud based stuff. Here's one of the first ones.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 27, 2011 at 1:31 pm
Lynn Pettis (3/26/2011)
Okay, poll time. How many of you are getting tired of Celko and his high horse?I may be wrong, but I think I could count on one hand the number of times any of his posts were truely helpful to the OP.
During two different threads having to do with hierarchies, Celko suggested that I send him my thoughts and code for dealing with very large hierarchies (basically, the article I'm working on for SSC) to possibly be included in the 2nd edition of one of his books he's currently working on. I turned down the "fame and glory" (his words, not mine) because I really don't want to be associated with the man... or his horse. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 25,081 through 25,095 (of 66,738 total)
You must be logged in to reply to this topic. Login to reply