April 16, 2008 at 11:23 pm
Jeff Moden (4/16/2008)
Do they look as bad as the sprocs found in SQL Server? I was amazed at how cruddy some of them are... sp_SpaceUsed is one of my favorites to rag about. They had the perfect opportunity to not only make it set-based, but with just a little imagination, they could have made it so it would work for all tables in the database in just about the same time that it works for just one. Instead, they chose RBAR on steroids.
A significant number of the Sharepoint sProcs used to service interactive queries have cursors built-in.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
April 17, 2008 at 4:40 pm
Jeff Moden (4/16/2008)
escaleraroyal (4/16/2008)
update.Vendor says the same applicationX runs fast in another company1 which has a higher volumne of data. He thinks it's our clustering server that is causing the issue as company1 does not use clustering server. I think I disagree with this cause our clustering server runs lots of stored procedures and SQL Jobs and other different applications and we do not have issues with them besides this applicationX.
Still, the only problem is that the vendor wrote crap code... break out your bat and make them fix it!
Jeff, I said the same aplication is run in another different company3 and this company3 has even more data than my company and its FAST. How could it be the code? I know cursors are bad. But How could you tell me the application runs FAST in company3?
p.s. company3 has the same objects, same databases.
April 17, 2008 at 5:08 pm
escaleraroyal (4/17/2008)
Jeff Moden (4/16/2008)
escaleraroyal (4/16/2008)
update.Vendor says the same applicationX runs fast in another company1 which has a higher volumne of data. He thinks it's our clustering server that is causing the issue as company1 does not use clustering server. I think I disagree with this cause our clustering server runs lots of stored procedures and SQL Jobs and other different applications and we do not have issues with them besides this applicationX.
Still, the only problem is that the vendor wrote crap code... break out your bat and make them fix it!
Jeff, I said the same aplication is run in another different company3 and this company3 has even more data than my company and its FAST. How could it be the code? I know cursors are bad. But How could you tell me the application runs FAST in company3?
p.s. company3 has the same objects, same databases.
"More data" does not equate to "More data with the same distribution" or "More data that is affected by this piece of code". Most companies buy products, and only use some of it: there's no guarantee that this job is being used at all at company X.
Besides - code sometimes needs to be adjusted. One size never fits all. He may or may not be right about the SAN, but who should know? What exactly did he base his assessment of "it's the SAN"? Proof, or even some amount of evidence of such statements would actually be nice before he passes the buck.
Even if the SAN is slowing things down somewhat - that doesn't get him off the hook for crappy code... My position is - I'll take that under advisement (as to the SAN), but until the problem is resolved - you're not off the hook...
----------------------------------------------------------------------------------
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?
April 17, 2008 at 5:29 pm
Matt Miller (4/17/2008)
escaleraroyal (4/17/2008)
Jeff Moden (4/16/2008)
escaleraroyal (4/16/2008)
update.Vendor says the same applicationX runs fast in another company1 which has a higher volumne of data. He thinks it's our clustering server that is causing the issue as company1 does not use clustering server. I think I disagree with this cause our clustering server runs lots of stored procedures and SQL Jobs and other different applications and we do not have issues with them besides this applicationX.
Still, the only problem is that the vendor wrote crap code... break out your bat and make them fix it!
Jeff, I said the same aplication is run in another different company3 and this company3 has even more data than my company and its FAST. How could it be the code? I know cursors are bad. But How could you tell me the application runs FAST in company3?
p.s. company3 has the same objects, same databases.
"More data" does not equate to "More data with the same distribution" or "More data that is affected by this piece of code". Most companies buy products, and only use some of it: there's no guarantee that this job is being used at all at company X.
Besides - code sometimes needs to be adjusted. One size never fits all. He may or may not be right about the SAN, but who should know? What exactly did he base his assessment of "it's the SAN"? Proof, or even some amount of evidence of such statements would actually be nice before he passes the buck.
Even if the SAN is slowing things down somewhat - that doesn't get him off the hook for crappy code... My position is - I'll take that under advisement (as to the SAN), but until the problem is resolved - you're not off the hook...
matt,
Then how do u explain me. the vendor running the application with my PRD database in his company'S environment and IT'S FAST!!!
April 17, 2008 at 6:09 pm
escaleraroyal (4/17/2008)
Jeff Moden (4/16/2008)
escaleraroyal (4/16/2008)
update.Vendor says the same applicationX runs fast in another company1 which has a higher volumne of data. He thinks it's our clustering server that is causing the issue as company1 does not use clustering server. I think I disagree with this cause our clustering server runs lots of stored procedures and SQL Jobs and other different applications and we do not have issues with them besides this applicationX.
Still, the only problem is that the vendor wrote crap code... break out your bat and make them fix it!
Jeff, I said the same aplication is run in another different company3 and this company3 has even more data than my company and its FAST. How could it be the code? I know cursors are bad. But How could you tell me the application runs FAST in company3?
p.s. company3 has the same objects, same databases.
Think about it... how does a clustered server work and how well do you think it's going to work with a cursor. And, if the vendor insists that the other company works so great, find out who they are and call them.
The bottom line is that you paid for some software and it's not working. Either get the vendor to fix it so it works on your configuration, or ask for a refund.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 17, 2008 at 7:09 pm
escaleraroyal (4/17/2008)
matt,Then how do u explain me. the vendor running the application with my PRD database in his company'S environment and IT'S FAST!!!
I don't, and like it or not, I don't actually have to - you do. All I can do is tell you what I would do, which is to say that noone "rests" until the problem I have is fixed.
Some cluster setups, especially with SANs, can be misconfigured, and behave badly. That being said - a well tuned SAN setup will outperform a locally-attached setup, and by quite a bit (you'd certainly hope so, since you paid a LOT for the privilege). Jumping on the SAN bandwagon is a possibility, but until you have PROOF that that's causing the issue, don't stop digging. All I am trying to point out is that while you should probably make sure that said SAN is in fact tuned correctly, but should NOT stop pursuing any possibility until said issue is fixed.
If I know that there is less than ideal code somewhere, then I make a stink. I don't care that it works well somewhere else, since they're not my concern. Call me brutal on my vendors, but them's the rules as far as I am concerned.
----------------------------------------------------------------------------------
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?
April 18, 2008 at 1:19 pm
In a hurry while at an airport, so I may have missed a few connections/items.
1) SANs do NOT always outperform DAS. Given equal spindles it can often be a good bit slower due to all of the delays along the way between CPU and actual physical disks in the SAN. The most demanding environments I know of actually use DAS for tempdb and tempdb logs due to the throughput gains. Add in the fact that a large percentage of SAN installations for SQL Server are misconfigured (often grossly so) and SANs usually disappoint those to purchase them from a performance standpoint.
2) This issue does NOT have to be the vendor's fault. a) someone could have dropped an index or three. Has a reference-schema comparison been done? b) has any waits-stats analysis been done? c) the hardware could simply be not up to the task. If I try to run a 10K seat SAP installation on a 5 year old single-cpu box with with 2 hard drives it will NOT be performant and yet the vendor would be quite appropriate in telling me it ran fast on their test platform.
3) the cursor mentioned, while likely inefficient, may be required due to other issues. Again, without doing a plan and wait stats analysis one can't make a definitive statement that the cursor is causing the performance issue.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply