16
Versions earlier than 15.0:
%S_PAGE has an incorrect pgfreeoff value of %d. The offset should be %d.
Version 15.0 and later:
Page %S_PAGE, partition ID %d, has an incorrect 'pgfreeoff' value of %d. The offset should be %d.
The free byte offset on a page indicates the offset of the first unused byte on that page. Error 2596 occurs when dbcc checktable detects that the free byte offset on a page is incorrect.
WARNING! This is a serious error that indicates possible corruption on the affected page and can occur in conjunction with other errors, particularly error 2506.
If error 2596 occurs on a system table being processed by dbcc checktable, call Sybase Technical Support.
If the number of the free byte offset shown in the error message is lower than the expected number, some data has been lost. To determine how much data has been lost, find the difference (in bytes) between the actual free byte offset and the expected free byte offset (both numbers are shown in the error message output). The amount of data lost includes 2 bytes overhead per row where there are only fixed-length columns or 4+<n> bytes overhead per row with variable-length columns, where <n> is the number of variable-length columns. If you need help, call SybaseTechnical Support.
Decide whether you should restore the database that contains the affected table from backups. In making that decision, consider the number of rows lost and the number of other corruption errors that have occurred on this table and database.
If the free byte offset on the page header is higher than the expected value, no data has been lost. However, some extraneous rows may exist.
If you have clean backups of your database, recover from backups. If you do not have clean backups of your database, follow these steps to correct the error:
Use the procedure “Finding an object name from a page number” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery to identify the table and index correspond to the page number from the error message text.
WARNING! The procedure referenced in step 1 uses the dbcc page command. Use the dbcc page command only as directed. This command is undocumented, nonstandard, and is provided “as is” without any warranty. Sybase Technical Support does not support this command for general use. Although the command syntax is provided for reference, use this command only in the specific diagnostic situations described, and with the specific syntax shown. Failure to do so could cause performance problems and database corruption.
If the object with 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 “Fixing a corrupted system table index” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery for instructions on how to repair the system table index.
If the object with the error is a system table and the index ID is 0 (zero), contact Sybase Technical Support. They may be able to help you repair the corruption or it may be necessary to restore from clean backups.
If the object with the the error is a user table and if the index ID is 0 (zero) or 255, go to step 4.
If the index ID is not 0 (zero) 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 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 confirm that the corruption is gone.
If the index ID is 255, delete or update the data row to remove the reference to the bad text page.
If the index ID is 0 (zero), do one of the following:
Restore the database from clean backups.
or
Refer to “Rescuing data from a corrupted table” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery.
WARNING! Some data on the page can be lost if you recover the table using bcp or select into (that is, the corrupted row and rows following it can be truncated and contain the wrong keys). Compare the two tables (old and new) row-by-row (for example, by joining them on a primary key) to determine if any rows are different (corrupted).
Before dumping the database, confirm that it is working correctly by running the following commands prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “Fixing and preventing allocation errors” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery for information about running these commands in multi-user mode and how to prevent false allocation errors from dbcc commands.)
All versions
