July 13, 2010 at 4:45 pm
Gianluca Sartori (7/12/2010)
I think yesterday it was Emperor Paulpatine's birthday.Happy birthday, Paul!
Heh... does it mean more Vuvuzelas?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 4:46 pm
I have a problem with the word "NEVER."
I can see where databases may change names from environment to environment. Ideally, they should have the same name from one environment to the next. I can also see where you would want to avoid the use of the "Use" statement in Stored Procs.
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
July 13, 2010 at 4:48 pm
Roy Ernest (7/12/2010)
Congrats Jeff... Hopefully I will see you all at the Pass Summit..!!!!
Thanks, Roy. Like they say down South, "Can't wait to meet all'y'all!"
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 4:49 pm
Here's another one in the same doc.
As a rule of thumb, once a table has more than five indexes, updates to that table may be adversely affected since the system must also update all of the indexes.
I think that is an odd rule of thumb.
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
July 13, 2010 at 4:55 pm
GilaMonster (7/12/2010)
CirquedeSQLeil (7/9/2010)
Oh and Congrats Jeff.Ditto.
Aye... thanks old friend. I'm very much looking forward to finally meeting you in person.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 5:00 pm
Chad Crawford (7/12/2010)
Jeff Moden (7/9/2010)
I promise to publish it right after PASS if it's not called upon.🙁 I don't want to wait. I had to build a hierarchy on 2005 (no HierarchyID), so I did my own research and rolled my own implementation. It's not been heavily used, but was getting ready for a big push on it since it is faster and better than the current solution. I'd love to see what you did before I commit to my implementation and get everyone to move over. DRAT! DRAT! DRAT!
Chad
Hmmm... according to Steve's compliment and encouragement, you may not have to wait. :discuss:
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 5:03 pm
Steve Jones - Editor (7/12/2010)
Chad Crawford (7/12/2010)
Jeff Moden (7/9/2010)
I promise to publish it right after PASS if it's not called upon.🙁 I don't want to wait. I had to build a hierarchy on 2005 (no HierarchyID), so I did my own research and rolled my own implementation. It's not been heavily used, but was getting ready for a big push on it since it is faster and better than the current solution. I'd love to see what you did before I commit to my implementation and get everyone to move over. DRAT! DRAT! DRAT!
Chad
Publish it now. There's no "great secret" to keep until the presentation. You talking about it will add value to what's written, even if they've read it.
Everything, or nearly everything I see Paul Randal present is written down on his blog or elsewhere. Doesn't change the desire to see him talk.
Ya know... that actually sounds like a great idea. If nothing else, the discussion that's sure to follow would be a great way to work out any kinks. Guess I'll finish putting it together a little sooner than I planned and submit it as an article. Thanks, Steve.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 5:05 pm
You are welcome and looking forward to seeing it.
July 13, 2010 at 5:36 pm
Trey Staker (7/12/2010)
Hearing the ops story reminded me of someone I worked with when I was new in my career. He had been working in IT/Technology a long time probably 15 to 20 years. My boss had hired him to do cabling and I kept having to explain some of the basics over and over with him every day. His work was a little slow but the results were excellent.The reviewing the basics got old quick. After a couple of weeks I had a one on one with my boss and I found out that this person had mentored my boss but had a stroke a few years earlier.
Now, there's a question for a survey... should the boss give you a heads up on such a thing before the new employee shows up or should the new employee be afforded some privacy that will eventually be necessarily broken?
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 5:38 pm
CirquedeSQLeil (7/13/2010)
Here's another one in the same doc.As a rule of thumb, once a table has more than five indexes, updates to that table may be adversely affected since the system must also update all of the indexes.
I think that is an odd rule of thumb.
Me, too, especially since it only takes one really bad one to make things go totally haywire.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 5:42 pm
Jeff Moden (7/13/2010)
CirquedeSQLeil (7/13/2010)
Here's another one in the same doc.As a rule of thumb, once a table has more than five indexes, updates to that table may be adversely affected since the system must also update all of the indexes.
I think that is an odd rule of thumb.
Me, too, especially since it only takes one really bad one to make things go totally haywire.
And yet I've heard it more than once from more than one source.
--------------------------------------
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
July 13, 2010 at 5:48 pm
Jeff Moden (7/13/2010)
CirquedeSQLeil (7/13/2010)
Here's another one in the same doc.As a rule of thumb, once a table has more than five indexes, updates to that table may be adversely affected since the system must also update all of the indexes.
I think that is an odd rule of thumb.
Me, too, especially since it only takes one really bad one to make things go totally haywire.
That was my thinking as well. One bad index could really offset a query. And i have seen 10+ indexes on a table with no noticeable impact.
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
July 13, 2010 at 5:50 pm
CirquedeSQLeil (7/13/2010)
Anybody have any comments on this nugget?•Never include a USE <database> statement in scripts.
I just found this in a doc here at work.
I'd like to see the context it was used in, but I believe in just exactly the opposite which has saved some folk's bacon (especially mine) more than once that I can remember. My feeling is that all {manual} scripts should be required to have the following code as the first 4 lines...
--===== Identify the database to use
USE [PutDataBaseNameHereAndRemoveNextLineBeforeRunning];
RETURN;
GO
Of course, I don't normally have such manual scripts in my database but I do require a USE statement for every script submitted by a developer especially for "data cleanup" scripts. For data cleanup scripts, I also require a BEGIN TRANSACTION statment and hard coded row count expectations in the form of print statements for any and all queries that modify production data. If the row counts match when I run them (after a quick code review, of course), only then will I commit the run.
I'm serious, especially concerning the "Data cleanup" scripts... the method of specifying hardcoded row count expectations has saved us from having to do DB restores more than once due to data changes that occured between the time the script was written/tested and the time the script was executed during a scheduled change control by the DBA.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 5:56 pm
Stefan Krzywicki (7/13/2010)
Jeff Moden (7/13/2010)
CirquedeSQLeil (7/13/2010)
Here's another one in the same doc.As a rule of thumb, once a table has more than five indexes, updates to that table may be adversely affected since the system must also update all of the indexes.
I think that is an odd rule of thumb.
Me, too, especially since it only takes one really bad one to make things go totally haywire.
And yet I've heard it more than once from more than one source.
I'm not sure where or how these rules of thumb are actually developed but I try to keep them from spreading especially when there is no proof offered with the related hearsay.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 13, 2010 at 6:01 pm
CirquedeSQLeil (7/13/2010)
WayneS (7/13/2010)
WayneS (7/12/2010)
Fellow Threadizens - I'm having problems getting ssis pkgs/maint plans on a second (named) instance on a 2-node cluster running from the standby node. If you can help, please check out this post.Thanks!
Anyone have any help for this? I'm running out of hair to pull out!
I posted a slew of questions for you.
Thanks! They did help.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
Viewing 15 posts - 16,321 through 16,335 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply