Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Achieve Better Performance Expand / Collapse
Author
Message
Posted Saturday, June 29, 2013 11:07 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 5:59 PM
Points: 31,082, Visits: 15,529
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
Post #1468811
Posted Monday, July 1, 2013 7:40 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, August 29, 2014 8:04 AM
Points: 3, Visits: 40
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
Post #1469062
Posted Monday, July 1, 2013 10:01 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 5:59 PM
Points: 31,082, Visits: 15,529
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
Post #1469137
Posted Monday, July 1, 2013 5:25 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 11:18 PM
Points: 35,267, Visits: 31,759
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".

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.


--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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1469241
Posted Tuesday, July 2, 2013 6:29 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, September 22, 2014 3:29 AM
Points: 116, Visits: 246
Hi Steve,

Thank you for another great article in Database Weekly :)

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



MCTS | MCITP | Microsoft SQL Server 2008 Administration & Development
MCSA | MCSE | Business Intelligence SQL Server 2012
Post #1469445
Posted Wednesday, July 3, 2013 7:08 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:42 PM
Points: 5,471, Visits: 3,259
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".

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.


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!!!
Post #1470035
Posted Wednesday, July 3, 2013 12:59 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:57 PM
Points: 7,745, Visits: 9,493
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".

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.

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
Post #1470201
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse