You might try looking for an arexception.log file....if you are of a sufficient version and have it enabled, you might find information on how some of the calls are being generated and maybe even who.
On Mon, Mar 26, 2018 at 1:45 PM, Dinesh Kumar <[email protected]> wrote: > Hi LJ, > > We are not able to find that update statement in the logs, its getting > captured in the AR Error logs only. Not sure from where its getting > triggered . > > Thanks, > Dinesh kumar. > > On Mon, Mar 26, 2018 at 9:25 PM, LJ LongWing <[email protected]> > wrote: > >> Dinesh, >> Remedy does a 'BEGIN' at the beginning of an API call and does a 'COMMIT' >> at the end of an API call....you'll need to run some API/SQL logs on your >> server to help identify what processes are causing the blocking to occur at >> the DB level... >> >> Now, that could easily describe why #1 is occurring....but for #2, the db >> having blocking would not and should not cause the Remedy server to >> disconnect. That is being caused at the db level, possibly by killing a >> job causing the blocking, but it's not being caused on the Remedy side... >> >> On Mon, Mar 26, 2018 at 12:48 PM, Dinesh Kumar <[email protected]> wrote: >> >>> Hi LJ, >>> >>> DB team is saying this is boz of "TX - row lock contention". >>> "enq: TX - row lock contention" waits are generally related to the >>> application code being executed and do not indicate a problem with the DB >>> itself. >>> >>> The reason to this could be as the commit is still not issued , thus the >>> lock is still not released. Causing other queries to wait for the lock. >>> >>> >>> When they check the segments where most amount of waits are spent we >>> could see that table T2457 takes about 95% of the time >>> >>> Thus all update queries running on table T2457 need to be checked by the >>> application team >>> >>> TX lock is an application coding, design and usage problem and can ONLY >>> be fixed by changing application code with more frequent and explicit >>> COMMIT statements and any other minor code changes. DBA team cannot fix >>> TX lock wait issues other than helping to identify the objects and commands >>> causing the waits. >>> >>> >>> Thanks, >>> >>> Dinesh kumar. >>> >>> >>> >>> On Mon, Mar 26, 2018 at 8:03 PM, LJ LongWing <[email protected]> >>> wrote: >>> >>>> Well, for #1, you are issuing a query to the db that's not returning in >>>> the 120 second timeout....for #2 you are getting disconnected from the >>>> DB....both scenarios are pointing to a DB that is either overwhelmed, or >>>> under performing...I would highly recommend working with your DBA to figure >>>> out what's happening at the DB level first. >>>> >>>> On Mon, Mar 26, 2018 at 11:52 AM, Dinesh Kumar <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> We are facing below issue in our environment which causes a higher >>>>> impact and Business critical. >>>>> >>>>> >>>>> >>>>> SRM Fulfillment requests are not getting generated. >>>>> >>>>> >>>>> >>>>> The requests are getting struck in the *CAI Events* form in the >>>>> Running status for all the events (SRM_OUT_RESTART_SR_SUBMIT, >>>>> TMS_OUT_GET_DATA). >>>>> >>>>> We could see that PDT’s are also not getting connected to the Service >>>>> Requests. (adding screenshot). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> We are getting time out errors in the plugin and ARERR logs for the >>>>> certain requests. >>>>> >>>>> >>>>> >>>>> *Error-1:* >>>>> >>>>> >>>>> >>>>> 2018-02-14 09:12:55,772 ERROR [pool-2-thread-4] >>>>> com.bmc.itsm.cai.filterapi.cai.worker.BaseEventWorker >>>>> (BaseEventWorker.java:166) - CAI plugin failed to update error code of >>>>> event:TMHAA5V0GJ3KKAPEER8HBGHK64BVRP. Failed with following >>>>> exception. ERROR (94): Timeout during database query -- consider using >>>>> more >>>>> specific search criteria to narrow the results, and retry the operation; >>>>> ATVIEUUSMS006:2000 ONC/RPC call timed out >>>>> >>>>> >>>>> >>>>> *Error-2:* >>>>> >>>>> >>>>> >>>>> Wed Feb 14 09:24:49 2018 390627 : The SQL database operation failed. >>>>> (ARERR 552) >>>>> >>>>> Wed Feb 14 09:24:49 2018 ORA-03135: connection lost contact >>>>> >>>>> Process ID: 315236 >>>>> >>>>> Session ID: 411 Serial number: 60447 >>>>> >>>>> Wed Feb 14 09:24:49 2018 lastsql UPDATE T2457 SET >>>>> C112=';1000000018;',C5='Remedy Application Service',C6=1518531886 WHERE C1 >>>>> = 'PDT000000005704' >>>>> >>>>> Wed Feb 14 09:24:53 2018 390627 : SQL database is now available >>>>> (ARNOTE 592) >>>>> >>>>> SRM:ProcessDefinitionTemplate_Base(T2457) is getting locked and we >>>>> are not able to create any request fulfillment after that. Then we >>>>> need to manually release. >>>>> >>>>> >>>>> >>>>> Has one faced this kind of issues. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Dinesh kumar. >>>>> >>>>> -- >>>>> ARSList mailing list >>>>> [email protected] >>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>> >>>>> >>>> >>>> -- >>>> ARSList mailing list >>>> [email protected] >>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>> >>>> >>> >>> -- >>> ARSList mailing list >>> [email protected] >>> https://mailman.rrr.se/cgi/listinfo/arslist >>> >>> >> >> -- >> ARSList mailing list >> [email protected] >> https://mailman.rrr.se/cgi/listinfo/arslist >> >> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
