Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Extract String and StringBuffer Date: Thu, 24 May 2012 20:29:04 +0000 (UTC) Organization: UK Free Software Network Lines: 36 Message-ID: References: <34c76a08-4bdb-462b-9178-c8a24d9a5dba@googlegroups.com> <54c296d1-7913-45f0-b1f1-a602a0c34cbf@googlegroups.com> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1337891344 26440 84.45.235.129 (24 May 2012 20:29:04 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Thu, 24 May 2012 20:29:04 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: csiph.com comp.lang.java.programmer:14782 On Thu, 24 May 2012 03:21:46 -0700, mikew01 wrote: > The requirement is to pull out the sql statements and profile them using > the Oracle explain plan which will be executed by Sonar. > Has time I had to do that I was able to use ODBC tracing facilities to capture SQL statements as they were executed, but that was a while ago and I can't recall whether all ODBC implementations had that ability or was a capability of the particular driver I was using. Of course, using this approach does rather assume that you have a regression test that is known to exercise all SQL statements and/or there is somebody who knows enough about the system to be able to reliably run them all. If this is part of a DB tuning exercise you should be aware that you'll need to run the complete set of statements more than once, so it would be worthwhile to build a set of scripts that can can be used to (a) re- capture the set of scripts and (b) run them and record performance data for analysis. There's one other vital bit of information you need too - a use frequency for each SQL statement. If you don't have this information it would be well worth instrumenting your system to capture it. DB tuning is a really good example of a place where the 80/20 rule applies: unless a piece of SQL isn't in the top 20% of most frequently run statements there's little point in optimising the DB for it unless its something quite unusual, e.g. the CEO uses it once a day/week/month or it is run once a night, is tooth-achingly slow, accesses most of the DB and tends to run longer than the quiet period its meant to complete its task in. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |