Not sure - in all honesty I don't even know why this query takes different times in either case. The "Where" clause is the same. I can see it taking slightly more time to grab the additional information but it's actually behaving like it does a table scan in one instance and an indexed query in the other. In reality the where clause uses an "OR" so it should be a table scan either way but I suspect the Oracle optimization rules are kicking in somewhere.
________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Darrell Reading Sent: Monday, July 07, 2008 3:06 PM To: arslist@ARSLIST.ORG Subject: Re: WUT GLE vs MT GLEWF in Modify People ** Could it be that the data contained in any blobs are being pulled over with the web query so that the tool would have a similar feel as the native client when opening a log field? Darrell Reading Systems Engineer Phone 479.204.5739 [EMAIL PROTECTED] Wal-Mart Stores, Inc. 805 Moberly Lane, MS-0560-68 Bentonville, AR 72716 Save Money. Live Better ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing Sent: Monday, July 07, 2008 14:58 To: arslist@ARSLIST.ORG Subject: Re: WUT GLE vs MT GLEWF in Modify People ** My first thought was that the mid-tier does a with fields in order to reduce the subsequent calls to the DB...but looking at the call that mid-tier is using...it's doing quite a bit more than that...it appears to be pulling currency fields, doing an outer join on the B table....does the subsequent sql call from both the client and the web look the same as the initial from the web? ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow Sent: Monday, July 07, 2008 1:27 PM To: arslist@ARSLIST.ORG Subject: WUT GLE vs MT GLEWF in Modify People ** In IM 7.03 patch 7 we have users who are experiencing slow-downs when accessing some base product functionality. The two scenarios are: Windows User Tool: The user opens an existing Incident and presses the "Modify" button on the customer tab to bring up the Customer Record. The screen opens quickly and displays the customer record. API/SQL logging indicates a +/- GLE is being issued which completes very quickly. A further action later on retries the actual values for the record to display. Mid-tier (solaris + IBM HTTP Server + Websphere) standalone - 7.1 patch 001 The user opens an existing Incident and presses the "Modify" button on the customer tab to bring up the Customer Record. The screen opens immediately to the "Loading" screen takes 45 seconds or so to display the customer record. API/SQL logging indicates a +/- GLEWF is being issued which completes very slowly. A further action later on retries the actual values for the record to display. This goes quickly as in the first case. Why on earth would the same workflow cause a GLE in the WUT and GLEWF in the mid-tier? It's the exact same workflow that is firing - there is no custom anything based on the client type. Also - the SQL commands that are issued by these GLE/GLEWF sequences is wildly different. GLE SQL: SELECT T659.C1,C1000000018,C1000000019,C1000000056,C1000000001,C1000000010,C200 000006,C200000012,C260000001,C7 FROM T659 WHERE ((T659.C1 = 'PPL000000923440') OR (T659.C4 = ' ')) ORDER BY 2 ASC,3 ASC, 1 ASC GLEWF SQL: SELECT T659.C1,C1000000188,C1000000027,C1000000031,C1000000035,C1000000673,C100 0000029,C1000000123,C1000000056,C108,C300469200,C1000000125,C1000000025, TO_CHAR(C301277100,'FM99999999999999999999999990.009'),C1000000023,C3012 77200,C260000001,C1000000052,C1000000906,C1000000050,C1000000121,C200000 012,C1000000010,C301336500,C1000000039,C1000000060,C123,C1000000119,C100 0000048,C1000000946,C3,C1000000846,C7,C1000000346,C1000000002,C100000094 8,C1000000062,C1000000004,C5,C112,C1000000042,TO_CHAR(C240000040V,'FM999 999999999999990.00000000009'),C240000040C,C240000040D,TO_CHAR(C240000040 USD,'FM999999999999999990.00000000009'),TO_CHAR(C240000040EUR,'FM9999999 99999999990.00000000009'),TO_CHAR(C240000040GBP,'FM999999999999999990.00 000000009'),TO_CHAR(C240000040JPY,'FM999999999999999990.00000000009'),C3 01349200,C1000000054,C1000000127,C302006500,C1000000654,C200000006,C1000 000018,C1000000952,C1000000044,C1000000020,C110,C1000000046,C300495800,C 160,C1000000026,C1000000049,C1000000122,C260141102,C1000000028,C10000000 34,C1000000036,C1000000126,C1000000541,C1000000032,C1000000674,C10000001 24,C1000000030,C1000000053,C301554200,C300469300,C600200100,C1000000949, C1000000024,TO_CHAR(C301554100,'FM99999999999999999999999990.009'),C1000 000926,TO_CHAR(C301554000,'FM99999999999999999999999990.009'),C240000042 ,C301600300,C1000000051,C1000000022,TO_CHAR(C301321200,'FM99999999999999 999999999990.009'),C1000000001,C1000000040,C179,C1000000074,C230000009,C 1000000069,C1000003975,C2,C1000000047,C1000000061,C1000000017,C100000004 5,C301553900,C6,C1000000947,C4,C260000006,C1000000059,CO1000003962||';'| |CC1000003962||';'||C1000003962,C302006600,C1000000003,C200000007,C10000 00021,C1000000041,C1000000128,C1000002476,C1000000033,C8,C1000001262,C10 00000043,C1000000120,C1000000037,C1000000019,C109 FROM T659 LEFT OUTER JOIN B659 ON (T659.C1 = B659.C1) WHERE ((T659.C1 = 'PPL000000923440') OR (T659.C4 = ' ')) ORDER BY 55 ASC,122 ASC, 1 ASC ) WHERE ROWNUM <= 2 William Rentfrow, Principal Consultant [EMAIL PROTECTED] C 701-306-6157 O 952-432-0227 __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ________________________________ ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error destroy it immediately. ********************************************************************** Wal-Mart Confidential ********************************************************************** __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
