21
Can’t unsplit logical page %ld in object ’%S_OBJID’ in database ’%S_DBID’ - row number %d is used on both pages.
When Adaptive Server determines that a row cannot be inserted due to insufficient room on the existing page, data and index pages are split to accommodate the insertion. If the transaction is rolled back (either by a user request or during database recovery), Adaptive Server tries to undo the changes done by the transaction. The undo steps include restoring the offset table that contains the location of rows on the page.
Error 3905 occurs when Adaptive Server is unable to restore the offset table on a data page, therefore failing to unsplit pages that were split during the transaction.
Error 3905 is due to an Adaptive Server problem and is sometimes seen when buffer pools larger than 2K are in use. When this error occurs, data integrity may have been compromised.
Use the steps described below to recreate the affected table, then call Sybase Technical Support for help in resolving the server problem:
If the object in question is a user table, go to step 2.
If the object is a system table (a system table name starts with “sys” and the object ID is less than 100), call Sybase Technical Support. They may be able to help you repair the corruption, but it may be necessary to restore from clean backups.
Use sp_help (<table_name>) to
determine the table’s lock scheme: all-pages-locked
(APL) table or data-only-locked (DOL) table.
Identify the rows that correspond to the affected page:
dbcc page(<dbid>, <page_num>, 1)
Where <dbid> and <page_num> are the database ID and page number shown in the error message respectively.
Use one of the following methods to recover from the problem:
Select the table data into a new table, drop the old table, and rename the new table to the old table name. Omit the affected rows from step 3 when selecting data from the old table.
For a DOL table, if there is an index on the table, force this index when copying data.
Bulk copy the affected table out, drop and re-create the table, and bulk copy the table back in. This is the most efficient solution for a very large table. Omit the affected rows from step 3 when copying the table back in.
Run dbcc checktable to check the new table.
Avoid using named caches or large I/O buffer pools until the problem is resolved.
When you call Sybase Technical Support, have the information ready that is listed in “Reporting errors”.
All versions
