Re: Tracing ALL sql queries - is it possible?

Except for shared memory and loopback connections. I think it's important to make that clear in your advertising when answering a question like this one. How do you know Michael isn't running a shared memory installation or using stream pipes? > Yes - with ZERO database server impact. Refer to www.sqlpower.com. > > Michael Ivanov wrote in message <3700F102.8C93B430@spb.sterling.ru>... > >Hi, does anybody know whether it is it possible to dump a trace of >ALL > sql queries, with timing info, >under Informix? > >Thanks a lot >-- > >Michael Ivanov. > Voice: +7 (812) 219-9237. E-mail: > ivans@spb.sterling.ru > >

Chuck Renaud wrote: > Except for shared memory and loopback connections. I think it's > important to make that clear in your advertising when answering a > 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. ":-( -- Michael Ivanov. Voice: +7 (812) 219-9237. E-mail: ivans@spb.sterling.ru

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. 2. No required operational changes to the database server, network or end-user workstations. 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: Except for shared memory and loopback connections. I think it's important to make that clear in your advertising when answering a 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. ":-( -- Michael Ivanov. Voice: +7 (812) 219-9237. E-mail: ivans@spb.sterling.ru