From dgoulet@vicr.com Fri, 07 Sep 2001 06:41:25 -0700 From: dgoulet@vicr.com Date: Fri, 07 Sep 2001 06:41:25 -0700 Subject: Re[2]: Egregious coding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain The real key here is to put some of the pain of their sloppy work back on their backs. I've had this problem before as well with our CIM (Computer Integrated Manufacturing) group. The solution was simply to shrink the shared pool size by 50%. Yeah this sure put one heck of a strain on the db server, but it also slowed their transactions down a whole bunch and in some cases even returned error messages. Now they were shooting for no one transaction to take more that 2 seconds tops. You can imagine how they reacted when a simple insert took over 10 seconds! Sure they blamed the db at first, but a little info from OEM and a demo of a third party (Quest) product as well as the occasional error message and they were in a much different mood. Held a 2 hour class for them on using paramaterised SQL and they went and did a complete code re-write concentrating on where they created SQL statements. Sure I increased the shared pool size as well while they were not looking. They got the credit for getting the most intensive transaction down to .5 seconds and I got a lot less headaches. We've been good friends ever since. Dick Goulet ____________________Reply Separator____________________ Author: Greg Moore Date: 9/6/2001 5:00 PM Egregious coding> I would love to hold a > valid threat over their heads The key word is valid. Threatening to throw a switch and blow up any SQL that contains literals is a threat, but is it a valid threat? I mean, what was your previous job, suicide bomber? Seriously, providing accurate measurement of how much the extra parsing now costs, along with an evaluation of current CPU use and an estimate of how much longer they have before the system bottlenecks might be a touch more civilized. Egregious coding
>  I would love to hold a
>  valid threat over their heads
 
The key word is valid.  Threatening to throw a switch and blow up any SQL that contains literals is a threat, but is it a valid threat?
 
I mean, what was your previous job, suicide bomber?
 
Seriously, providing accurate measurement of how much the extra parsing now costs, along with an evaluation of current CPU use and an estimate of how much longer they have before the system bottlenecks might be a touch more civilized.
 
 

 

-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: dgoulet@vicr.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).