Re: Tracing ALL sql queries - is it possible?
Posted in 1999
Obnoxio The Clown, Your statement of the capabilities of the Sql Power SniFFFer product line is not quite correct regarding shared memory connections or IPC connections to an Informix database server. Please refer to the response that will be posted this morning to the Informix Newsgroup thread 'Subject: Re: Tracing ALL sql queries - is it possible?'. Mary Owens Sql Power Tools 201.825.9511 -----Original Message----- From: Obnoxio The Clown <obnoxio@hotmail.com> To: rreiter@sqlpower.com <rreiter@sqlpower.com> Date: Thursday, April 01, 1999 3:19 AM Subject: Re: Tracing ALL sql queries - is it possible? >Listen, I think we've all got the point. Could you please post soemthing >other than your bloody advertisement now? Your software won't help >people who use IPC connections. Like the guy you just sent the same >thing to, twice! And the rest of the newsgroup! LISTEN TO THE QUESTION, >IDIOT!!! > > >>From: "Randy Reiter" <rreiter@sqlpower.com> >>Reply-To: "Randy Reiter" <rreiter@sqlpower.com> >>To: informix-list@iiug.org >>Subject: Re: Tracing ALL sql queries - is it possible? >>Date: Wed, 31 Mar 1999 12:50:35 -0500 >>From owner-informix-list@iiug.org Wed Mar 31 10:50:15 1999 >>Received: from [206.175.175.254] by hotmail.com (1.5) with SMTP id >MHotMailB8CBB940018ED1B98330CEAFAFFE84540; Wed Mar 31 10:50:15 1999 >>Received: (from majordom@localhost) by iiug.iiug.org (8.7.5/8.7.3) id >MAA22956; Wed, 31 Mar 1999 12:40:08 -0600 (CST) >>Organization: Sql Power Tools >>Message-Id: <7dtngp$b53$1@mtinsc02.worldnet.att.net> >>X-List-Gateway: comp.databases.informix >>Sender: owner-informix-list@iiug.org >>Precedence: bulk >> >>This is a multi-part message in MIME format. >> >>------=_NextPart_000_001D_01BE7B75.11EBAAC0 >>Content-Type: text/plain; >> charset="koi8-r" >>Content-Transfer-Encoding: quoted-printable >> >>The Sql Power SniFFFer will monitor all stored procedure executions >(all = >>SQL commands or statements actually) sent over the network to an = >>Informix database server (IDS). >> >>The stored procedure execution with transmitted SQL execution text, = >>parameters, database server response time, end-user response time, rows >= >>returned, network send time, network receive time, any errors, login id >= >>and more will be captured, monitored and archived by the Sql Power = >>SniFFFer. One can easily obtain the performance of all or any subset = >>stored procedure (any SQL actually) executions in real-time or off-line >= >>from an archive. Any subset off the SQL transations sent over the = >>network can be filtered and analyzed from the archive for SQL = >>transaction performance analysis or database server service level = >>statistics. >> >>With: >> 1. ZERO required performance impact upon the Informix database server, >= >>network or end-users. =20 >> 2. No required operational changes to the database server, network or >= >>end-user workstations. =20 >> 3. No required software installation on the database server, network >or = >>end-user workstations. >> 4. No required connectivity to an Informix database server or end-user >= >>workstations. >> 5. No intrusive database server agents, audits, traces, probes, = >>monitors, end-user workstation agents, proxy servers or middleware. >> this may be accomplished. >> >>Quite powerful for the following reasons: >> >>1. ZERO impact, 7x24 database server performance monitoring at the SQL >= >>transaction level. >> >>2. Long running stored procedure (any SQL command actually) executions >= >>are immediately identified. Allows one to focus your performance = >>efforts on poor performing SQL transactions on a systematic, proactive >= >>basis where the ROI of the time you spend on performance tuning is = >>maximized. e.g. The SQL or stored procedures most frequently having = >>either long or an irregular distribution of run times. Or, the SQL = >>statements with the worst performance when referencing a specific set >of = >>database tables or columns. >> >>3. Stored procedure querying database tables with skewed distribution = >>statistics may have inconsistent end-user response times. Some fast = >>others slow. These can be easily identified for development, test or = >>production (1000+ transactions/second) database servers. They also = >>typically can cause performance headaches for DBAs or developers. = >>Typical scenario is 'it worked great in my test', however in a = >>production mode exhibits different performance due to stored procedure >= >>parameters or where clause selection criteria referencing different >data = >>rows. >> >>4. ZERO impact database server Service Level Statistics can be easily = >>obtained 7x24. e.g. the database server transaction processing rate, = >>average database server response time, average end-user response time, >= >>average rows returned, average network send time and receive time and = >>more are available on a time interval basis (2 sec, 2 min, etc.). = >>Available in real-time or off-line from an archive. When a service = >>level interval is found with unaccepatble performance, the SQL = >>transactions can be easily reconstructed. >> >>Note: The SQL text of the stored procedure execution will not be = >>captured for a stored procedure execution since only the stored = >>procedure name with parameters is transmitted over the network. The = >>stored procedure text will only be captured by the Sql Power SniFFFer = >>when the procedure is compiled during development or when a 3rd party = >>product's procedures are compiled to the database server. >> >>Randy Reiter >>201.825.9511 >>www.sqlpower.com >> >> >> >> Michael Ivanov wrote in message = >><3701B003.36A3C4CA@spb.sterling.ru>... >> Chuck Renaud wrote:=20 >> Except for shared memory and loopback connections. I think >it's = >> >> important to make that clear in your advertising when answering >= >>a=20 >> question like this one. How do you know Michael isn't running >a = >> >> shared memory installation or using stream pipes? >> Yes, and it's true - I'm interested mostly in sql code, generated >by = >> >> stored procedures. So network sniffing wouldn't help I guess. >":-(=20 >>-- >>Michael Ivanov. >> Voice: +7 (812) 219-9237. E-mail: ivans@spb.sterling.ru >> =20 >> >>------=_NextPart_000_001D_01BE7B75.11EBAAC0 >>Content-Type: text/html; >> charset="koi8-r" >>Content-Transfer-Encoding: quoted-printable >> >><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> >><HTML> >><HEAD> >> >><META content=3Dtext/html;charset=3Dkoi8-r = >>http-equiv=3DContent-Type><!doctype html public "-//w3c//dtd html 4.0 = >>transitional//en"> >><META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> >></HEAD> >><BODY bgColor=3D#ffffff> >><DIV><FONT color=3D#000000 size=3D2>The Sql Power SniFFFer will monitor >= >>all stored=20 >>procedure executions (all SQL commands or statements actually) sent >over = >>the=20@