Hi,
If you add API/FLTR/ESCL to the log as well, you will get more
time-stamped markers.
Also look at the RPC ID which uniquely identifies each API-call.
Each thread fires seqencially, but you may get calls from different
threads intermixed.
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.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at http://rrr.se.
> Typically I consider the 'ok' to be the finish of the statement before
> it....but are these both on separate threads, or are you dealing with a
> delay you are trying to figure out?
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Wheeler, Dylan
> Sent: Wednesday, November 05, 2008 6:00 PM
> To: [email protected]
> Subject: SQL Log question
>
> I'm wondering how I should read this sql log. Can someone help me out?
>
> /* Wed Nov 05 2008 15:01:47.4860 */SELECT
> helpText,changeDiary,objProp,owner,lastChanged FROM arschema WHERE
> (schemaId
> = 973)
> /* Wed Nov 05 2008 15:01:47.4860 */OK
>
> /* Wed Nov 05 2008 15:01:56.6300 */SELECT name, actlinkId, alOrder,
> executeMask, controlfieldId FROM actlink WHERE actlinkId
> IN(3556,3557,3558,3559,3560,3561,3562,3563,3941,3942,3943,3944,3945,3957,395
> 8,3959,3960,3961,3962,3963,3964,3965,3966,3967,3968,3969,3970,3971,3972,3973
> ,3974,3975,3977,3979,3980,3981,3982,3984,7880,7891,7893,7894,7952,7953,7954,
> 7955,7956,7957,7958,7959,7960,7961,7962,7963,7964,7965,7966,7967,7968,7987,7
> 988,7989,7990,7991,7992,7993,7994,8795,8796,10696,10697,10698,11145,11146,11
> 147,11148,11149,11150,11151,11152,11153,11154,11155,11156,11157,11158,11159,
> 11160,11161,11162,11163,11164,11165,11166,11167,11168,11169,11170,11171,1117
> 2,11173,11174,11175,11176,11177,11178,11179,11180,11181,11182,11183,11184,11
> 185,11186,11187,11188,11189,11190,11191,11192,11193,11194,11195,11196,11197,
> 11198,11199,11200,11201,11202,11203,11204,11205,11206,11207,11208,11209,1121
> 0,11211,11212,11213,11214,11215,11216,11217,11218,11219,11220,11221,11222,11
> 223,11224,11225,11226,11227,11228,11229,11230,11231,11232,11233,11234,11235,
> 11236,11237,11238,11239,11240,11241,11242,11243,11244,11245,11246,11247,1124
> 8,11249,11250,11251,11252,11253,11254,11255,11256,11257,11258,11259,11260,11
> 261,11262,11263,11264,11265,11266,11267,11268,11269,11270,11271,11272)
> ORDER
> BY 2 ASC
> /* Wed Nov 05 2008 15:01:56.7090 */OK
>
> There is a 8 second gap between the first query and the second.
>
> So my question is, does the OK line represent Remedy saying that it's
> ready
> to send the query off to SQL or does it represent that Remedy received the
> response from SQL and to move on to the next instruction.
>
> I'm trying to figure out why some operations are running really slow and
> the
> dba is asking me what the OK represents.
>
> Thanks for any help
>
> Dylan
>
> ____________________________________________________________________________
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
> Sponsor:
> www.rmsportal.com ARSlist: "Where the Answers Are"
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.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
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
