3202 Severity Level 16 - Release 10.0 and Later Received MULTARG is not for device name as expected. Releases 4.9.x and Earlier Write on dump device '%.*s' failed, vsn=%ld return=%d status=%ld. Please consult the SQL SYBASE SQL Server Release 10.0 and Later The meaning of Error 3202 for SQL Server 10.0 and later is different from the meaning when it is raised on SQL Server 4.9.x and earlier. A MULTARG is a structure SQL Server stores in memory to keep information about the device being dumped to. If the dump routine was passed a MULTARG which is not for a dump device and you are running the Diagnostics Server (not likely), Error 3202 will be raised. If you receive Error 3202 when using SQL Server 10.0 or later, call Sybase Technical Support. Releases 4.9.x and Earlier For SQL Server 4.9.x and earlier versions, Error 3202 means that an error occurred when “writing” out a packet of data to the backup. Common causes are: • Running out of space for your dump (to disk) • A bad tape • A bad tape size • A bad block size • Hardware failure This error is fatal and stops the dump from completing. This invalidates the backup and makes it unusable for recovery purposes. The error message output includes: • vsn – the virtual socket number. • return – the return value: 0 means successful; -2 means failure. • status – the ending status, displayed in decimal value. The most common value is 524288 which usually means an I/O error. This status is Sybase-specific and has no operating system correlation. The following actions apply only to SQL Server 4.9.x and earlier versions. If a 3202 error occurs on SQL Server 10.0 or later, call Sybase Technical Support. To determine the cause of the 3202 error, look at the message above the 3202 error in your SQL Server error log. You should see a generic message about a write to tape/disk failure during a dump database or dump transaction. Depending on the reason Error 3202 was raised, perform one of the following actions. Not Enough Space Error 3202 can occur in dumps to disk if the database you are dumping is larger than the size of the file you are dumping to. This limit can be user-imposed or system imposed. Under VMS, a user can assign a limit for size on individual files. Under many versions of UNIX, there is a 2GB file system size limit. If you have a database that exceeds these limits, dump the database to tape. Error 3202 can occur when dumping to tape if the tape runs out before the entire database has been dumped. You will encounter this if the size specified for the device via sp_addumpdevice is larger than the capacity of the device. Hardware Errors • Check the SQL Server error log to see if there are other indications of hardware problems, such as kernel messages reporting I/O errors. • Check the operating system error log or diagnostics utilities for I/O errors. Check your operating system error log for operating system errors. If no errors are logged in your operating system error log andComments

3104 Severity Level 16 - LOAD DATABASE encountered page with invalid logical page number %ld. SYBASE SQL Server This error occurs when SQL Server detects an invalid page number within a database dump. The invalid page number is greater than the highest page number for the database to be loaded into. This is a serious error and it indicates a corrupted database dump. Attempts to access this database after it encounters Error 3104 may result in Error 930. Some potential causes of the error are: • Overlapping partitions. • Using UNIX operating system files for Sybase database devices (that is, if the file system fills up). This error only occurs in SQL Server releases earlier than 10.0. 1. Examine your operating system error log file and your SQL Server error log to determine if hardware errors may have caused the corruption. 2. If you have a clean backup of your database (not the one you just loaded), drop your database, re-create it with the for load option and load the dump into it. If you do not have a known clean backup of your database, contact Sybase Technical Support for assistance. Prevention In some cases, dbcc commands detect a problem in the database before the database is dumped, thus preventing the database from being dumped and loaded. More specifically, the following commands should be run prior to each dump: 1. dbcc checkdb. 2. dbcc checkalloc or dbcc checkalloc with the fix option. (See “How to Fix and Prevent Allocation Errors” in the SQL Server Troubleshooting Guide for information about running these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.) Before loading your database dump into a database, make sure that: 1. The database you will load into has the same data and log device allocations as the database dump. For more information about data and log mapping and user segment definitions, see “Error 2558” on page 2-274. 2. The database dump has the same user segment definitions as the database you want to load into. Additional Information Refer to: • “Device Administration Issues” in the SQL Server Troubleshooting Guide • load database in the System AdministrComments

