Inserts into pr_data_notification_recipient

General
, , ,
1

We are seeing millions of inserts happening into the table pr_data_notification_recipient since we have upgraded PEGA Robotics from 7 to 8.5. Below is the insert query which keeps on running. Any idea from where and why it is getting executed, and how it can be prevented?

INSERT INTO CIWPROD_DATA.pr_data_notification_recipient (pzInsKey , pxCommitDateTime , “PXAPPLICATION” , “PXCREATEDATETIME” , “PXCREATEOPERATOR” , “PXCREATEOPNAME” , “PXINSNAME” , “PXNOTIFICATIONID” , “PXOBJCLASS” , “PXRECIPIENTID” , “PXSAVEDATETIME” , “PXUPDATEDATETIME” , “PXUPDATEOPERATOR” , “PXUPDATEOPNAME” , “PYGUID” , “PYRULESETNAME” , “PYSTATUS”) VALUES (:1 , CURRENT_TIMESTAMP , :2 , :3 , :4 , :5 , :6 , :7 , :8 , :9 , :10 , :11 , :12 , :13 , :14 , :15 , :16 )

2

@AMARAN84

On analyzing the PEGA logs in splunk, we could see that the insert statement is happening from the activity ‘pzProcessNotification’. This gets called from the Queue processor ‘pyProcessNotification’, which calculates data such as the list of recipients, the message, or the channel including email, gadget notification, or Push notification. As far as I remember we do not do any notifications from our application to any of the stake holders and even if we are doing we do it through separate Email Notification step within the process.

image_comment_806336_1.png
image_comment_806336_1.png980×489 17.9 KB

Below is one sample log entry.

2021-03-10 22:43:25,675 GMT8PEGA000512055000ebbd0e21dde01172256492f4cd30101NANABMA95GDTKTEOYRRN2VEYHXOSQ5Z49G6SRASystemPegaSamplenullb894dab0237eeacbf21d2421619171f1N2870106EE5BC9F3CF7D817126B967AEFC06E7289DataFlow-Service-PickingupRun-pyProcessNotification:98, Access group: [PRPC:AsyncProcessor], PartitionsEQUALS[14]STANDARDcom.pega.pegarules.data.internal.store.DataStorePreparedStatementNANARule-Obj-Activity:pzProcessNotificationSYSTEM-QUEUE-NOTIFICATION PZPROCESSNOTIFICATION #20180713T133038.620 GMT Step: 11 Circum: 0NA*****pxRDBIOElapsed=0.79;pxDBOpExceedingThresholdCount=1;pxRDBIOCount=2;pxTotalReqCPU=8.53;pxRunModelCount=4;pxRunWhenCount=20,103;pxDeclarativePageLoadElapsed=0.30;pxRulesExecuted=40,255;pxTotalReqTime=27.10;pxActivityCount=13,441;pxAlertCount=3;pxOtherFromCacheCount=8;pxRunOtherRuleCount=1;pxDeclarativeRulesInvokedCount=6,695;pxInteractions=1;pxLegacyRuleAPIUsedCount=6;pxRuleCount=8;pxDeclarativeRulesInvokedElapsed=0.29;pxRuleIOElapsed=0.00;pxRulesUsed=40,282;pxDeclarativePageLoadCount=2;pxRuleFromCacheCount=8;pxOtherIOElapsed=1.78;pxCommitElapsed=20.40;pxTrackedPropertyChangesCount=7;pxDBOutputBytes=1,430;pxOtherIOCount=6,695;System-Queue-NotificationpyQueuePageSystem-Queue-NotificationpyQueuePage*Commit;RULE-OBJ-ACTIVITY SYSTEM-QUEUE-NOTIFICATION PZPROCESSNOTIFICATION #20180713T133038.620 GMT Step: 11 Circum: 0;doActivity Rule-Obj-Activity:pzProcessNotification;;initial Executable;0 additional frames in stack;*pzExecutionMetadata=page “” of class “System-Message-QueueProcessor”, 8/9 props expandedexpanded properties: -pyInitialInterval EQUALS “1” -pyIntervalFactor EQUALS “2.0” -pyIsDelayedProperty EQUALS “false” -pyMaxAttempts EQUALS “1” -pzAcquireLockAttempts EQUALS “0” -pzAtte+;NotificationRecipientsPage=RecipientsPage;pyForEachCount=6690;Database update took more than the threshold of 500 ms: 1,205 ms SQL: INSERT INTO CIWPROD_DATA.pr_data_notification_recipient (pzInsKey , pxCommitDateTime , “PXAPPLICATION” , “PXCREATEDATETIME” , “PXCREATEOPERATOR” , “PXCREATEOPNAME” , “PXINSNAME” , “PXNOTIFICATIONID” , “PXOBJCLASS” , “PXRECIPIENTID” , “PXSAVEDATETIME” , “PXUPDATEDATETIME” , “PXUPDATEOPERATOR” , “PXUPDATEOPNAME” , “PYGUID” , “PYRULESETNAME” , “PYSTATUS”) VALUES (? , CURRENT_TIMESTAMP , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ? , ?)

On further analysis, we were able to note that the agent activity ‘pzMonitorRobotCommandAndHeartbeat’ is the one which is queueing these many entries onto the queue table. Below is the chronology of the process.

  1. pzMonitorRobotCommandAndHeartbeat activity runs as part of agent, Pega-Robotic-AutomationPackageManagement, where it calls pzMonitorRobotHeartbeat in step 4.4.
  2. pzMonitorRobotHeartbeat call pyNotifyRecipients in step 12.
  3. pyNotifyRecipients calls pxNotify within which the object for System-Queue-Notification class is created and committed to the DB.

Though pzMonitorRobotCommandAndHeartbeat is not the only rule which calls pxNotify, it appears to be the major contributor to the record count. I am unable to open the report definition, pzGetCommandAndSvcOpDetailsForAllRobots, which retrieves the Command and Service Operation Details for all the BOTS to understand how the data is getting retrieved.