Problem
sp_StatUpdate_XE_Session.sql captures to an 8 MB ring buffer, which wraps long before a 5-hour maintenance window ends — the events you most want (from the start of the run) are gone by the time you look. It also leaves stale sessions behind, does not work on Azure SQL Database, and captures server-wide noise instead of scoping to sp_StatUpdate's own activity.
Fix
- event_file target (with rollover) instead of / alongside the ring buffer, read back via
fn_xe_file_target_read_file filtering on object_name and timestamp before casting to xml.
- Stale-session hygiene: sweep-and-drop prior sessions by name prefix on create; unique session-name suffix to avoid collisions.
- Azure SQL DB support:
ON DATABASE variant, with event existence probed via sys.dm_xe_objects before inclusion.
- Scoped predicates: filter on the
SU| CONTEXT_INFO prefix that sp_StatUpdate now stamps per session, so the trace captures only this tool's statements.
- Pre-build CREATE/START/STOP/DROP as a four-string lifecycle so any code path can clean up.
Pattern source: sp_HumanEvents session engineering (DarlingData).
Problem
sp_StatUpdate_XE_Session.sql captures to an 8 MB ring buffer, which wraps long before a 5-hour maintenance window ends — the events you most want (from the start of the run) are gone by the time you look. It also leaves stale sessions behind, does not work on Azure SQL Database, and captures server-wide noise instead of scoping to sp_StatUpdate's own activity.
Fix
fn_xe_file_target_read_filefiltering on object_name and timestamp before casting to xml.ON DATABASEvariant, with event existence probed viasys.dm_xe_objectsbefore inclusion.SU|CONTEXT_INFO prefix that sp_StatUpdate now stamps per session, so the trace captures only this tool's statements.Pattern source: sp_HumanEvents session engineering (DarlingData).