(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)
Description:
This wait type is when a thread is calling the Windows FlushFileBuffers function.
(Books Online description: N/A)
Questions/comments on this wait type? Click here to send Paul an email, especially if you have any information to add to this topic.
Added in SQL Server version:
2008
Removed in SQL Server version:
N/A
Extended Events wait_type value:
The map_key value in sys.dm_xe_map_values is 451 in 2008 and 2008 R2, 499 in 2012, and 515 in 2014 RTM. After 2014 RTM, you must check the DMV to get the latest value as some map_key values have changed in later builds.
Other information:
When SQL Server is running on Linux, and from SQL Server 2017 CU6 onward, this wait type may be the most prevalent on your system. This is because SQL Server on Linux will forcibly flush log blocks and data pages to disk to avoid any possibility of data loss. If the I/O subsystem guarantees write durability, this behavior can be disabled using trace flag 3979. See this KB article for more details, and a much deeper explanation of SQL Server on Linux I/O here.
This wait type is one that I usually filter out.
Note that when a thread calls out to Windows, the thread changes from non-preemptive (SQL Server controls the thread) to preemptive (Windows controls the thread) mode. The thread’s state will be listed as RUNNING, as SQL Server doesn’t know what Windows is doing with the thread.
Known occurrences in SQL Server (list number matches call stack list):
- Flush all in-memory buffers for a file to disk (in this case, making sure all of a backup file is durably stored when finished a BACKUP operation)
- Flush all in-memory buffers for a file to disk (in this case, as part of running a DBCC WRITEPAGE command that bypasses the buffer pool)
- Flush all in-memory buffers for a file to disk (in this case, as part of shutting down a database that has the AUTO_CLOSE option set)
- Flush all in-memory buffers for a file to disk (in this case, as part of writing out a checkpoint file during a RESTORE operation)
And other similar call stacks.
Abbreviated call stacks (list number matches known occurrences list):
- SOS_Task::PopWait+b1
AutoSwitchPreemptive::~AutoSwitchPreemptive+95
DBFlushFileBuffers+b9
BackupDiskFile::RequestDurableMedia+d5
BackupFile::Close+92
BackupMediaIo::Close+1b7
BackupStream::DoClose+48
BackupStream::ThreadMainRoutine+153
BackupThread::ThreadBase+51
SubprocEntrypoint+a7f
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+ab - SOS_Task::PopWait+b1
AutoSwitchPreemptive::~AutoSwitchPreemptive+95
FCB::FlushFileBuffersByHandle+190
FCB::EnsureBuffersFlushedForClose+60
FCB::Close+2c7
DbccWritePage+d24
DbccCommand::Execute+153
CStmtDbcc::XretExecute+7cd
CMsqlExecContext::ExecuteStmts<1,1>+427
CMsqlExecContext::FExecute+a43
CSQLSource::Execute+86c
process_request+a57
process_commands+4a3
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+ab - SOS_Task::PopWait+b1
AutoSwitchPreemptive::~AutoSwitchPreemptive+95
FCB::FlushFileBuffersByHandle+190
FCB::EnsureBuffersFlushedForClose+60
FCB::Close+2c7
FileMgr::Shutdown+52
RecoveryUnit::Shutdown+283
DBTABLE::Shutdown+2e9
DBMgr::ShutdownDB+208
DBMgr::CleanShutdownDB+51c
TaskDatabaseAutoClose::ProcessTskPkt+386
OnDemandTaskContext::ProcessTskPkt+3e2
SystemTaskEntryPoint+426
OnDemandTaskContext::FuncEntryPoint+25
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+ab - SOS_Task::PopWait+b1
AutoSwitchPreemptive::~AutoSwitchPreemptive+95
FCB::FlushFileBuffersByHandle+190
CheckpointableOperation::Save+23d
BackupOperation::SaveCheckpoint+1e2
BackupStream::ThreadMainRoutine+207
BackupThread::ThreadBase+51
SubprocEntrypoint+a7f
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+ab