INF: How to Troubleshoot SQL Server Tape Read/Write ErrorsID: Q123405
|
The purpose of this article is to explore various hardware problems related to Microsoft SQL Server's use of attached tape devices. A basic review of the database dump and load process will provide a general frame of reference to the actual operation that reads or writes from/to the tape device. The review of these operations is not intended to explain the entire process, only to provide a common framework for exploring the subsequent SQL Server tape issues.
SQL Server provides the ability to write database pages to a database dump
device defined in master..sysdevices. The process that manages the load or
dump of database pages is shielded from the actual definition and operation
of the defined dump/load device. All that is required by either a dump or
load process is that the device be valid and accessible via the WIN32 API.
The WIN32 API call that exposes all hardware devices to SQL Server for the
purpose of dump/load is CreateFile() (see the WIN32 API Reference for
details). A successful return from this function call is a 'handle' to the
device, that can be referenced by SQL Server. This handle can be to a
floppy disk, a file on a hard disk, or a tape drive.
The actual activity of writing to the 'dump' device is commonly referred to
as a 'database dump' or backup. The term 'dump' is probably more meaningful
and not as easily confused with 'backup.' The term 'backup' can just as
easily refer to the writing of files to tape by NTBACKUP.EXE as well as
pages written from a database to tape; both operations perform a backup of
sorts. For the sake of consistency, database dump/load or dump/load will be
used for the remainder of this document when referencing the act of
reading/writing database pages from/to a dump device.
The database dump procedure is fairly straight forward. The database to be
dumped is opened. A header is generated for the database dump and written
to the selected device. All pages not actually in buffer cache are written
to the defined device. These cached pages are skipped and tracked by SQL
Server in the form of an 'Out of Sequence' queue. Pages that have not been
allocated to an object in the database are skipped completely. After the
allocated pages are written, the 'Out of Sequence' queue is traversed and
referenced pages are written out to the dump device. A trailer is
generated for the dump itself, and is written to the device, and the device
is then closed.
The load process is initially very similar to the dump process. A valid
'handle' must be obtained and the device opened. Once opened, the
information contained on the physical medium is transferred to SQL Server.
SQL Server then writes the information page by page into the target
database. After all the pages from the dump device have been transferred,
the remaining 'missing' pages in the database are created and initialized.
The final step taken by SQL Server is to recover the database. This is the
same process that SQL Server uses when it recovers a database on startup.
It is possible that uncommitted transactions are rolled back and committed
transactions rolled forward.
This is the basic process at the server, however, a interface must be
exposed so that information can be exchanged between the client and the
server. This interface is not required for database dumps/loads to/from
hard disk devices, but is very important for removable media such as tape
and floppy disks. The comments in the following paragraphs are directed
towards these removable media operations.
There are several methods that SQL Server uses to communicate with the
spid (server process id) that initiated the dump/load process. The oldest
method of communicating with SQL Server for floppy disk and tape
dumps/loads, and one that this common to both SQL Server for OS/2 and SQL
Server, is by using the CONSOLE.EXE. Running CONSOLE.EXE provides a link to
SQL Server by allowing communication with a special 'console' thread which
is spawned as SQL Server starts up. This interface allows information to
pass between the client and SQL Server during database loads or dumps, via
tape or floppy disk (See the "Transact-SQL Reference Guide," Utilities
chapter for details). However, the most flexible and user friendly tool for
the dump/load process is provided through SQL Administrator.
SQL Administrator is a WIN32 or WIN16 graphical user interface (GUI)
application, which provides a Windows environment facilitating
communication to SQL Server for all types of database dumps/loads. Tape and
floppy disk dumps are handled somewhat differently, because there is an
interface between SQL Administrator and SQL Server provided by SQL Monitor.
Any time dumps/loads are initiated by SQL Administrator, a connection to
SQL Monitor is made, which subsequently connects to the console thread
(this is the same thread that is exposed by CONSOLE.EXE). All prompts and
errors are passed from the Server, via the console thread, to SQL Monitor
which then passes them back to SQL Administrator or display/response.
The batch mode database dump is performed when SQL Server determines that
there is no interface to the console thread and the operation is a tape
dump or load (floppy disk dumps/loads require the console program or SQL
Administrator). This mode of operation will provide prompts back to the
client process that initiated the dump or load operation. Most of this type
of processing is facilitated by ISQL.EXE, and there is no capability for
the user/client process to respond to messages from the server. This method
depends heavily on Registry entries for handling the tape drive, which are
visible in SQL Setup by clicking the Options, Set Server Options, Tape
Support button. This entry will determine how long SQL Server will wait
and how often SQL Server will poll for a tape while in batch mode. (See the
SQL Server "Configuration Guide" for more information.)
As stated initially, the purpose of this article is to attempt to shed some
light on the common hardware errors seen in the SQL Server Errorlog and in
the Windows NT Event Viewer's Application Log (NOTE: this article will use
the SQL Server Errorlog rather than the Event Viewer's Application Log for
consistency) that involve the actual process of interfacing with the tape
drive. There are four main activities related to the use of the tape device
and SQL Server: opening the device, reading or writing from/to the device,
and closing the device. It is possible to receive errors from any one of
these operations.
A general synopsis of the typical database dump/write to tape from SQL
Server would be as follows:
Open the tape device
Write the Volume Label
Write the first Header
Write the second Header
Write a supported tape mark
Write the pages from the database
Write a supported tape mark
Write the first End of File Trailer
Write the second End of File Trailer
Write the final supported tape mark
Close the tape device
Open the tape device
Read the Volume header
Read the first Header
Read the second Header
Position the tape at the next supported tape mark
Read the database pages from the tape
Stop when the next supported tape mark is encountered
Read the first End of File trailer
Read the second End of File trailer
Close the tape device
Msg Severity Text
---- -------- ------
4027 16 Mount first tape for %s of database %s
4028 10 End of tape has been reached, remove tape %s and mount
next tape for %s of database %s
4029 10 Database %s%s(%d pages) dumped to file <%d> on tape %s.
4030 16 Tape %s expires on day %s year %s and cannot be overwritten
4031 16 Creation date on tape %s(%s) does not match that of
first volume(%s)
4032 16 Cannot find file %d on tape %s
4033 16 File <%d> on tape %s is not a SQL Server %s dump
4034 16 Warning, file <%d> on tape %s was dumped from database %s
No errors seen
None
No errors seen
None
No errors seen
None
No errors seen
None
kernel tbsreadflush: Read failure on backup device '\\.\TAPE0',
returned operating system error 1117(The request
could not be performed because of an I/O device error).
No errors seen
None
kernel tprhdrs: failed to seek Tape Mark, operating system error :
1(Incorrect function.)
kernel tprvol: Read returned 87, the parameter is invalid reading
volume header
kernel tbsreadcheck: tape rejected.
kernel tbswritecheck: Backup device '\\.\Tape0' failed to open.
Operating system error = 2 (The system can not
find the file specified.)
kernel tbswritecheck: Backup device '\\.\TAPE0' failed to open,
operating system error = 32(The process cannot
access the file because it is being used by
another process.)
kernel tbswritecheck: Seek operation in backup device '(null)'
returned operating system error =
kernel tbswritecheck: not enough space is left in the device to
initiate this dump.
kernel checktapeinfo: error getting media information for device
'\\.\Tape0', OS error:(null)
kernel checktapeinfo: Unable to load tape into the tape drive,
OS Error 121 (the semaphore time-out period has expired)
kernel checktapeinfo: Unable to load tape into the tape drive: OS
Error : 1112(No media in drive.)
kernel checktapeinfo: cannot write on a write protected tape
kernel tprhdrs: failed to seek Tape Mark, operating system error :
(Incorrect function.)
kernel tbsreadcheck: Tape rejected
No errors seen
None
No errors seen
None
No errors seen
None
No errors seen
None
kernel tpwvol: Seek operation in backup device failed returned OS
Error 1117 (The request could not be performed because of an
I/O device error.)
Additional query words: SQL Server WINNT Tape
Keywords : kbusage SSrvAdmin
Version : 4.21a
Platform : WINDOWS
Issue type :
Last Reviewed: April 14, 1999