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 123»»»

I'm sick of poor third-party software performance Expand / Collapse
Are you tired of complaints/requests from end users wanting you to fix poorly-performing third-party software?
Poll ResultsVotes
Yes...I can't take it anymore!!!
 
29.41%
5
No...I love solving problems!
 
29.41%
5
Don't care...there'll always be poorly-performing third-party software.
 
41.18%
7
Member Votes: 15, Anonymous Votes: 0. You don't have permission to vote within this poll.
Author
Message
Posted Tuesday, December 11, 2007 10:13 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 9:47 AM
Points: 1,546, Visits: 1,334
With all the third-party software being installed and connected to SQL server, DBAs are expected to work miracles and fix these badly performing applications. I'm tired of it! Anyone else?
Post #431906
Posted Tuesday, December 11, 2007 2:30 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 4:53 PM
Points: 36,795, Visits: 31,257
Not enough answers in the Poll... for the reasons you stated, I simply don't allow 3rd part software into my database without a full peer review for form, fit, function, and performance.

--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 #432050
Posted Tuesday, December 11, 2007 10:07 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Today @ 11:35 AM
Points: 33,102, Visits: 15,213
Lots of time there's nothing I can do. App vendors want to sell software, not build the best quality they can. Deals get cut above my head, I just deal with it.

