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

Reply via email to