This section contains error messages for problems in Adaptive Server access methods.
21
Descriptor for system table '%ld' in database '%d' not found in the descriptor hash table.
Adaptive Server expects every database to have a systhresholds table. Error 601 occurs when the Adaptive Server Threshold Manager could not open the systhresholds system table in a database because the descriptor for systhresholds was not found. The failure to open systhresholds is probably due to corruption in the database named in the error message.
Determine the name of the database from the database ID in the error message:
1> use master 2> go
1> select * from sysdatabases where dbid = ID 2> go
where ID is the database ID from the error message.
Determine whether the system table object ID displayed in the error message exists:
1> use database_name 2> go
1> select * from sysobjects where id = object_ID 2> go
where database_name is the name from step 1 and object_ID is the system table ID listed in the error message.
If the ID exists for the table displayed in the message, then the 601 error may be due to corruption in the memory structure used to hold the descriptor. Shutting down and restarting Adaptive Server should clear the problem. If this does not work, go on to step 4.
If the ID does not exist, there is probably corruption in your database. Do the following:
Run dbcc checkalloc, dbcc checkcatalog, and dbcc checkdb for the database.
Determine whether hardware problems exist by checking your operating system error log.
Call Sybase Technical Support. They may be able to help you recover your database, but you will probably have to recover your database from backups.
Before contacting Technical Support, be prepared to provide:
Adaptive Server version and SWR version level
Complete text of all error messages
Adaptive Server error log output
Operating system error log output
dbcc checkalloc, dbcc checkcatalog, and dbcc checkdb output for the database listed in the error message
All versions
17
There are not enough system session descriptors available to run this query. Raise the value of the configuration parameter ’number of aux scan descriptors’ or retry your query later.
This error occurs when Adaptive Server runs out of system session descriptors when running a query. Error 603 can occur on commands which create, drop, and update objects, as these commands often have many dependencies on system tables which Adaptive Server must handle to complete the command.
Session descriptors are the data structures used to manage access to Adaptive Server objects. Session descriptors come in three forms: user session descriptors (including worktable session descriptors), system session descriptors, and worktable session descriptors.
Session descriptors are used in the following situations:
When your query is compiled or executed, a user session descriptor is reserved and assigned to each table involved in the query. Currently, a maximum of 16 user session descriptors are possible, limiting the number of tables involved in a query to that number. If a single table is referenced more than once in the from clause (a “self join”), a user session descriptor is reserved for each reference. User session descriptors correspond to the number of open objects configuration parameter.
System session descriptors are used for system tables that are not named in the query. For example, the following query:
select x from t where y = 3
prompts Adaptive Server to open sysobjects and syscolumns to look up the table t and its columns x and y. A maximum of six system session descriptors are available.
A worktable session descriptor is used to manage references to worktables. A worktable is required for order by, group by, distinct, and some other operators. Also, the query optimizer may choose a plan involving reformatting which copies rows from a table into a worktable, creates an index, then performs joins between the worktable and other tables in the query. There are 12 worktable session descriptors that can be used at any one time.
You cannot change the number of session descriptors available to a query.
When you get Error 603, you do indeed have to simplify your query or command. To recover from this error, split up your query or simplify the command and run it again.
For example, if you are entering a drop procedure command and that procedure contains other procedures or triggers, you can simplify your command by dropping the other procedures or triggers manually before running the drop procedure command.
Refer to “Setting Configuration Parameters” in the System Administration Guide for a description of number of aux scan descriptors and how queries use scan descriptors.
All versions
21
An attempt was made to fetch logical page '%ld' in database '%.*s' from cache '%.*s'. Page belongs to object with id '%ld', not to object '%.*s'.
This serious error occurs when Adaptive Server discovers page allocation corruption. Adaptive Server tries to access a particular object but discovers a page in the page chain for that object whose object ID is different than that of the object being accessed. There is probably either a damaged page chain or an invalid entry in the system tables for that object.
Usually this error is detected after the corruption has been written to the database on disk (hard 605), but it can also occur entirely in cache without the damage ever being written to disk (transient 605), and is not associated with data corruption. See the next section for more information about the different kinds of 605 errors and their causes.
When an error is transient, it means it is reported
even though no error condition exists or it exists only in memory.
Generally, a transient error is cleared by a reboot of Adaptive
Server, whereas a hard error does not go away with an Adaptive Server
reboot.
For accurate diagnosis of object ID mismatch problems, the 605 error is raised only when the objects in question are user objects. Other related types of errors result in one of the errors 691 through 697. Refer to the writeups for these errors in this chapter for details.
Assuming the error is not a transient 605, corruption usually exists in the second object specified in the 605 error text. If the dbcc checkdb and dbcc checkalloc commands do not report additional errors, the first object mentioned is not corrupt. Because the 605 error can mask the existence of other errors, you must run the dbcc checks to determine the extent of the damage.
Instead of listing two object names, this error might contain other information:
The error displays a number greater than zero. An attempt was made to refer to an object ID that does not exist in the system table sysobjects.
If the error states that a page belongs to object “ALLOCATION,” some of the allocation structures used by the database may be corrupted.
Hardware Cause |
Additional Information |
Transient or Hard |
|---|---|---|
Overlapping partitions on disk (UNIX only).a |
Often this occurs when the server is installed on a partition that overlaps other partitions. |
Hard |
Problem with device driver |
-- |
Hard |
Problem with controller |
-- |
Hard |
Bad disk |
“Data retry” messages in /var/adm/messages (UNIX). |
Hard |
a. For more information about overlapping partitions, refer to “Correct Use of Raw Partitions” in the Encyclopedia of Tasks chapter. |
||
Software Causes |
Additional Information |
Transient or Hard |
|---|---|---|
Loading a master database on a master device that does not have rows in sysusages for dbid 1,2,3 identical to the device it was dumped from. |
-- |
Hard |
Loading a master database that has syscharsets in a location that is different from the default. |
Caused by changing Adaptive Server sort order after operating it for some time. |
Hard |
Operating system notifies Adaptive Server that an I/O operation is complete when it is not. Any time buffer information about a page is different from the disk information about the page (and the disk has the correct information). |
Adaptive Server connection often dies. Running dbcc checkdb and dbcc checkalloc should produce no more 605 errors. Corruption is not on disk. First, checkpoint the other databases. Then, perform a shutdown...with nowait and restart Adaptive Server. |
Transient |
Run the dbcc checktable command on the second object specified in the error message.
To help determine the full extent of the corruption, run the dbcc checkdb and dbcc checkalloc commands as soon as feasible.
Check the Adaptive Server error log for other errors which often accompany a 605 error. If the 605 error is not transient, the problem is severe and you will probably need to restore from known clean backups.
Either of the following situations may also apply to your Adaptive Server:
If this error occurs after rebuilding the master device or reconfiguring the configuration block to the defaults, then the sort order on the new device may not match the sort order in the dump. If the sort orders do not match, call Technical Support for further assistance.
To check if the error occurred as the result of hardware failure, examine your operating system error log and correct hardware problems.
If you have dial-in facilities, Technical Support may be able to help you recover from this error without having to restore from backups. However, this recovery procedure often results in a loss of data, and therefore is often unacceptable, especially for production systems.
For information on locating device fragments, refer to “How to Determine Which Physical Devices a Database is On” in the Encyclopedia of Tasks chapter.
Have the following information ready before contacting Technical Support:
Adaptive Server version and SWR version level
Complete text of all error messages
Adaptive Server error log output
Operating system error log output
Output of dbcc checkdb, dbcc checkalloc, and dbcc page for the corrupted page
Related Page Mismatch Errors in Version All versions
Starting with Version 11.0.3, many page mismatch problems no longer raise 605 errors, but are instead reported with the following error numbers:
Error |
Description |
691 |
Page 0 is read incorrectly, or an attempt is made to read a negative page number. |
692 |
Attempt to read an uninitialized page. |
693 |
I/O request was made prematurely, causing an object ID mismatch. |
694 |
The device or operating system may be suspect. |
695 |
The page has been overwritten, for example page 10 on disk may actually hold page 20. Hard error. |
696 |
Objects are crossed in tempdb. Similar to a 605 except that objects are in tempdb. |
697 |
Results from memory corruption. |
Refer to the writeups for these errors in this manual for more information.
All versions
21
Attempt made to end a transaction that is idle or in the middle of an update.
This error occurs when a termination request event occurs during the processing of a transaction. Error 611 can be caused by:
Massive processing using group by or order by.
A stored procedure that references other stored procedures (and is in the midst of calling those procedures) being dropped.
An Adaptive Server problem.
To determine what might have caused the above error message, check for the following:
dbcancel calls from within DB-Library exit processing routines that fail to test all error conditions
Users typing Ctrl-c during heavy use of temporary tables
Error 611 may produce a stack trace that gives a portion of the SQL that caused the error. Obtain the entire stack trace, along with any errors that might have occurred prior to or following the 611 error, to determine the internal state of the process at the time of the failure.
All versions
21
A row on page %ld was accessed that has an illegal length of %d in database '%.*s'.
This error may be caused by a hardware problem.
This error occurs when Adaptive 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 size of a data row or index row is 1962 characters; allow 2 characters of row overhead for APL tables, for a maximum usable row size of 1960. For DOL tables, subtract two characters per varchar column in determining usable row size.
This error can occur under the following conditions:
During normal processing, when Adaptive Server tries to access the row specified by the error message.
During database recovery (database recovery occurs during Adaptive 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 Adaptive 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.
Use the procedure in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to identify which table and index correspond to the page number from the error message text.
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 Encyclopedia of Tasks chapter 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.
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
To ensure that the information needed to re-create the index is available, run sp_helpindex on the index prior to dropping it.
Drop the index.
Re-create the index. This clears the corruption in most cases.
Run dbcc checktable on the table to verify that the corruption is gone.
If the index ID is 0, do one of the following:
Restore the database from clean backups.
Refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
WARNING! Some data might be lost on this page if you recover your table using bcp or select into (that is, the corrupted row and rows following it might be truncated and contain the wrong keys). Compare the two tables (old and new) row by row (by joining them on a primary key, for example) to see which rows are different (corrupted).
Before dumping your database, make sure it works correctly. Run the following commands prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about how to run these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)
When this error occurs during recovery, the database is marked suspect and is not accessible. Usually, you must load the database from backup. To do this, follow the instructions below:
If the database in the 614 error is tempdb, check the page number. If this page is not valid for tempdb, the problem may be on another database (possibly due to a bad device). Stop here and contact Sybase Technical Support.
If the page is valid for tempdb, or the 614 error refers to a database other than tempdb, continue with step 2.
Drop the database. If the drop fails, follow the instructions in “How to Drop a Database When drop database Fails” in the Encyclopedia of Tasks chapter.
Create a database for load. Make sure the database you create has sizes at least as large as those in sysusages for the original database (and that all other sysusages values match the original values). Refer to “create database” in the ASE Reference Manual for information on create database for load.
Load the database from backup. (Refer to “load database” in the ASE Reference Manual.)
Use the online database command to make the database available for use.
If loading from backups is not feasible, call Sybase Technical Support. Have the following documentation ready:
Adaptive Server error log
Text of all error messages
select * from master..sysusages output
To prevent Error 614 occurring on recovery, checkpoint each database that is being used before shutting down Adaptive Server.
Refer to “Developing a Backup and Recovery Plan” in the Adaptive Server Enterprise System Administration Guide for information about how to safely create, dump, load, and re-create databases.
All versions
20
Opentable was passed a varno of %d. Object '%.*s' already has that session descriptor in use.
A session descriptor is an internal data structure in Adaptive Server which contains information about a table. All open objects in Adaptive Server require a descriptor structure. Whenever a connection to Adaptive Server attempts to open a table, it gets a session descriptor. varno refers to a variable number that Adaptive Server uses to maintain an array of session descriptors for a query. A unique varno is assigned to each session descriptor tracking the usage of a given object for the query.
Error 622 is raised when Adaptive Server attempts to open a table, but the varno points to a session descriptor that is already in use.
Error 622 breaks the user's connection to Adaptive Server.
Error 622 is due to an Adaptive Server problem. Contact Sybase Technical Support for assistance when this error is raised.
When calling Technical support, have the following information available:
Adaptive Server version and SWR version level
Adaptive Server error log
Text of all error messages
Text of the query that raises the error
All versions
21
Attempt to retrieve row from page via RID failed because logical page %ld is not a data page. %S_RID. %S_PAGE.
This error may be caused by a hardware problem.
This error occurs when Adaptive Server tries to retrieve a row from a data page by specifying the row ID (RID) and the retrieval fails because the requested page was not a data page. This error is usually caused by a server problem.
After loading a database on top of an existing database, Error 623 may appear during recovery or while doing a checkpoint.
This error may or may not be transient (transient errors disappear after Adaptive Server is restarted). In the worst case, Error 623 may indicate corruption in your database. Perform the action below as soon as possible to determine how serious the error is and to avoid further corruption if corruption has occurred.
Determine whether this error is transient by performing the following steps:
Refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter for instructions on how to use the dbcc page command to determine the table involved. Save this information and use it in the appropriate section below.
Using the object ID found in step 1, issue the following query to determine the table name:
1> select object_name(object_ID) 2> go
Using the table name displayed in the output from step 2, issue the following query to determine whether corruption has occurred:
1> dbcc checktable(table_name) 2> go
If no errors occur when you run dbcc checktable, the 623 error was probably transient. Shut down and restart the server.
If errors do occur when you run dbcc checktable, refer to the writeups for those errors in this manual for instructions on how to recover from them or restore your database from a clean backup. To restore from backup, follow the instructions below:
Drop the database. If the drop fails, follow the instructions in “How to Drop a Database When drop database Fails” in the Encyclopedia of Tasks chapter.
Create a database for load. Make sure the database you create has sizes as least as large as those in sysusages for the original database and that all other sysusages values match the original values. Refer to “create database” in the ASE Reference Manual for information on create database for load.
Load the database from backup. (Refer to “load database” in the ASE Reference Manual.)
Use the online database command to make the database available for use.
If loading from backups is not feasible, call Sybase Technical Support. Have the following information ready:
Adaptive Server version and SWR version level
Adaptive Server error log
Text of all error messages
select * from master..sysusages output
Refer to “Developing a Backup and Recovery Plan” in the System Administration Guide for complete information about how to safely create, dump, load, and re-create databases.
All versions
21
Attempt to retrieve row from page via RID failed because the requested RID has a higher number than the last RID on the page. %S_RID.%S_PAGE.
This error may be caused by a hardware problem.
This error occurs when Adaptive Server tries to retrieve a row from a data page by specifying the row ID (RID), but the retrieval fails because the requested row ID was a higher number than the last row ID on the page. This can happen:
During normal processing, if the leaf page of a corrupt non clustered index points to an incorrect or nonexistent row ID on a data page.
During database recovery at Adaptive Server startup (database recovery also occurs when a load database command is processed). Recovery fails because the data structure which contains the last checkpoint record in the transaction log is pointing to an incorrect or nonexistent record in the log.
Errors 624 and 625 occur under similar conditions.
Recovery from this error depends on when the error occurred. Determine whether the error occurred during normal processing or during database recovery and then follow the appropriate instructions in this section:
Refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter for instructions about how to use the dbcc page command to determine the table involved. Save this information and use it in the appropriate section below.
The specific action you take depends on whether or not you know which index or query caused the problem. In general, dropping and re-creating the index should resolve the index corruption.
If you do not know which index is causing the problem, but you do know which query encounters the problem, use this section to correct it. If you do not know the index or query, go to “Index and Query Both Unknown”.
Determine which index should be dropped by reading the showplan output for the query that encounters the error and determining which nonclustered index the query is using to access the table in question.
Turn on showplan and use the no execute mode:
1> set showplan on 2> go
1> set noexec on 2> go
Enter the query that was causing the problem. For example:
1> select title from titles where title > "Cooking" 2> go
STEP 1 The type of query is SELECT FROM TABLE titles Nested iteration Index: titlein
Turn showplan and the no execute mode off again:
1> set noexec off 2> go
1> set showplan off 2> go
If the index identified in step 1 is on a system table (object ID is less than 100), refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on repairing the system table index. Otherwise, drop and re-create the index identified in step 1 (in this example “titleind”).
If you do not know either the index or the query, rebuild all nonclustered indexes on the table using the instructions in this section.
Examine the dbcc page output you obtained earlier.
If the object is a system table (the object ID is less than 100), refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index. Then go to step 3.
For a user table, use sp_helpindex to list all indexes on the table, and then rebuild all the nonclustered indexes using one of two methods:
Drop and re-create each nonclustered index on the table.
Or:
If a clustered index also exists on the table, drop and re-create it; this causes all nonclustered indexes to be rebuilt. If your table is large, you may not have the space to do this (a rough rule of thumb is 120 percent to 150 percent of your table size must be available).
Run dbcc checktable on the table to confirm that the problem has been resolved.
When this error occurs during recovery, the database is marked suspect and is not accessible. Usually, you must load the database from backup. Follow the instructions below, depending on the version level of your server (if you have dial-in facilities, Sybase Technical Support may be able to correct the problem so that recovery of this database can proceed):
Drop the suspect database using the instructions in “How to Drop a Database When drop database Fails” in the Encyclopedia of Tasks chapter.
Create a database for load. Make sure the database you create has sizes as least as large as those in sysusages for the original database (and that all other sysusages values match the original values). Refer to “create database” in the ASE Reference Manual for more information on create database for load.
Load the database from backup (refer to “load database” in the ASE Reference Manual).
Use the online database command to make the database available for use.
All versions
21
Could not retrieve row from logical page %ld via RID because the entry in the offset table for that RID is less than or equal to 0.
This error may be caused by a hardware problem.
Every row in a database has a unique row ID (RID). The two parts of a row ID are a logical page number and a row number. The row number part of row IDs are stored at the end of every data page and indicate where a certain row is located on that page.
Commands that use row IDs include dbcc checkdb, dbcc checktable, and dbcc checkcatalog. They verify the consistency of indexes and use the row IDs stored in nonclustered indexes to quickly access the data rows.
Error 625 occurs when Adaptive Server tries to retrieve a row from a data page by specifying the row ID and it fails because the requested row ID has an illegal value (smaller than or equal to zero).
This error can occur under the following conditions:
The data page of a nonclustered index is corrupt.
Hardware failure.
Errors 624 and 625 occur under similar conditions.
Examine your operating system error log file and the Adaptive Server error log to determine if hardware errors may have corrupted your database devices.
Refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter for instructions about how to use the dbcc page command to determine the table and the index involved. Save this information and use it in the appropriate section that follows.
The specific action you take depends on whether or not you know which index or query caused the problem. In general, dropping and re-creating the index will resolve the index corruption.
If you do not know which index is causing the problem, but you do know which query encounters the problem, use this section to correct it. If you do not know the index or query, use the next section.
Determine which index should be dropped by reading the showplan output for the query that encounters the error and determining which nonclustered index the query is using to access the table in question.
Turn on showplan and use the no execute mode:
1> set showplan on 2> go
1> set noexec on 2> go
Enter the query that was causing the problem. For example:
1> select title from titles where title > "Cooking" 2> go
STEP 1 The type of query is SELECT FROM TABLE titles Nested iteration Index: titleind
Turn showplan and the no execute mode off again:
1> set noexec off 2> go
1> set showplan off 2> go
If the index identified in step 1 is on a system table (object ID is less than 100), refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
Otherwise, drop and re-create the index identified in step 1 (in this example “titleind”).
If this did not clear the error, create a clustered index on the table or drop and re-create the existing clustered index. Note that creating a clustered index requires an amount of space equal to 120 percent to 150 percent of the size of the table where you want to create the index.
If you do not know either the index or the query, rebuild all nonclustered indexes on the table using the instructions in this section.
Look at the dbcc page output you obtained earlier.
If the object is a system table (object ID is less than 100), refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on repairing the system table index. Then go to step 4.
For a user table (object ID is 100 or greater), use sp_helpindex to list all indexes on the table, and then rebuild all the nonclustered indexes using one of two methods:
Drop and re-create each nonclustered index on the table.
Or:
If a clustered index also exists on the table, drop and re-create it, which causes all nonclustered indexes to be automatically rebuilt. If your table is large, you may not have the space to do this (a rough rule of thumb is 120 percent to 150 percent of your table size must be available).
If the above methods did not clear the error, create a clustered index on the table (if space is available). You may then drop the clustered index.
Run dbcc checktable on the table to confirm that the problem has been resolved.
For more information, refer to “create database” in the ASE Reference Manual.
If you need to call Technical Support for assistance, have the following documentation ready:
Adaptive Server version and SWR version level
Adaptive Server error log
Text of all error messages
select * from master..sysusages output
All versions
21
Clustered index row entry for data page %ld is missing in index page %ld of table '%S_OBJID' in database '%S_DBID'; index row contains data page %ld instead. You can recreate the clustered index to fix this error. Xactid is (%ld,%d).
This error occurs when Adaptive 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 last page number refers to the leaf-level index page that points to the data page.
Error 629 can occur when you attempt to delete a row in a table that has a clustered index, but Adaptive Server cannot find a pointer from the leaf page of the clustered index to the data page as expected.
The error is caused by data corruption that occurred during Adaptive 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 the server, the operating system, or hardware.
Use the procedure in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to identify which table and index correspond to the first page number in the error message text.
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 Encyclopedia of Tasks chapter for instructions on how to repair the system table index. Then go to step 6.
Determine the index name and the first page in the page chain.
1> use database_name 2> go
1> select name, first from sysindexes 2> where id = object_ID and indid = 1 3> go
Check that the page linkage is intact.
1> dbcc pglinkage(<dbid>,<first page>,0,1,0,1) 2> go
If you see a message indicating “End of chain reached”, the page linkage is intact; continue with Step 5. If you do not see such a message, the page linkage is bad; stop here, do not drop the clustered index, and contact Sybase Technical Support.
To ensure that the information needed to re-create the index is available, run sp_helpindex on the index prior to dropping it.
Drop the index.
Re-create the index. This clears the corruption in most cases.
Run dbcc checktable on the table to verify that the corruption is gone. If corruption still exists, call Sybase Technical Support.
Refer to “drop index” and “create index” in the Reference Manual for information about dropping and re-creating indexes.
All versions
21
The length of %d passed to delete row routine for the row at offset %d is incorrect on the following page: %S_PAGE. The expected row length is %d. The offset should be no greater than %d.
This error may be caused by a hardware problem.
This error occurs when Adaptive 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 Adaptive Server tries to delete the row specified by the error message.
During database recovery. Database recovery occurs:
During Adaptive Server start-up
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 Adaptive 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.
Use the procedure in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to identify which table and index correspond to the page number from the error message text.
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 Encyclopedia of Tasks chapter 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.
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
To ensure that the information needed to re-create the index is available, 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.
Run dbcc checktable on the table to verify that the corruption is gone.
If the index ID is 255, delete the bad data row.
If the index ID is 0, do one of the following:
Restore the database from clean backups.
Refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
WARNING! Some data might be lost on this page if you recover your table using bcp or select into (that is, the corrupted row and rows following it might be truncated and contain the wrong keys). Compare the two tables (old and new) row by row (by joining them on a primary key, for example) to determine which rows are different (corrupted).
Before dumping your database, make sure it works correctly. Run the following commands prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about how to run these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)
When this error occurs during recovery, the database is marked suspect and is not accessible. Usually, you must load the database from backup. To do this, follow the instructions below:
Drop the database. If the drop fails, follow the instructions in “How to Drop a Database When drop database Fails” in the Encyclopedia of Tasks chapter.
Create a database for load. Make sure the database you create has sizes as least as large as those in sysusages for the original database (and that all other sysusages values match the original values). Refer to “create database” in the Reference Manual for more information on create database for load.
Load the database from backup. (Refer to “load database” in the Reference Manual.)
Use the online database command to make the database available for use.
If loading from backups is not feasible, call Sybase Technical Support. Have the following documentation ready:
Adaptive Server error log
Text of all error messages
select * from master..sysusages output
One of the following items may help to prevent Error 631 from occurring on recovery:
Use shutdown to shut down Adaptive Server instead of shutdown with nowait after a period of heavy update activity in your databases.
Or:
checkpoint each database that is being used before shutting down Adaptive Server.
Examine both your operating system error log and the Adaptive Server error log to determine if hardware errors may have affected your database devices. Look for any kernel messages reporting I/O errors and check the hardware error log or diagnostics utilities for I/O errors.
Refer to “Developing a Backup and Recovery Plan” in the System Administration Guide for complete information about how to safely create, dump, load, and re-create databases.
All versions
21
Index row entry for data row id (%ld, %d) is missing from index page %ld of index id %d of table '%S_OBJID' in database '%S_DBID'. Xactid is (% ld,%d). Drop and re-create the index.
This error may be caused by a hardware problem.
This error occurs when the nonclustered index indicated by “index id” is corrupt. This corruption is detected when a process tries to delete a nonexistent row.
To recover from this error, use the following steps to drop and re-create the index.
Record the value of “index page” and “ index id” specified in the 644 error text. Then follow the instructions in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to identify which table and index correspond to the index page number. Also note the object ID.
If the object with the error is a system table (its object ID is less than 100), refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index. Then go to step 4.
If the object ID is greater than 100, drop and re-create the index, using the table name and the index name obtained in step 1. This clears the corruption in most cases.
To verify that all problems have been resolved on this table, run dbcc checktable and dbcc tablealloc on the affected table.
If problems persist, this procedure may not be sufficient to clean up the index corruption, and you should contact Sybase Technical Support. Have the following information ready:
Server version and SWR version level
Server error log
Output of dbcc tablealloc and dbcc checktable
Text of all error messages
All versions
20
Invalid Buffer Cache Access: Could not open object '%ld' in database '%d'
This error is raised when Adaptive Server is unable to locate and read an object into a data cache. The error occurs in the following situations:
When dbcc checkalloc finds that an allocation structure or extent belongs to a non-existent object.
The error does not prevent you from continuing other operations. However, each occurrence of this error represents a loss of up to eight pages on disk, or 16K. The pages cannot be used until the error is corrected.
When the configuration parameter sort page count is set to a very high value, and a stack overflow occurs during subsequent operations.
If the error is raised by dbcc checkalloc, it is due to an Adaptive Server problem. contact Sybase Technical Support for assistance.
If the configuration parameter sort page count is set to a very high value, try using a smaller value for this parameter.
All versions
20
Encountered invalid logical page '%ld' while accessing object '%ld' in database '%d'. This is an internal system error. Please contact Sybase Technical Support.
These errors may be due to hardware problems.
This error occurs when Adaptive Server tries to access an object but requests an invalid page number. There are two possibilities:
A negative page number is requested.
Page number 0 is requested. To be more specific, a request is issued for page 0, which is an allocation page, as if it was a data page. Data pages do not use page ID 0. Corrupt page linkages or incorrect entries for the object in sysindexes can cause the server to request page 0.
Error 691 results in a stack trace and breaks your connection to Adaptive Server.
Take the following steps:
Check the server error log for other errors that may have been raised prior to the 691 error. Save the entire error log.
Identify the object named in the error message using the following isql commands:
1> use <database name> 2> go 1> select name from sysobjects where id=<object id> 2> go
To determine the full extent of the corruption, run dbcc checkstorage, the dbcc checkdb and dbcc checkalloc commands, or dbcc checktable and dbcc tablealloc) as soon as possible.
To check if this error is a result of hardware failure, examine your operating system error log and correct hardware problems.
If the 691 error is not a soft error (one that exists only in memory), the problem is severe. Sybase Technical Support may be able to help you recover from the error. However this recovery procedure often results in loss of data; if this is unacceptable, you will probably need to restore from backups.
Refer to the writeup for Error 605 in this chapter for a discussion of potential causes of hardware error.
Have the following information ready before calling Sybase Technical Support:
Adaptive Server version and SWR version level
Server error log
Operating System error log
Output of the dbcc checks from Step 3 above.
All versions
20
Uninitialized logical page '%ld' was read while accessing object '%ld' in database '%d'. Please contact Sybase Technical Support.
These errors may be due to hardware problems.
Error 692 occurs when Adaptive Server tries to read a page that is not formatted (initialized) or is improperly formatted. The server retries the read if the first read attempt failed, and raises the 692 error if the second read attempt also fails.
Error 692 results in a stack trace and breaks your connection to Adaptive Server.
Take the following steps:
Check the server error log for other errors that may have been raised prior to the 692 error. Save the entire error log.
Obtain page information by running dbcc page as soon as possible, using the database ID and page number shown in the message:
1> dbcc page (<db_id>, <page_number>, 0, 1, 1, -1) 2> go
WARNING! Use the dbcc page command only as directed above.
Identify the object named in the error message using the following isql commands:
1> use <database name> 2> go 1> select name from sysobjects where id=<object_id> 2> go
Find information about this object in sysindexes:
1> select first, root, doampg, ioampg from sysindexes 2> where name = object_name(<object_id>) 3> go
To determine the full extent of the corruption, run dbcc checkstorage, the dbcc checkdb and dbcc checkalloc commands, or dbcc checktable and dbcc tablealloc) as soon as possible.
To check if this error is a result of hardware failure, examine your operating system error log and correct hardware problems. See “Checking the Operating System Error Log” in the Encyclopedia of Tasks chapter for assistance.
If the 692 error is not a soft error (one that exists only in memory), the problem is severe. Sybase Technical Support may be able to help you recover from the error. However, this recovery procedure often results in loss of data; if this is unacceptable, you will probably need to restore from backups.
Refer to the Error 605 writeup for a discussion of potential causes of hardware error. Refer to “Useful dbcc Commands” in the Encyclopedia of Tasks chapter for more dbcc information.
Have the following information ready before calling Sybase Technical Support:
Adaptive Server version and SWR version level
Server error log
Operating System error log
Output of the sysindexes query and dbcc checks from Steps 2, 4, and 5 above.
A database dump and transaction log dumps may also be required.
All versions
20
Multiple copies of logical page '%ld' from database '%d' reside in more than one cache. This is an internal system error. Please contact Sybase Technical Support.
This error occurs when Adaptive Server tries to access an object but is unable to establish the identity of a logical page for the object. Copies of the page are found in more than one cache, and the current session is accessing the wrong version.
Error 693 is caused by an Adaptive Server problem. It results in a stack trace and breaks your connection to Adaptive Server.
Check the server error log for other errors that may have been raised prior to the 693 error. Save the entire error log.
Obtain cache information by running dbcc page as soon as possible, using the database ID and page number shown in the message:
1> dbcc page (<db_id>, <page_number>, 0, 1, 1, -1) 2> go
WARNING! Use the dbcc page command only as directed above.
Contact Sybase Technical Support with the information you collected.
Refer to Error 605 for a complete list of related object mismatch errors.
Have the following information ready before calling Sybase Technical Support:
Adaptive Server version and SWR version level
Server error log
Operating System error log
Output of dbcc page.
All versions
24
An attempt was made to read logical page '%ld', virtpage '%ld' from virtual device '%d' for object '%ld' in database '%d'. The page was not read successfully. You may have a device problem or an operating system problem.
These errors may be due to hardware problems.
This error occurs when Adaptive Server tries to access an object but is unable to read the page mentioned in the message. Adaptive Server automatically issues a second read request to verify the consistency of the first read attempt. One of the following cases will be true:
The second I/O request did not take place either, and the page header is unchanged by the I/O operation. Adaptive Server writes the following message into the error log:
I/O did not occur, buffer contents are unchanged. Previous page in buffer = %ld Previous objid = %ld
The second read request returned new information, but that information was incorrect. This indicates an unreliable disk or controller.
The second read request was successful. The first read request may have failed due to a timing or caching problem on the device.
In all cases, Adaptive Server writes the following message into the error log:
Suspect a Device or OS problem, %s
and raises Error 694, resulting in a stack trace and breaking your connection to Adaptive Server.
This error indicates hardware or operating system problems.
Save the entire Adaptive Server error log from the last boot to the time of the error.
If the second read was successful, check whether dbcc checkalloc or dbcc checkdb is running concurrently with other activities on the server. Error 694 may occur when too many I/O's are requested from the server.
If the second I/O attempt failed or if it returned a bad read, check if the device in question provides a caching mechanism. If so, turn off caching to see if this resolves the 694 error.
If the error persists, determine what device(s) are responsible for the errors. Examine your operating system error log and correct hardware problems. See “Checking the Operating System Error Log” in the Encyclopedia of Tasks chapter for assistance.
Refer to the writeup for Error 605 for a discussion of potential causes of hardware error.
All versions
20
An attempt was made to read logical page '%ld' for object '%ld' in database '%d' from cache '%.*s'. Wrong logical page '%ld' was brought into cache.
These errors may be due to hardware problems.
Error 695 occurs when Adaptive Server tries to read a page from disk (the first logical page in the message), but the page number in the header of the returned page does not match the requested page. This means that the page is corrupt on disk, and has been overwritten by another page. The error may be due to an Adaptive Server problem but could also be caused by problems such as overlapping partitions or hardware errors.
Error 695 results in a stack trace and breaks your connection to Adaptive Server. Additional errors may be reported on the console and in the server error log prior to this error.
Check the server error log for other errors that may have been raised prior to the 695 error. Save the entire error log.
Obtain page information by running dbcc page as soon as possible, using the database ID and page number shown in the message:
1> dbcc page (<db_id>, <page_number>, 0, 1, 1, -1) 2> go
WARNING! Use the dbcc page command only as directed above.
To determine the scope of the problem, locate the device on which the database resides, and check if any other databases use the same device. Refer to “How to Determine Which Physical Devices a Database is On” in the Encyclopedia of Tasks chapter.
Check that the device is partitioned correctly. See “Correct Use of Raw Partitions” in the Encyclopedia of Tasks chapter .
Run dbcc log to find the history of transactions against this page.
1> dbcc log (<dbid>, 0, <page_no>, 0, 0, -1) 2> go
WARNING! Use the dbcc log command only as directed above.
To determine the full extent of the corruption, run dbcc checkstorage, the dbcc checkdb and dbcc checkalloc commands, or dbcc checktable and dbcc tablealloc) as soon as possible.
To check if this error is a result of hardware failure, examine your operating system error log and correct hardware problems. See “Checking the Operating System Error Log” in the Encyclopedia of Tasks chapter for assistance. Also see Error 605 for a discussion of potential causes of hardware error.
Sybase Technical Support may be able to help you recover from the error. However this recovery procedure often results in loss of data; if this is unacceptable, you will probably need to restore from backups.
See “Useful dbcc Commands” in the Encyclopedia of Tasks chapter for more dbcc information.
Have the following information ready before calling Sybase Technical Support:
Adaptive Server version and SWR version level
Server error log
Operating System error log
Output of the dbcc checks from Steps 2, 5, and 6 above.
All versions
21
An attempt was made to fetch logical page '%ld' in tempdb from cache '%.*s'. Page belongs to object '%ld' and not to object '%ld'. Restart of SQL Server will clear the error. Please contact your System Administrator for help.
This error occurs when Adaptive Server discovers page allocation corruption. Adaptive Server tries to access a particular object but discovers a page in the object's page chain whose object ID is different than that of the object being accessed.
This error is similar to the 605 error. However, Error 696 always occurs in the context of the tempdb database. Since the object ID mismatch is detected in cache, this is a transient (soft) error.
Shut down and restart Adaptive Server to clear the cache problem. If Error 696 occurs again, call Sybase Technical Support.
Have the following information ready before calling Sybase Technical Support:
Adaptive Server version and SWR version level
Text of all error messages
Text of the query which raises the error.
All versions
20
An attempt was made to fetch logical page '%ld' for object '%ld' in database '%d' from cache '%.*s'. Wrong logical page '%ld' was found in cache.
These errors can be due to hardware problems.
This error occurs when Adaptive Server tries to access an object in cache but arrives at an invalid page. The page number is correct on disk, but it does not match the page number of the page in memory.
Error 697 results in a stack trace and breaks your connection to Adaptive Server.
Since the problem occurs in cache, it is a soft error. Shut down and restart Adaptive Server to clear the memory corruption.
All versions
