SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Achieve Better Performance


Achieve Better Performance

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)

Group: Administrators
Points: 65623 Visits: 19118
Comments posted to this topic are about the item Achieve Better Performance

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
jjeffryes
jjeffryes
Forum Newbie
Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)

Group: General Forum Members
Points: 6 Visits: 49
Steve,

Thanks for your newsletter editorial entitled, "Achieve Better Performance." I loved the collection of links, which neatly summarize essential skills.

I think the aims of improving database performance and cultivating technical skills are achievable if institutionalized. That means putting them on the schedule for consistent attention. I bought copies for my whole team of a lovely book by Dan Tow entitled, "SQL Tuning." We read and study the book together, meeting every week for a one-hour session we call "Tuning Tuesday." We recently dove into statistics and the benefits to our enterprise have already begun rolling in, just as you suggest in your editorial.

I expect to enjoy looking at your other links, too, because these basic issues come up for us as well.

Jai Jeffryes
Steve Jones
Steve Jones
SSC Guru
SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)

Group: Administrators
Points: 65623 Visits: 19118
Thanks, glad you liked it.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (90K reputation)SSC Guru (90K reputation)SSC Guru (90K reputation)SSC Guru (90K reputation)SSC Guru (90K reputation)SSC Guru (90K reputation)SSC Guru (90K reputation)SSC Guru (90K reputation)

Group: General Forum Members
Points: 90245 Visits: 41146
Great Editorial. Now all we need is a link that teaches managers and developers how not to over-promise and one that teaches developers how to get over the "just get it off my plate" syndrome. ;-)

It all boils down to the simple rules that "Good enough usually isn't" and that "If you want it real bad, that's the way you'll usually get it". :-P

The bottom line is that it takes time to learn how to write good code and unit test it with enough data to know if it will perform well. Too many people won't take the time to do either. That's why SSDs and things like Hekaton are such a draw... they promise the gift of performance for crap code. w00t

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
ITGuy268
ITGuy268
SSC-Enthusiastic
SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)SSC-Enthusiastic (142 reputation)

Group: General Forum Members
Points: 142 Visits: 281
Hi Steve,

Thank you for another great article in Database Weekly Smile

Currently being between roles I have noticed how BIG performance is in the list of requirements for many roles I am applying for. I am going through each of the links and so far I have found every one useful. Not that I am trying to plug any one piece of software but I have SQL stuff set up in Evernote and have been making notes on each of the subjects and clipping useful articles for future reference.

Thanks again for a great article with so many good links in one place - I had to keep it!

Cheers,

Dan :-D

MCTS | MCITP | Microsoft SQL Server 2008 Administration & Development
MCSA | MCSE | Business Intelligence SQL Server 2012
Gary Varga
Gary Varga
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16935 Visits: 6534
Jeff Moden (7/1/2013)
Great Editorial. Now all we need is a link that teaches managers and developers how not to over-promise and one that teaches developers how to get over the "just get it off my plate" syndrome. ;-)

It all boils down to the simple rules that "Good enough usually isn't" and that "If you want it real bad, that's the way you'll usually get it". :-P

The bottom line is that it takes time to learn how to write good code and unit test it with enough data to know if it will perform well. Too many people won't take the time to do either. That's why SSDs and things like Hekaton are such a draw... they promise the gift of performance for crap code. w00t


The sad thing for me as a developer is that I come across far too many DBAs who are not only significantly worse than me but also don't give a [insert favourite ending here]. Even worse for developers. Rarely a consideration of when there will be more than 20 rows.

Ah, the ol' technology to speed up poorly written code. Developers (and perhaps DBAs) have relied on hardware too long to achieve this.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Tom Thomson
Tom Thomson
SSChampion
SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)

Group: General Forum Members
Points: 14764 Visits: 12238
Jeff Moden (7/1/2013)
Great Editorial. Now all we need is a link that teaches managers and developers how not to over-promise and one that teaches developers how to get over the "just get it off my plate" syndrome. ;-)

It all boils down to the simple rules that "Good enough usually isn't" and that "If you want it real bad, that's the way you'll usually get it". :-P

I would disagree on one point there, mostly because you need some nested quote marks but also because I don't agree with your "never": good enough always is good enough - but "good enough" is sometimes a lie, sometimes a mistake, and only rarely good enough; and I've sometimes written stuff which I knew would have a lifetime of only a few days, so that honing the performance would have been a waste of resource - good enough was good enough those times.

The really big problems are as you say, over-promising and the "just hand it over" syndrome. In my experience over-promising is almost always committed by junior/middle management or by salesmen, and is the result of timescale pressure from the top and/or from prospects. Bonus schemes for salesmen make them very vulnerable to such pressure, especially when the penalties of their overpromising damage development bonuses, not sales bonuses, and of course the fact that the company has been committed and will lose face leads to top management refusing to accept realistic dates. Training salesman to promise nothing not already committed by development/QA/Release teams and persuading those teams to do proper estimating instead of going for "what's the earliest we could possible do this if everything goes just right" might solve the problem if the people concerned are trainable. "Just get it of my plate" should be a firing offence; developers indulge in it, so do QA types, and so do development/QA management. In a developer it is usually the worst sort of laziness: I can't be bothered to do this properly because I want to get on to the next interesting thing instead of finishing this boring old stuff. In managers it's often a pass-the-buck strategy: maybe if I sign this off and hand it over to Fred he'll get blamed for any delays, not me.
The bottom line is that it takes time to learn how to write good code and unit test it with enough data to know if it will perform well. Too many people won't take the time to do either. That's why SSDs and things like Hekaton are such a draw... they promise the gift of performance for crap code. w00t

SSDs and in-store databases change the game somewhat. Using that sort of thing to try to make lousy code run faster is usually futile, and I don't much like it even when it works.

However, just as large scale random access storage devices allowed performance that was unimaginable using serial mag tape, and necessitated new algorithms/designs to exploit them properly, devices with zero seek time and effectively zero search time (SSDs) will allow us to do new things and may mean that we need to learn new tricks to exploit them properly.

The same applies even more strongly to in-memory databases, which aren't really particularly new - Hekaton is in a sense old-hat. The cache algorithms in SQL 2000 were such that certain of the NEOS databases were effectively resident on our customer sites (while others on the same sites were non-resident) giving a big performance boost: of course the NEOS databases were designed to behave like that, without using any of that silly table-pinning stuff. What Hekaton brings is elimination of a lot of overheads in buffer handling, because no page of the database can be dropped from the buffer. Back in the late 80s/early 90s I was working on massively parallel systems with in-store database (using at different times our own fully declarative destined to be in-store database system and Oracle OMPS) and the projects I was involved in were certainly not the only ones addressing in-store databases in those 10 years. We probably need to learn new tricks to exploit in-store databases, just as we do to exploit SSD storage - and many of those new tricks may be common to both technologies.

Tom

Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search