We are in ARS 8.1 SP1 and SRM 8.1. Why we are updating the SRM:ProcessDefinitionTemplate_Base form for every service request creation ?
Thanks, Dinesh kumar. On Mon, Mar 26, 2018 at 9:48 PM, LJ LongWing <lj.longw...@gmail.com> wrote: > 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 <guru...@gmail.com> 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 <lj.longw...@gmail.com> >> 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 <guru...@gmail.com> >>> 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 <lj.longw...@gmail.com> >>>> 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 <guru...@gmail.com> >>>>> 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 >>>>>> ARSList@arslist.org >>>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>>> >>>>>> >>>>> >>>>> -- >>>>> ARSList mailing list >>>>> ARSList@arslist.org >>>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>>> >>>>> >>>> >>>> -- >>>> ARSList mailing list >>>> ARSList@arslist.org >>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>> >>>> >>> >>> -- >>> ARSList mailing list >>> ARSList@arslist.org >>> https://mailman.rrr.se/cgi/listinfo/arslist >>> >>> >> >> -- >> ARSList mailing list >> ARSList@arslist.org >> https://mailman.rrr.se/cgi/listinfo/arslist >> >> > > -- > ARSList mailing list > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