2509 Severity Level 16 - Table Corrupt: The row number and offset of each row in the page should have a matching entry in row number table; check this page (page#=%ld row#=%d offset in row number table=%d) SYBASE SQL Server The offsets for data or index rows are stored at the end of every page (in the row number table) and indicate where a certain row is located on that page. Error 2509 occurs when the dbcc checkdb or dbcc checktable command detects that a row does not have an entry matching its offset (location) on the page in the row offset table. Attempts to delete the offending row will result in Error 631, while attempts to select the offending row may be successful. This problem is probably a result of a problem within SQL Server but may also be caused by one of the following: • Hardware failure • Sybase System Administration problems • UNIX System Administration problems First, make sure that you ruled out any of the above-mentioned causes of this error by referring to the appropriate sections in “Encyclopedia of Tasks” in the SQL Server Troubleshooting Guide. After you eliminated other more serious errors on this table, follow these steps to correct the 2509 error: 1. Follow the instructions in “How to Find an Object Name from a Page Number” in the SQL Server Troubleshooting Guide to identify which table and index correspond to the page number from the error message text. Also note the object ID. 2. If the object with the error is not a system table (object ID is more than 100), continue with step 3. If the object with the error is a system table and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables” in the SQL Server Troubleshooting Guide for instructions on how to repair the system table index. If the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption or it may be necessary to restore from clean backups. 3. If the object with the error is a user table, use one of the following three methods to clear the 2509 error: - Create a clustered index on the corrupted table. Creating a clustered index will copy the whole table onto new data pages, and will overwrite the row number table on each page. If a clustered index already exists on the table identified in step 1, drop the clustered index and re-create it. u WARNING! If you have other seriComments

806 Severity Level 21 - Could not find virtual page for logical page %ld in database '%S_DBID'. SYBASE SQL Server This error occurs when SQL Server fails to convert a logical page number to a virtual page number. Depending on what caused the error, it can be serious or transient. A virtual page is the page within a Sybase device whereas a logical page is the page in a SQL Server database. There is a one-to-one correspondence between the two types of pages. If Error 806 appears with a stack trace and exec_dbcc appears in the stack trace, it means you used dbcc page with an invalid parameter. This is not a serious problem. If Error 806 occurs on recovery, it may be transient or serious (see information under “Explanation” for specifics). Error 806 can occur during normal processing, such as creating an index or running a stored procedure. In this case, the error is probably caused by corruption or a problem with SQL Server and it is a serious error. If Error 806 specifies tempdb in the message output, restart SQL Server. Since tempdb is rebuilt each time SQL Server is restarted, this may clear the error. If the error occurs again (on tempdb), call Sybase Technical Support. During Recovery If Error 806 occurs on recovery, the database will be marked suspect. If the error is transient, resetting the suspect status will solve the problem. To determine whether this is the case, reset the suspect status one of two ways: • Execute the sp_resetstatus procedure supplied in “How to Reset a Database’s “suspect” Status” in the SQL Server Troubleshooting Guide. This is the safest method. After you execute sp_resetstatus, go to step 3 in the following set of steps. • Alternatively, you can do the following: 1. Use the following procedure on the suspect database: 1> sp_configure "allow updates", 1 2> go 1> reconfigure with override 2> go 1> use master 2> go 1> begin transaction 2> go 1> update sysdatabases 2> set status = status & ~256 3> where name="database_name" 4> go If only one row is affected by the update transaction, continue with these instructions. If more than one row is affected by the update transaction, roll back the transaction and find out why other rows are being affected. 2. If the above commands affect only one row, use the commands below to commit the transaction, disable updates to the system tables, issue a checkpoint, and shut down SQL Server: 1> commit transaction 2> go 1>Comments

614 Severity Level 21 - A row on page %ld was accessed that has an illegal length of %d in database '%.*s'. SYBASE SQL Server This error occurs when SQL Server accesses a data or index row whose length is smaller than the minimum row size or greater than the maximum row size. The minimum length of a row for each object is stored in the minlen column of sysindexes and in each data or index page header. The maximum size allowed for a data row or index row is 1962 bytes. (On Stratus platforms, the row size can be up to 4010 bytes because Stratus platforms have a larger page size than other platforms.) This error can occur under the following conditions: • During normal processing, when SQL Server tries to access the row specified by the error message. • During database recovery (database recovery occurs during SQL Server start-up or when a load database or load transaction command is processed). Error 614 can be caused by data corruption during normal processing (for example, an operating system panic occurs, causing interruption in disk writes when using UNIX files for SYBASE database devices). This may be due to a problem with SQL Server, the operating system, or hardware. Error 614 is usually the result of a more serious underlying problem, and recovering from this error depends on when the error occurred. Determine whether the error occurred during normal processing or during database recovery, then follow the appropriate set of instructions in this section. If the Error Occurred During Normal Processing 1. Use the procedure in “How to Find an Object Name from a Page Number” in the SQL Server Troubleshooting Guide to identify which table and index correspond to the page number from the error message text. 2. If the object encountering the error is not a system table (a system table’s object ID is less than 100), continue with step 3. If the object encountering the error is a system table and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables” in the SQL Server Troubleshooting Guide for instructions on how to repair the system table index. If the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption, but it may be necessary to restore the database from clean backups. 3. For user tables, if the index ID is 0, continue with step 4. If the index ID is not 0, translate it into an index name: 1> use database_name 2> go 1> select name from sysindexes 2> where id = object_ID and indid = index_ID 3> go Drop the index. To ensure that the information needed to re-create the index is available, you may need to run the sp_helpindex procedure on the indeComments

629 Severity Level 21 - Fatal attempt to delete clustered index entry for page %ld - index row contains page %ld. SYBASE SQL Server This error occurs when SQL Server fails to delete a clustered index entry because the index entry did not point to the expected page. In the error message text, the first page number refers to the data page and the second page number refers to the node-level index page that points to the data page. Error 629 can occur when you attempt to delete a row (for example, when a table that has a clustered index is dropped, the row in sysindexes is deleted). The error is caused by data corruption that occurred during SQL Server processing (for example, an operating system panic occurs, causing interruption in disk writes when using UNIX files for SYBASE database devices). This may be due to a problem with SQL Server, the operating system, or hardware. 1. Use the procedure in “How to Find an Object Name from a Page Number” in the SQL Server Troubleshooting Guide to identify which table and index correspond to the first page number in the error message text. 2. If the object encountering the error is not a system table (a system table’s object ID is less than 100), continue with step 3. If the object with the error is a system table, refer to “How to Fix a Corrupted Index on System Tables” in the SQL Server Troubleshooting Guide for instructions on how to repair the system table index. Then go to step 4. 3. Translate the index ID into an index name: 1> use database_name 2> go 1> select name from sysindexes 2> where id = object_ID and indid = 1 3> go To ensure that the information needed to re-create the index is available, you may need to run the sp_helpindex procedure on the index prior to dropping it. Drop the index. Re-create the index. This clears the corruption in most cases. 4. Run dbcc checktable on the table to verify that the corruption is gone. If corruption still exists, call Sybase Technical Support. Additional Information See the System Administration Guide and SQL Server Reference Manual for information about dropping and re-creating indexes. Comments

631 Severity Level 21 - The length of %d passed to delete row routine for the row at offset %d is incorrect on the following page: %S_PAGE. SYBASE SQL Server This error occurs when SQL Server attempts to delete a row (via a direct delete or inherently through updating) from an index or data page by specifying the row offset and the row length, and the action fails because the specified values of the offset or row length did not match the actual values. Error 631 can happen under the following conditions: • During normal processing, when SQL Server tries to delete the row specified by the error message. • During database recovery (database recovery occurs during SQL Server start-up or when a load database or load transaction command is processed). Some potential causes of Error 631 are: • Data corruption during normal processing (for example, an operating system panic occurs, causing interruption in disk writes when using UNIX files for SYBASE database devices). This may be due to a problem with SQL Server, the operating system, or hardware. • Hardware failure during loading or dumping Error 631 is probably the result of a more serious underlying problem, and recovering from this error depends on when the error occurred. Follow the instructions in this section, selecting the correct set depending on whether the error occurred during normal processing or during database recovery. If the Error Occurred During Normal Processing 1. Use the procedure in “How to Find an Object Name from a Page Number” in the SQL Server Troubleshooting Guide to identify which table and index correspond to the page number from the error message text. 2. If the object encountering the error is not a system table (a system table’s object ID is less than 100), continue with step 3. If the object with the error is a system table and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables” in the SQL Server Troubleshooting Guide for instructions on how to repair the system table index. If the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption but you may have to restore from clean backups. 3. For user tables, if the index ID is 0 or 255, continue with step 4. If the index ID is not 0 or 255, translate it into an index name: 1> use database_name 2> go 1> select name from sysindexes 2> where id = object_ID and indid = index_ID 3> go Drop the index. To ensure that the information needed to re-create the index is available, you may need to run the sp_helpindex procedure on the index prior tComments

3201 Severity Level 16 - Release 10.0 and Later No dump device has been specified. SQL Server Releases Up to 4.9.x Can’t open dump device '%.*s', device error or device off line. Please consult the SQL Server error logSYBASE SQL Server This error occurs when SQL Server is unable to access a dump device during a database dump. This error is fatal and stops the dump from completing. Error 3201 is most likely caused by one of the following: • The device you specified for the dump is offline or otherwise unavailable to SQL Server. • Permissions for the dump device are not set correctly for user “sybase” or the user performing the dump (read and write privileges are required). • A previous dump aborted and SQL Server believes the dump device is still in use. • For SQL Server releases previous to 10.0, you are trying to run more than one dump database command at the same time. You can only do this (for tape devices) if the cntrltype values (defined using sp_addumpdevice) of the devices to which you are dumping are different. For example, only one disk byte stream interface can be active at a time. You cannot dump multiple databases or transaction logs to the same tape device or disk dump. As of SQL Server 10.0, dumps are performed by the Backup Server. During dump and load commands, the Backup Server automatically determines whether a tape or disk device is being used and what its controller type is. It ignores the cntrltype parameters specified with sp_addumpdevice. 1. Check to make sure the device you specified is defined for your SQL Server: 1> select * from master..sysdevices 2> where status = 16 or status = 24 3> go low high status cntrltype name phyname mirrorname --- ------ ------- ---------- ---------- ---------- --------- 0 20000 16 3 tapedump1 /dev/rmt4 NULL 0 20000 16 2 tapedump2 /dev/rst0 NULL If the device is not there, you can use sp_addumpdevice to add it. 2. At the operating system level, check the permissions for the dump device for user “sybase” or the user performing the dump (read and write privileges are required). 3. For SQL Server releases 4.9.x and earlier with the dump database being done to a tape dump device, do this step. Using sp_who and dump device information from the SQL Server error log, check whether SQL Server believes a dump device is still in use from a previous dump that aborted. If this is true, restart SQL Server. This should clear the error and allow you to do your dump. 4. For SQL Server releases previous to 10.0, if you wish to run more than one dump database (to tape) command at the same time and the cntrltype values (as shown above) of the devices to which you are dumping are the same, change the appropriate cntrltype values. For disk and file dump devices and for tape drives to be used as disk dump devices, you can only define one cntrltype value and the controller number parameter must be 2 (byte stream interface). For tape dump devices, the controller number paraComments

3307 Severity Level 21 - Process %d was expected to hold logical lock on page %ld. SYBASE SQL Server This error occurs when SQL Server, while committing or aborting a transaction, attempts to release a lock on the page displayed by the error message and the page is not locked. This error may occur during recovery as well as during run time. Common causes of this error are: • Software failures. • When SQL Server was performing a rollback, it expected a logical lock on the page displayed in the error message but the lock could not be found. • When SQL Server attempted to deallocate a page, it expected a logical lock on that page but one did not exist. • SQL Server tries to undo a page deallocation. • SQL Server tries to roll back a user transaction which has executed a stored procedure that required reresolution. Reresolution is required for stored procedures that reference objects which have been dropped and re-created between executions. Refer to “Procedure Re-resolution” in the SQL Server Troubleshooting Guide for more information about reresolution. Look for other errors in the Sybase error log as well as in your operating system error log to find out the specific source of the problem and clear those errors first, as they might be the actual cause of the error. Restarting SQL Server will release any locks that active transactions might still hold. However, this will not clear the root cause of this error. If there are no other errors in the Sybase error log or in your operating system error log, contact Sybase Technical Support for assistance. Additional Information For more information about transactions, see transaction in the Transact-SQL User’s Guide. Before calling Technical Support, have the following information available: • SQL Server release and EBF Rollup level • SQL Server error log • Hardware error log • Output of sp_lock and sp_who before restarting SQL Server • Text of all error messages Recovery Errors This section contains error messages pertaining to SQL Server recovery. Comments

3425 Severity Level 21 - Transaction (%ld, %d) not found in transaction table. SYBASE SQL Server This error occurs when, during SQL Server recovery, load transaction, or load database, an end (commit or rollback) transaction log record was found that does not have a corresponding begin transaction record. Therefore, the transaction could not be rolled back or committed and recovery or load could not complete for that database. You cannot use the affected database until whatever caused the error has been corrected because SQL Server marks the database suspect. If the error occurred during recovery, determine which database had the error by looking at your SQL Server error log. If you have a clean backup, restore your database using that backup. If you do not have a clean backup, call Sybase Technical Support. Additional Information If you need assistance from Sybase Technical Support, have the following information available when you call: • SQL Server release and EBF Rollup level • SQL Server error log • Text of all error messages Comments