I've learned to work around some of their issues, putting up my own indexes, etc.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #432132
Posted Wednesday, December 12, 2007 12:05 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:21 PM
Points: 42,495, Visits: 35,566
Yup. I've seen some nasty stuff from vender software. From 38 indexes in one table, with the same leading column, to 'temporary' tables that don't get dropped (we had 150000 tables after a year and we didn't know if we could drop them) to reimplementing the nested loop join in CLR.

Jeff, I envy the position you have. Here we get absolutely no say in what products are bought (except for DBA-type tools) and have to 'make it work' regardless of what.

Usually the database team are the last people consulted about anything, from product purchases, to server specs, to table and database design

*sigh* Sorry, I'm ranting again



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #432150
Posted Wednesday, December 12, 2007 12:38 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 4:53 PM
Points: 36,795, Visits: 31,257
No, no... the rant is understood and appreciated. When I first reported to my company, they had and average of 640 deadlocks a day with spikes to 4,000, no documentation in the code, and every time the DBA went to promote some code to production, it would always fail on the first run.

So, working with the DBA's, we ganged up on everyone... we wrote/published standards and told management how close they were to having a server meltdown... and that was no lie.

It was a long hard battle to lock things down and get people educated (including the appdev and other managers) about the right way to write code... but it was worth it!


--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 #432159
Posted Wednesday, December 12, 2007 1:55 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:21 PM
Points: 42,495, Visits: 35,566
Jeff Moden (12/12/2007)
No, no... the rant is understood and appreciated. When I first reported to my company, they had and average of 640 deadlocks a day with spikes to 4,000, no documentation in the code, and every time the DBA went to promote some code to production, it would always fail on the first run.


Sounds similar to this place 2 years ago, though we just had massive performance and stability issues, not deadlocks. Through a lot of work and an upgrade to SQL 2005, we got things stable and moderatly fast. I wrote coding standards, with change management and the DBA manager instituted code reviews. offered help and advice to developers, etc

For a while, things were fine, but recently we've been backsliding, and IT's reputation is going downhill, along with the quality of the solutions we're putting out.

In theory, I'm supposed to approve any code going into production. In reality, if I say it's not up to standard and is likely to cause problems, I get overridden by management 3+ levels above me. <sarcasm> After all, we can aways fix it later, right? </sarcasm>

It was a long hard battle to lock things down and get people educated (including the appdev and other managers) about the right way to write code... but it was worth it!


I'm tired of fighting now. Every week its the same battle. Every time we have an incident, the same things come up in the post-mortem, but nothing ever changes.

We've got no data architects. We've got two application architects who were promoted to that position from development. They've got no architect training, though they are trying very hard to learn. The developers often design the tables without any input. There's no technical managment in the developer area. The PMs promise dates without consulting anyone, then push to make those dates regardless.

I usually find out about new development when it's too late to change the table design (once development is complete usually, sometimes a day before deployment)

Think I'm going to go and have a nice long chat with my boss now.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #432180
Posted Wednesday, December 12, 2007 6:31 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 9:47 AM
Points: 1,546, Visits: 1,334
What other answers would you put in there, Jeff? Thanks.
Post #432270
Posted Wednesday, December 12, 2007 6:54 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:11 AM
Points: 7,122, Visits: 15,031
GilaMonster (12/12/2007)
Yup. I've seen some nasty stuff from vender software. From 38 indexes in one table, with the same leading column, to 'temporary' tables that don't get dropped (we had 150000 tables after a year and we didn't know if we could drop them) to reimplementing the nested loop join in CLR.

Jeff, I envy the position you have. Here we get absolutely no say in what products are bought (except for DBA-type tools) and have to 'make it work' regardless of what.

Usually the database team are the last people consulted about anything, from product purchases, to server specs, to table and database design

*sigh* Sorry, I'm ranting again


Oh I hear that - I knew I was in trouble when I actually got the "lead developer" of one of these gems to go look up "normalization". There have been times where I've found myself "isolating" them 3rd party products, and starting to cut off its various features to replace them with ones I've written that will actually work without killing a dedicated server.

It's amazing how much better their code gets when they figure out that you're about to create your OWN improved version of their POS product (and no - that doesn't stand for "point of sale").


----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #432282
Posted Wednesday, December 12, 2007 8:41 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 4:53 PM
Points: 36,795, Visits: 31,257
What other answers would you put in there, Jeff? Thanks.


Heh... Like what? There's no magic fix, no instant answers to such problems and all of the fixes take time, extreme knowledge, and a whole lot of determination... sometimes, it takes a hell of a lot of risk on your part if you believe in either the company or the people you work for.

Unless you can show management the ROI of doing things more wisely, it will continue to be a problem... the big problem is that management frequently knows the cost of everything and the value of nothing. Sometimes, it simply takes a server meltdown and someone with the nads to step up and say "I know how to fix that" and then do it.

For those who've gotten tired of "the fight", I feel for ya and I've almost (but not quite) been there. Sometimes, management borders on the fringes of absolute ignorance about quality code and it's tempting to just give up. You either have to "re-muster the fight" in you, leave, or be satisfied with being a code drone. I've never done the 3rd and never will, although I have learned which battles to fight and when to leave. Remember that the managment you may be fighting against also have bosses they must answer to. Let them do their job and you do yours... help them if you can.

It doesn't have to be a "fight" so much as recognizing or even seeking out an "opportunity"... sometimes you can just educate folks in management by saying/doing something like "We had this one 30 minute run that sometimes fails that I thought could be reworked... I worked on it after hours, got it down to 6 seconds, and I can't make it fail. I think I know a couple of other places where we might make similar improvements." You'll need to demo what you've done and prove that it produces the same correct results reliably... after a couple/three of those small wins, they'll actually start to believe it. Be prepared to demo a big win right after that and be prepared to defend yourself against "nay-sayers" without being arrogant or defensive. Stick to the facts only and make sure the "facts" are right. And never ever bad mouth other folks' code... always make it a "mentoring/helpful/cheerful" experience. "I think there may be other similar opportunities for improvement" usually works a lot better than "This is crap code and it needs to be fixed NOW!"

Here's another huge point... once you've gained some respect as a "goto" person, if you're not willing to coach others and "let people see it your way", you're doomed to "drone-dum". If you're not willing to stop what you're doing to help someone else, don't expect the same in return from either your peers or managment.

Also, it's ok, maybe even a requirement, to be confident... but the first sign of arrogance on your part will kill managment's opinion of you and, just like the fastest gun in the West, will invite every nay-sayer there is to challenge you. Build your own authority by being politely correct in everything you say and do. If you don't know something, say so... and then tell them what you're going to do to change that. That will also earn you a huge amount of respect and surprising numbers of allies that will bust a hump for you.

Above all else, remember that your only job is to make the people you work for look good (sometimes, despite themselves). Contrary to popular belief, that's all you were hired for.

That's probably more than you guys wanted to hear, though, huh? :P But that's precisely what I've done to be successful. Speaking of success... Napoleon Hill wrote a book called the "Law of Success"... the nineth "lesson" in that book teaches "The Habit of Doing More than Paid For" and it's a darned good habit to get into... I know it works for me 'cause I've noticed that I don't have to "fight" as much as most. :D

And for all of those who have grown weary of the "fight"...

"If you have tried and met with defeat; if you have planned and watched your plans as they were crushed before your eyes; just remember that the greatest [people] in all history were the products of courage, and courage, you know, is born in the cradle of adversity." --Napoleon Hill

... be great.


--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 #432629
Posted Wednesday, December 12, 2007 9:20 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 11:50 AM
Points: 2,706, Visits: 3,789
Hear Hear, Jeff!

And to add another catch phrase ... "You catch more flies with honey than with vinegar" :D



______________________________________________________________________

Personal Motto: Why push the envelope when you can just open it?

If you follow the direction given HERE you'll likely increase the number and quality of responses you get to your question.

Jason L. Selburg
Post #432637
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse