BACKUPIO

(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)

(Back to main page…)

Description:

This wait type is when a backup thread is waiting for a read or write of a buffer from/to a backup file to complete. The description below is very old and does not take into account network backups, which can cause this wait to have a long wait time.

(Books Online description: “Occurs when a backup task is waiting for data, or is waiting for a buffer in which to store data. This type is not typical, except when a task is waiting for a tape mount.”)

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:

Pre-2005/2005

Removed in SQL Server version:

N/A

Extended Events wait_type value:

The map_key value in sys.dm_xe_map_values is 135 in 2008 and 2008 R2, and 139 in 2012 and 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:

This wait type occurs for all backups, and can become prevalent when backing up to or restoring from a slow I/O subsystem (like a tape drive) or a backup file stored across a network. It’s essentially a measure of write/read latency to/from the backup file. When this wait type occurs during a BACKUP operation, it’s not uncommon to see BACKUPBUFFER waits also.

To troubleshoot this wait type, figure out which BACKUP operation is causing the long waits, and then investigate the I/O load on that portion of the I/O subsystem, or network latency, if applicable.

Known occurrences in SQL Server (list number matches call stack list):

1. Waiting for a read from a backup file to complete during a RESTORE operation (unknown what kind of restore, as this is a spawned worker thread, not the main thread)
2. Waiting for a write to complete during a BACKUP operation (unknown what kind of backup, as this is a spawned worker thread, not the main thread)
3. Waiting for a write to complete during a BACKUP LOG operation

And many other similar call stacks.

Abbreviated call stacks (list number matches known occurrences list):

1. SOS_Task::PostWait+90
   EventInternal<SuspendQueueSLock>::Wait+1f9
   BackupOperation::WaitForEvent+71
   MediaReadInterface::Wait+d8
   RestoreCopyMachine::CopyData+1c3
   BackupMedium::RestoreData+570
   BackupMedium::Restore+f42
   BackupStream::DoRestore+6e
   BackupStream::ThreadMainRoutine+207
   BackupThread::ThreadBase+51
   SubprocEntrypoint+a59
   SOS_Task::Param::Execute+21e
   SOS_Scheduler::RunTask+a8
2. SOS_Task::PostWait+90
   EventInternal<SuspendQueueSLock>::Wait+1f9
   BackupOperation::WaitForEventNoThrow+b1
   BackupIoRequest::WaitForCompletionInternal+c2
   BackupIoRequest::WaitForCompletion+e
   BackupOperation::CopyFileToBackupSet0+410
   BackupOperation::CopyFileToBackupSet+7d
   AsynchronousDiskAction::ExecuteDeferredAction+bf
   AsynchronousDiskWorker::ThreadRoutine+15c
   SubprocEntrypoint+a59
   SOS_Task::Param::Execute+21e
   SOS_Scheduler::RunTask+a8
3. SOS_Task::PostWait+90
   EventInternal<SuspendQueueSLock>::Wait+1f9
   BackupOperation::WaitForEvent+71
   BackupLogReader::MainThread+41
   BackupOperation::CopyLogToArchive+d4
   BackupOperation::PerformLogCopySteps+50
   BackupEntry::BackupLog+318
   CStmtDumpXact::XretExecute+ef
   CMsqlExecContext::ExecuteStmts<1,1>+400
   CMsqlExecContext::FExecute+a33
   CSQLSource::Execute+866
   process_request+73c
   process_commands+51c
   SOS_Task::Param::Execute+21e
   SOS_Scheduler::RunTask+a8