Hi Ben,
Yes you are right.
In some situations, you do not have the end-line in the SQL-logs.
You have to at least add API-logs as well, and FLTR-logs gives you lots of
extra timestamps. If you do this, you can come close to the reality in
most cases.
Why not upload a sample log with no more than 500 SQL-calls or 50
API-calls to the test-version of RRR|Log and see what it can do with it?
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* 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.
> I seem to recall that you may be right. It may be a new ARS feature
> (since
> 5x). I doubt that I have any 5.x logs around any more.
>
> In effect that means you cannot tell the duration of the SQL call. You
> can
> probably "come close" by using any next line in the log - but you have no
> idea how much time the intervening ARS server code took or even if there
> were any semaphore waits involved.
>
> Misi (bcc)? Am I right here?
>
> There's a bunch of better stuff you can do in Oracle but I am not an
> Oracle
> guy. Axton (bcc)?
>
> Cheers
> Ben
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of L G Robinson
> Sent: April 16, 2010 3:41 PM
> To: [email protected]
> Subject: Re: Interpreting ARS server SQL logs
>
> Hi Ben,
>
> Nope... I did not edit out any lines, just the actual text of the SQL
> Select
> statement.
> My logs don't seem to have any "OK's in them.
>
> Thanks.
> Larry
>
> On Apr 16, 2010, at 9:27 AM, Ben Chernys wrote:
>
>> For SQL logs ONLY (I presume you edited your sample log and left out
>> the
>> SQL OK)
>>
>> You should have had an OK immediately following every SQL Log entry
>>
>> Then, OK - SQL when they follow each other (and are the same thread id
>> of-course)
>>
>>
>> Cheers
>> Ben Chernys
>>
>> Senior Software Architect
>> Software Tool House Inc.
>>
>> Canada / Deutschland / Germany
>> Mobile: +49 171 380 2329 GMT + 1 + [ DST ]
>> Email: [email protected]
>> Web: www.softwaretoolhouse.com
>>
>> Check out Software Tool House's free Diary Editor.
>>
>> Meta-Update, our premium ARS Data tool, lets you automate your
>> imports, migrations, in no time at all, without programming, without
>> staging forms, without merge workflow.
>> http://www.softwaretoolhouse.com/
>>
>>
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:[email protected]] On Behalf Of L G Robinson
>> Sent: April 16, 2010 3:04 PM
>> To: [email protected]
>> Subject: Interpreting ARS server SQL logs
>>
>> Hi Folks,
>>
>> I have a question about interpreting ARS server SQL logs. I am in the
>> process of migrating from a Sybase database server to an Oracle server
>> and
> I
>> am trying to evaluate the performance of the Oracle server. I have
>> turned
> on
>> API and SQL logs and have them both written to a combined log file. When
>> I
>> complete a typical search using the Windows User tool, the following log
>> entries are written:
>>
>> 01 /* Wed Apr 14 2010 08:25:23.5164 */ +GLEWF ARGetListEntryWithFields
>> --
>> schema X-Calls
>> 02 /* Wed Apr 14 2010 08:25:23.5178 */ SELECT ...
>> 03 /* Wed Apr 14 2010 08:25:24.6918 */ COMMIT WORK
>> 04 /* Wed Apr 14 2010 08:25:24.8038 */ -GLEWF OK
>> 05 /* Wed Apr 14 2010 08:25:24.8097 */ +GLEWF ARGetListEntryWithFields
>> --
>> schema X-Calls
>> 06 /* Wed Apr 14 2010 08:25:24.8935 */ -GLEWF OK
>> 07 /* Wed Apr 14 2010 08:25:24.8992 */ +GLEWF ARGetListEntryWithFields
>> --
>> schema X-Calls
>> 08 /* Wed Apr 14 2010 08:25:24.9841 */ -GLEWF OK
>> 09 /* Wed Apr 14 2010 08:25:24.9896 */ +GLEWF ARGetListEntryWithFields
>> --
>> schema X-Calls
>> 10 /* Wed Apr 14 2010 08:25:25.0660 */ -GLEWF OK
>> 11 /* Wed Apr 14 2010 08:25:25.0716 */ +GLEWF ARGetListEntryWithFields
>> --
>> schema X-Calls
>> 12 /* Wed Apr 14 2010 08:25:25.1086 */ -GLEWF OK
>> 13 /* Wed Apr 14 2010 08:25:25.1146 */ +GLEWF ARGetListEntryWithFields
>> --
>> schema X-Calls
>> 14 /* Wed Apr 14 2010 08:25:25.1492 */ -GLEWF OK
>> 15 /* Wed Apr 14 2010 08:25:25.1545 */ +GLEWF ARGetListEntryWithFields
>> --
>> schema X-Calls
>> 16 /* Wed Apr 14 2010 08:25:25.1810 */ -GLEWF OK
>> 17 /* Wed Apr 14 2010 08:25:25.1864 */ +GLEWF ARGetListEntryWithFields
>> --
>> schema X-Calls
>> 18 /* Wed Apr 14 2010 08:25:25.1967 */ -GLEWF OK
>>
>> My questions is: Which times constitute the exact time that it took the
>> database server to complete the select?
>>
>> For this particular query, 825 rows were returned.
>>
>> I have numbered the lines so that we can say something like:
>>
>> line04-line02 = whatever...
>>
>> Config:
>>
>> ARS 5.01.02 patch 1313 / Solaris 8
>> Oracle 10.2.0.4
>>
>> Thanks.
>> Larry
>>
>> Larry Robinson [email protected]
>> Office of Information Technology
>> NC State University 919-515-5432 Voice
>> Raleigh, NC 27695-7109 919-513-0877 FAX
>>
>>
> ____________________________________________________________________________
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10
>> www.wwrug.com ARSlist: "Where the Answers Are"
>>
>>
> ____________________________________________________________________________
> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>
> ____________________________________________________________________________
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
