Optimize TSQL outbox cleanup by reducing batch size and adding rowlock hint

[ramonsmits]

Resolves:

• Deadlocks/timeouts occur on SQL outbox table cleanup if it is under high load #778

Optimize TSQL outbox cleanup by

1. Reducing batch size to prevent lock escalation to page/table locks
2. Add hint to prevent escalation from row to page locks to not conflict with regular incoming message outbox operations as DELETE does not have to be efficient and should avoid any lock escalation over performance

To prevent lock escalation to page/table locks the number of rows must not be over 4.000 or 5.000 rows

Google states multiple resources that either going over 4.000 or 5.000 rows results into lock escalation from row to page/table locks:

• https://dba.stackexchange.com/questions/284675/delete-rows-older-than-x-days-without-locking-table
• https://www.sqlservercentral.com/forums/topic/row-locks-not-escalating-to-table-locks-after-5000
• https://www.sqlpassion.at/archive/2016/05/09/lock-escalations-do-they-always-happen/

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[udidahan]

Given the approval, it seems like this was validated as having some benefit, so why was it not followed through on?

[ramonsmits]

Given the approval, it seems like this was validated as having some benefit, so why was it not followed through on?

No specific reason except this didn't show up in the github notifications and due to your comment it did.

[udidahan]

I would have thought that the ping from the bot would have triggered the same notification, but ok.