Active

As Microsoft® SQL Server™ executes the utility command, it will allocate or free buffers as necessary by accessing the single shared buffer pool. Whenever SQL Server needs to perform I/O against one of its data streams, it builds a command and sends it to the appropriate device. The command specifies the action to perform. When data transfer is involved, a shared buffer accessible in the client process is identified. The client loops, invoking IClientVirtualDevice::GetCommand to retrieve a sequence of commands. The client executes the command, and when it is complete, invokes IClientVirtualDevice::CompleteCommand to notify the server. This prompts the completion agent in SQL Server to call back to a SQL Server function associated with that command.

The virtual device is responsible for ensuring that the exact sequence of data written during BACKUP is retrieved during RESTORE. During RESTORE, the same BLOCKSIZE must be used as that used during the BACKUP. Generally, the same MAXTRANSFERSIZE should also be used. However, if the backup does not contain full-text data, then any MAXTRANSFERSIZE can be specified during the RESTORE. Regardless of these settings, the RESTORE command may request data to be read in any size between BLOCKSIZE and MAXTRANSFERSIZE (in multiples of BLOCKSIZE). There is no guarantee that the RESTORE command will request data in the same sequence of sizes as were used during the BACKUP.

If a client is using asynchronous I/O, it must ensure that a mechanism exists to complete outstanding requests when it is blocked in a IClientVirtualDevice::GetCommand call. Because GetCommand waits in an Alertable state, that use of Alertable I/O is one such technique. In this case, the operating system calls back to a completion routine set up by the client.