Version store backup monitor

[petervandivier]

Sessions can fill up tempdb version store long before they're subject to a length-of-execution timeout. Add config options & logic to profile version store and begin to warn/kill sessions when version store is under growth pressure.

[taddison]

How would you imagine this working? Some of the challenges I remember from prior attempts at this (because it's a great idea!) are:

• Versioned records can be owned by multiple requests
• The DMVs that expose the version store are expensive to query (increases in cost in proportion with the size of the store)

I'm guessing this is mostly related to queries on a secondary replica, which would mean length of time of the transaction is going to correlate well with being the most likely candidate to have pinned the version store. If this is the typical runbook when manually troubleshooting (version store is big! hey that transaction is long running! kill.), maybe this scenario (version store large) gets Ed209 a little more aggressive with the durations it considers kill-worthy?

I don't know if life is any better with PVS (at least it's easier to know which database is the problem!)