Two waits belong to the FileTable subsystem (the FFT prefix), and this page covers both: FFT_NSO_DB_LIST, a thread waiting for access to the list of databases the FileTable subsystem maintains, and FFT_RECOVERY, a thread waiting for FileTable recovery to run while a database starts up.
FileTables expose FILESTREAM data as a Windows file share, and the subsystem keeps its own bookkeeping across the databases that use them.
Are They a Problem?
No; neither has been a contention point. The database-list wait is registry housekeeping, and the recovery wait is a startup phase for FileTable-enabled databases, adding its slice to database recovery time in proportion to FileTable state that needs reconciling.
Instances without FileTables should see neither; their appearance is mostly an inventory fact that FileTables exist somewhere.
What To Do
- Filter both in routine analysis.
- If a FileTable-enabled database recovers slowly,
FFT_RECOVERYtime confirms the FileTable share of it; heavy FileTable estates pay this at every failover. - FileTable performance generally is FILESTREAM performance: the file I/O path, AV exclusions on containers, and share access patterns.
How To See It
Rank waits with Get-WaitStatistics; expect them only where FileTables are configured, and quietly even there.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply