Archiving-related UPDATEs on PR_METADATA keep running and locking the database even though all archiving jobs are disabled

Blueprint and App Design
, , ,
1

We suddenly started seeing archiving-related SQL statements hitting our database and causing heavy locking/contention. At the moment all archiving jobs are turned off (we disabled archiving-related Job Schedulers), but these queries keep coming and are locking our DB:

UPDATE PRPC8DATA.pr_metadata “DA” SET “PYARCHIVESTATUS” = :1 ,“PYCOMMENT” = :2 WHERE ( “DA”.“PYINSKEY” IN (:3 ) )
UPDATE PRPC8DATA.pr_metadata “DA” SET “PYARCHIVESTATUS” = :1 ,“PYCOMMENT” = :2 WHERE ( “DA”.“PYINSKEY” IN (:3 , :4 , :5 , :6 , :7 ) )
UPDATE PRPC8DATA.pr_metadata “DA” SET “PYARCHIVESTATUS” = :1 ,“PYCOMMENT” = :2 ,“PYFILELOCATION” = :3 ,“PYARCHIVEDATETIME” = SYSDATE,“PYSECONDARYSTORAGETYPE” = :4 ,“PYBATCHNAME” = :5 WHERE ( “DA”.“PYINSKEY” IN (:6 , :7 , :8 , :9 , :10 , :11 , :12 , :13 , :14 , :15 , :16 , :17 , :18 , :19 , :20 , :21 , :22 , :23 , :24 , :25 , :26 , :27 , :28 , :29 , :30 ) )

What can we do to stop them immediately to prevent DB locks?

2

These updates usually continue because another background process is still triggering archive status changes even if the visible Job Schedulers are disabled. The direct fix is to stop the archive queue processors, background processing nodes, or any active archiving requestors that are still running in the cluster, then clear the pending archive items that are already in process. After that, verify in Admin Studio that no archive-related queue processor or node type is enabled on any server. Once those background processors are fully stopped, the PR_METADATA updates will stop and the database locks will be removed. This works because the SQL is coming from active archive processing, not from the disabled scheduler rule alone.