Re: SRM Fulfillment creation issue

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 <gurudin@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.longwing@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 <gurudin@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