Dinesh, I've never been too much on the application side of things....a quick filter log should show you what workflow is pushing to that form which might give you a better idea of 'why' :)
On Mon, Mar 26, 2018 at 1:56 PM, Dinesh Kumar <[email protected]> wrote: > 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 <[email protected]> > 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 <[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 >> >> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
