Backups of large databases fails with similar errors:
21/01/2009 19:00:16: DiskFile:: FALSE = WriteFile(0x1FD4,, 6656, 0, {0x1FD4, 997, 0, 6656, 6656, 0x00012200 0x00000000X})
21/01/2009 19:00:16: flush page detected (page header) so FlushData
21/01/2009 19:00:16: thread = 1 file index = 1
21/01/2009 19:00:16: DiskFile:: FALSE = WriteFile(0x1DEC,, 6144, 0, {0x1DEC, 997, 0, 6144, 6144, 0x00012A00 0x00000000X})
21/01/2009 19:00:16: DiskFile:: TRUE = GetOverlappedResult(0x1FD4, {0x1FD4, 997, 6656, 0, 6656, 0x00012200 0x00000000}, 6656)
21/01/2009 19:00:16: DiskFile:: TRUE = WriteFile(0x1DDC,, 29696, 29696, {0x1DDC, 0, 29696, 0, 29696, 0x00010000 0x00000000X})
-----------
21/01/2009 20:28:54: DiskFile:: FALSE = WriteFile(0x1FD4,, 1052160, 0, {0x1FD4, 112, 0, 1052160, 1052160, 0x088EF200 0x00000004X})
21/01/2009 20:28:54: DiskFile:: FALSE = WriteFile(0x1FD4,, 1052160, 0, {0x1FD4, 112, 0, 1052160, 1052160, 0x088EF200 0x00000004X})
21/01/2009 20:28:54: VDI -> Error: 10900, Msg: Error saving data to file. Thread: 0
21/01/2009 20:28:54: VDI::TransferData -> Error: 1, Msg: user exception
Between these errors the following may be displayed at different time intervals;
21/01/2009 20:28:16: Try ExtendFile by 2146435072
21/01/2009 NN:NN:NN: Try ExtendFile by 1073217536
21/01/2009 NN:NN:NN: Try ExtendFile by 536608768
21/01/2009 NN:NN:NN: Try ExtendFile by 268304384
21/01/2009 NN:NN:NN: Try ExtendFile by 134152192
Changing Litespeed backup settings max transfer size, encryption, compression doesnt help and there is adequatediskspace.
This may occur depending on how Litespeed extends the backup files. Litespeed initially tries to extend the file by 2146435072. If it fails, it drops it to half that amount. It will continue to drop it by half its amount and if it keeps failing, it will eventually fail completely with the 112 out of space error.
When the backup starts, LiteSpeed reads all of the available drive space and proceeds with file extension enabled. Litespeed does this in order to improve the speed of the backup because then overlapped IO kicks in. This causes the size of the backup file to increase until the end of the backup process, at which time the working space is freed and removed from the backup file.
Error 997 and error 112 are false errors.
Script your Litespeed backup job and add the @ioflag.
EX: @ioflag=OVERLAPPED, @ioflag=SEQUENTIAL_SCAN, @ioflag=NO_BUFFERING, @ioflag=FILE_EXTENSION=-1
Add the parameter is missing in the backup script. This will slow the task and will remove the extending of the backup file.
Additional Information:
Additional information aboutIOFlags
@ioflag=FILE_EXTENSION=<<size>> will set (or disable) the amount in bytes that SQLLiteSpeed incrementally pre-allocates a local disk backup file during a backup. This pre-allocation does not occur for backups to non-local disks. Pre-allocation of local backup files is important for performance reasons. If this parameter is not passed in for a local backup then SQLLiteSpeed computes an optimal value, not to exceed 2GB. Pre-allocation can be disabled by passing in @ioflag=FILE_EXTENSION=-1.
@ioflag=OVERLAPPED will cause the FILE_FLAG_OVERLAPPED to be passed in to the CreateFile method for disk backups and restores. This allows each SQLLiteSpeed VDI thread to use asynchronous IO, returning from WriteFile calls to begin processing the next block asynchronously to the writing of the previous block. See Microsofts MSDN for a description of this attribute. It only makes sense for SQLLiteSpeed to always pass in the FILE_FLAG_OVERLAPPED attribute for performance reasons.
Additionally, SQLLiteSpeed allows a further syntax of the parameter which allows for setting of the number of concurrent overlapped operations that can occur per each VDI thread. This syntax is @ioflag=OVERLAPPED=<<n>> where <<n>> is the number of concurrent overlapped operations to allow. SQLLiteSpeed allows 2 concurrent overlapped operations per VDI thread by default. Be aware that the higher the value of <<n>> then the more memory will be used. Each overlapped buffer pre-allocates (BASE_SIZE+(MAX_TRANSFER_SIZE*1.2)) bytes of memory. And each SQLLiteSpeed VDI thread has its own set of overlapped buffers. Example: @threads=4, @max_transfer_size=4194304, @ioflag=OVERLAPPED=5,@base_size=4194304 would allocate 4*5*(4MB+(4MB*1.2)) bytes of memory in the SQLLiteSpeed process for the overlapped buffers. That is 184MB of memory.
@ioflag=SEQUENTIAL_SCAN will cause the FILE_FLAG_SEQUENTIAL_SCAN to be passed in to the CreateFile method for disk backups and restores. See Microsofts MSDN for a description of this attribute. This attribute is only a recommendation to the device driver for performance reasons. This attribute is mutually exclusive with the RANDOM_ACCESS attribute. It only makes sense for SQLLiteSpeed to always pass in the FILE_FLAG_SEQUENTIAL_SCAN attribute. Here is a Microsoft link with more info on FLAG_SEQUENTIAL_SCAN: http://support.microsoft.com/kb/98756
@ioflag=NO_BUFFERING will cause the FILE_FLAG_NO_BUFFERING to be passed in to the CreateFile method for disk backups and restores. See Microsofts MSDN for a description of this attribute.
Here is a Microsoft link with more details about FILE_FLAG_NO_BUFFERING: http://support.microsoft.com/kb/99794
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx
