Deadlock_Issue

Doesn't look like a deadlock.  Looks like a blocking lock.

You need to see what is on the remote system that is blocking your local transaction.

this is not a deadlock
it's a distributed transaction which has failed
you'll have an entry in dba_2pc_pending

in 99% of the cases, i need to cancel those
it's usually because of restarting 1 part of the systems in our shop

you'll have to either run a commit force or a rollback force
and then cleanup with purge_lost_db_entry

see here :https://docs.oracle.com/database/121/ADMIN/ds_txnman.htm#ADMIN12265

Thanks @sdstuber @Greet .

This issue is happening with production DB (the query is executed only once in a day) lock was occurred for a small time period, which i'm facing difficulty to trace the exact query at the time of failure .

So please suggest is there any way to find out the remote Query .

What kind of access do you have to the other Oracle database involved here?  This error indicates that some action in your production database involves a database link (that is: a connection to a separate database, called a "remote database").  This other database may actually be on the same host machine as your local, production database (where you see the error).  Or, the other database may be on a different server machine that is connected by either a LAN or WAN to your production database.

We have no idea what your local PL\SQL procedure does, nor what kind(s) of SQL calls it makes to the remote database, and we have no idea what kinds of SQL and/or PL\SQL activities are happening in the remote database, so we can't tell you exactly what you can do to try to avoid the distributed lock.  One suggestion would be to try this procedure at a time when the remote database is less busy.

Thanks @Mark

We have Read_only access to Oracle DB . But i'm exactly not found any DB link used in this Block .Please help me out on this .

FYI & A
--------------
DECLARE
FLAG_COUNT number;
UDC_ITM_LIV_FL_CNT number;

        BEGIN

        superuser.PG_IDRP_GLOBAL.p_log_msg('Updating table STSC.UDT_ITEM');

        UPDATE /*+ parallel(itm,8)*/ STSC.UDT_ITEM itm   ---- Transaction failing from this point when i tried to set my flag to '0'
        SET UDC_ITM_LIV_FL = 0,
        UDC_ITM_LIV_DT =TO_DATE('01-JAN-1970','DD-Mon-YYYY');

         superuser.PG_IDRP_GLOBAL.p_log_msg('Table STSC.UDT_ITEM updated for all ITEMS');
         COMMIT;

        MERGE /*+ parallel(ITM,8) */ INTO STSC.UDT_ITEM ITM
 USING (SELECT /*+ parallel(BKP,8)*/
                        DISTINCT SHC_ITM,MIN(GO_LIVE_DT) GO_LIVE_DT
                        FROM AAM.IDRP_CUTOVER@IDRPPAA0_RO BKP
                        WHERE TRUNC(BKP.GO_LIVE_DT)<=TRUNC(SYSDATE)
                        AND TRUNC(BKP.GO_LIVE_DT)<>TO_DATE('31-DEC-2199','DD-Mon-YYYY')
                        GROUP BY SHC_ITM
                        ) COVR
                    ON (ITM.ITEM =COVR.SHC_ITM
                       )
        WHEN MATCHED THEN
               UPDATE SET
                        ITM.UDC_ITM_LIV_FL =1,
                        ITM.UDC_ITM_LIV_DT=COVR.GO_LIVE_DT;

          FLAG_COUNT := SQL%ROWCOUNT;

        superuser.PG_IDRP_GLOBAL.p_log_msg('Number of records updated in table STSC.UDT_ITEM ITM for UDC_ITM_LIV_FL=1 are: '|| FLAG_COUNT);

        superuser.PG_IDRP_GLOBAL.p_log_msg('Table STSC.UDT_ITEM has been updated for ITEMS which have been cutover');

        COMMIT;

         SELECT /*+ parallel(ITM,8)*/ COUNT(*)
           INTO UDC_ITM_LIV_FL_CNT
          FROM STSC.UDT_ITEM ITM
          WHERE UDC_ITM_LIV_FL = 0;

         superuser.PG_IDRP_GLOBAL.p_log_msg('Number of records having UDC_ITM_LIV_FL=0 in table STSC.UDT_ITEM ITM are : '|| UDC_ITM_LIV_FL_CNT);

        END;
        /

you'll need the sys user to purge the entry

Thanks @Mark for your valuable suggestion

3) Developers try to Update the flag and live date for items in table STSC.UDT_ITEM which have been cut-over (for the fresh data load) .

~ As i have limited access to change the prod code .. Please suggest on which part i can remove for working it in a better way .