Skip to content

Blocking/deadlock XML processors truncate parsed data every run #23

@erikdarlingdata

Description

@erikdarlingdata

Bug

Both collect.process_blocked_process_xml and collect.process_deadlock_xml TRUNCATE their respective parsed output tables (blocking_BlockedProcessReport and deadlocks) on every scheduled run, then re-parse all raw XML from scratch.

The scheduler calls both processors with no @start_date/@end_date, which hits the TRUNCATE path at line 143 in both procedures. The date-range code path that would preserve parsed data exists but is never used.

Impact

  • Parsed blocking/deadlock data is wiped and rebuilt every 5-10 minutes
  • As raw XML ages out of 30-day retention, the corresponding parsed data is permanently lost on the next re-parse cycle
  • Wasted CPU re-parsing identical XML every cycle (currently 61 raw rows re-parsed every run)
  • The parsed table can never contain events older than what's currently in the raw XML table

Fix

Add an is_processed flag to the raw XML tables (collect.blocked_process_xml and collect.deadlock_xml). Processors will:

  1. Only count/process rows where is_processed = 0
  2. Derive @start_date/@end_date from unprocessed rows (using the existing date-range code path)
  3. Mark rows as is_processed = 1 after successful parsing

This allows parsed data to accumulate over time and eliminates redundant re-parsing.

Also fixes a Lite bug: blocked_process_reports is missing from ArchiveService.cs archival list, causing blocking data to accumulate indefinitely.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions