One tester reported a brutal load on "tempdb" - the Job "SSI: Block Recording" ran for more than an hour (?) and dramatically increased the size of the "tempdb" (??) ...
Not sure what happened here, since the stuff is just recoding to its own table, by default in "msdb" ...
My current guess is:
Technically lots of micro-blocks happen which possibly also trigger that Alert, thus it might be (now: have been?) somewhat "hyper-nervous" and recording all this nonsense ...
The affected server (above) runs around 30 (40?) databases with 200+ Users, so system-wide probably a load of that nonsense-stuff (e.g. parallel thread waits etc.) existed ...
I added a @min_wait threshold to the recording, by default 1 second.
Thus, only if a block exists which takes longer than this @min_wait then the recording starts.
(please re-install the Job and the Alert with the new scrips)
We are still investigating this - so just be warned!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One tester reported a brutal load on "tempdb" - the Job "SSI: Block Recording" ran for more than an hour (?) and dramatically increased the size of the "tempdb" (??) ...
Not sure what happened here, since the stuff is just recoding to its own table, by default in "msdb" ...
My current guess is:
Technically lots of micro-blocks happen which possibly also trigger that Alert, thus it might be (now: have been?) somewhat "hyper-nervous" and recording all this nonsense ...
The affected server (above) runs around 30 (40?) databases with 200+ Users, so system-wide probably a load of that nonsense-stuff (e.g. parallel thread waits etc.) existed ...
I added a @min_wait threshold to the recording, by default 1 second.
Thus, only if a block exists which takes longer than this @min_wait then the recording starts.
(please re-install the Job and the Alert with the new scrips)
We are still investigating this - so just be warned!
BTW: You could monitor the tempdb-size with such an Alert, for example: