Discussion
Fideco
SG
Last activity: 8 Sep 2015 19:28 EDT
pr_sys_queue_sla Table
Hi All,
Regarding "pr_sys_queue_sla" table, does it have other use other than displaying the number of items that are currently on queue?
Can be viewed at prsysmgmt:
- Agent Management
- System Queue Management
Pega Version: 5.5
Thanks in advance!
Areteans Technology
IN
Whenever, the process reach an assignment which has an SLA defined on it, a record is created in pr_sys_queue_sla table which contains information of the assignment, sla goal,deadline etc.
Contains rows for instances of the System-Queue-ServiceLevel class, which support event-driven processing of service-level agreement deadlines and goals by the Pega-ProCom agent.
So, this table is the backbone for your SLA to work.
Fideco
SG
Thanks Ashok_Bommisetty!
Looking at the table on our side, we have the following:
Status Item Count Oldest Item Newest Item
Broken-Process 700,000 2011-07-31 2015-09-04
Scheduled 3,000,000 2012-07-31 2015-09-04
Since our application is slowing down to to the large amount of records, we are thinking about:
1. Deleting all the items with "Broken-Process" status.
2. Deleting all the items with "Scheduled" status, retaining only the records for the last 3 months.
Thanks Ashok_Bommisetty!
Looking at the table on our side, we have the following:
Status Item Count Oldest Item Newest Item
Broken-Process 700,000 2011-07-31 2015-09-04
Scheduled 3,000,000 2012-07-31 2015-09-04
Since our application is slowing down to to the large amount of records, we are thinking about:
1. Deleting all the items with "Broken-Process" status.
2. Deleting all the items with "Scheduled" status, retaining only the records for the last 3 months.
Will this have a negative effect to our system?
What could be the cause of having these large amount of records?
Thanks in advance!
Areteans Technology
IN
A record is marked as a broken process when it failed to do the respective task. 700k records is a pretty large number. I am assuming these records are there in the system may be from few years.
Now every record indicates the sla for a particular assignment. It is broken when it tries to do the sla and fails to do so which might happen due to lock failure, missing assignment, finishing assignment etc. Now if you are sure, you do not need these SLA actions on these tasks, they can be deleted.
These records are useful, if you want to retry the SLA activity on that particular task.Without this record, you cannot do the SLA action easily. So make a wise decission !!!
If I am you, I would see the age of the records and experiment with few of the latest records to see the failure reason.
Thanks,
Ashok
Fideco
SG
Thanks Ashok!
I tried to re-queue a "Broken-Process" status item.
What happenned is:
1. Current requeued item is deleted.
2. A new ID was created.
3. Searching the new ID, it is tagged as "Broken-Process".
Thanks Ashok!
I tried to re-queue a "Broken-Process" status item.
What happenned is:
1. Current requeued item is deleted.
2. A new ID was created.
3. Searching the new ID, it is tagged as "Broken-Process".
Viewing the XML of the item, I searched the work id in Pega.
I was able to open it and found no problem regarding the item.
Having that result, we are actually planning to delete all the "Broken-Process" records.
The main concern is the "Scheduled" items.
It is worth 3 million records having its oldest item dated 2012-07-31.
Will this have a negative effect to our system?
We are planning to create an activity that will check if the NODE defined in each item is the current one.
This is because the application was placed into different servers in the past.
Will retain the record if the NODE is applicable, else, delete the item.
Please take note that the NODE name is not exposed.
This is the reason why we need to open each item one by one.
Thanks in advance!
Fideco
SG
Upon clicking the radio button of the corresponding item, click the "View" button.
The following details will appear (the target property is underlined and the sample value is in bold letters):
| System-Queue-ServiceLevel | SYSTEM-QUEUE-SERVICELEVEL 1441349801147000A905D1FBD4512BD291C3B0858C2D914E | 20150904T145641.147 GMT+08:00 | 20150904T145641.147 GMT+08:00 |
Output for SystemQueueManagement / PerformAction / 1.0
<?xml version="1.0"?> <pagedata> <pxInsName>SYSTEM-QUEUE-SERVICELEVEL 1441349801147000A905D1FBD4512BD291C3B0858C2D914E</pxInsName> <pxUpdateSystemNode>SERVERNAMEINTHENETWORK</pxUpdateSystemNode> <pyAccessGroup>ABC:Developers</pyAccessGroup> <pyPriority>0</pyPriority> <pxUpdateAgentName>Pega-ProCom:ServiceLevelEvents</pxUpdateAgentName> <pyItemId>SYSTEM-QUEUE-SERVICELEVEL 1441349801147000A905D1FBD4512BD291C3B0858C2D914E</pyItemId> <pyItemStatus>Scheduled</pyItemStatus> <pyRetainOnSuccess>false</pyRetainOnSuccess>
UnitedHealth Group
US
We also face a similar problem in our application. Thousands of items stuck in this table for years.
Is it safe to run a delete script and directly delete the old items from this table ?