I would like the script as well
Stuart Schon Team Leader Fujitsu Australia Limited 2 Julius Avenue, North Ryde NSW 2113, Australia T +61 2 9113 9435 M +61 458 592 245 [email protected] <mailto:[email protected]> au.fujitsu.com <http://au.fujitsu.com> <file:///C:\DOCUMENTS%20AND%20SETTINGS\SCHONST\Application%20Data\Microsoft\Signatures\Fujitsu_files\fujitsuemailsignature.gif> From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Richard Copits Sent: Saturday, 20 November 2010 01:42 To: [email protected] Subject: Re: SQL Timing I would also like a copy of the Perl script. Thanks! From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Doug Blair Sent: Friday, November 19, 2010 8:47 AM To: [email protected] Subject: Re: SQL Timing ** Frank, Yes, we're all interested in your perl log parser! Please share/post/mail/attach it. Thanks! Doug (no, one of the other Dougs) Doug -- Doug Blair Sent from my iPhone4, typographic errors likely +1-224-558-5462 On Nov 19, 2010, at 6:21 AM, Frank Caruso <[email protected]> wrote: ** Thanks for all of the input. I created a PERL script to parse the API logs into separate files by threadid. I then walked each file and calculated the difference between the start and end of a transaction. From what I can tell it is accurate and I have been able to pull some very nasty end user SQL. If anybody is interested I will share the PERL script. On Tue, Nov 16, 2010 at 5:00 AM, Misi Mladoniczky <[email protected]> wrote: Hi, None of these are actually 100% sufficient. Some databases gives you an end-tag, but some do not. If you put FLTR/ESCL/API/SQL into the same file, you can track the thread and see when a call stopped by looking at the following row of the thread. Sometimes though, internal things in the ARServer takes time that is not possilbe to track... Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > Frank, > SQL Queries are correlated via TID (Thread ID). If you look for a > specific > query, and then look for the next instance of that thread ID the line > should > be 'OK'...the OK is the end of the SQL Query. If you are looking to > perform > general SQL timing, there are a number of tools on the BMCDN that will > parse > API/SQL logs and give you lots of good statistics. Contact me offline if > you need specifics. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Frank Caruso > Sent: Monday, November 15, 2010 11:38 AM > To: [email protected] > Subject: SQL Timing > > Haven't had to do this in a while and thought I understood the logic but > am > confused about how, from an SQL log, can you tell how long the query took? > I > can see the query start but I don't see anything indicating when it > finished. For an Update statement I see the commit. > > Frank > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ________________________________ Portions of this message may be confidential under an exemption to Ohio's public records law or under a legal privilege. If you have received this message in error or due to an unauthorized transmission or interception, please delete all copies from your system without disclosing, copying, or transmitting this message.
