IMPPROV_IOWAIT is recorded when a thread has issued an asynchronous read against a bulk load source file and is waiting for the read to complete. It belongs to BULK INSERT, OPENROWSET(BULK...), BCP, and similar import paths: the engine reads the source data file, and time spent waiting on those reads lands here.
It is effectively a latency meter for wherever your import files live.
Is It a Problem?
Only in proportion to how much bulk loading you do and how fast it needs to be. During a load window, this wait accumulating is expected; the question is whether the per-wait latency is reasonable for the storage serving the files. Source files on a network share or slow disk make the whole import crawl, and this wait is where that shows up.
If bulk loads meet their windows, ignore it. If loads are slow and IMPPROV_IOWAIT dominates their profile, the bottleneck is reading the source, not writing the table.
Common Causes
- Source files on network shares with high latency or limited bandwidth.
- Slow or busy local disks serving the import files.
- Very large single files read sequentially while the destination could absorb data faster.
- Antivirus or file-system filters inspecting the source file during reads.
What To Do
- Compare the wait’s average duration with the expected latency of the source storage; a share across a WAN will never feed a fast load.
- Move import files closer: local SSD on the SQL Server beats a share for hot load paths.
- Split giant source files and load in parallel streams where the table design allows.
- Check filter drivers (AV exclusions for the import directory) if local reads are mysteriously slow.
How To See It
Rank it against everything else with Get-WaitStatistics, and correlate with your load jobs; outside load windows it should be absent.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply