XE_FILE_TARGET_TVF is recorded while a thread performs operations for a query reading event data from an Extended Events file target via sys.fn_xe_file_target_read_file, the function behind most XE analysis queries, including reading system_health files. It is a preemptive wait, so the thread stays on the processor until the read operation completes.
Every time you (or a tool) query XE files, this wait meters it.
Is It a Problem?
No; it has not been a contention point, and its total is a diary of XE file reads: your troubleshooting sessions, scheduled jobs parsing system_health, monitoring products sweeping event files. Big values mean somebody reads a lot of event data, which is an activity, not a fault.
The practical note: parsing large XE files with the TVF (plus XML shredding) is genuinely CPU-heavy work. If scheduled XE analysis jobs weigh on the server, that cost shows in CPU and elapsed time; offloading analysis (copy files, parse elsewhere) is the standard relief.
Common Causes
- Ad hoc troubleshooting queries reading system_health and custom session files.
- Scheduled jobs or monitoring tools parsing XE files on the instance.
What To Do
- Filter it in routine analysis.
- For heavy recurring analysis, parse XE files off-box; the TVF works on copied files anywhere.
- Keep event sessions filtered so the files stay small enough to read cheaply.
How To See It
Rank waits with Get-WaitStatistics; its accumulation maps to whoever reads event files, including your own scripts.
Part of the SQL Server Wait Types Library.
Related deep dive: ASYNC_NETWORK_IO Wait Type.
Leave a Reply