This section contains error messages for Adaptive Server transaction processing.
21
Can't unsplit logical page %ld in object '%S_OBJID' in database '%S_DBID' - both pages together contain more data than will fit on one page.
Data and index pages are split when Adaptive Server determines that a row cannot be inserted due to insufficient room on the existing page. During transaction rollback (either by a user request or during database recovery), Adaptive Server tries to undo the changes done by the transaction. Error 3904 occurs when Adaptive Server fails to unsplit pages which were split during the transaction.
Error 3904 is caused by an Adaptive Server problem.
When this error occurs, data integrity may have been compromised.
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 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 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 object with the error is a system table and 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 from clean backups.
For a user table, if the index ID is not 0, run the sp_helpindex procedure on the index to get information for rebuilding it.
Drop the index.
Re-create the index. This clears the corruption in most cases.
Run dbcc checktable on the table to verify data integrity. If errors occur, call Sybase Technical Support.
For a user table, if the index ID is 0, run dbcc checktable on the table to verify data integrity. If errors occur, restore the database from clean backups.
Refer to drop index and create index in the Reference Manual for information about dropping and re-creating indexes.
Refer to “Developing a Backup and Recovery Plan” in the System Administration Guide for information about how to safely create, dump, load, and re-create databases
All versions
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 accomodate 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 which 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, thus failing to unsplit pages which 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 system table (a system table name starts with ’sys’ and the object ID is less than 100), call Technical Support. They may be able to help you repair the corruption, but it may be necessary to restore from clean backups.
If the object is a user table, continue with Step 2.
Use sp_help(<table_name>) to determine the table’s lock scheme: allpages-locked (APL) table or data-only-locked (DOL) table.
Identify the row(s) corresponding to the affected page using:
dbcc page(<dbid>, <page_num>, 1)
where dbid and page_num are the database ID and page number 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 back in. This is the most efficient solution for a very large table. Omit the affected rows from Step 3 when copying in.
Run dbcc checktable to check the new table.
Avoid using named caches or large I/O buffer pools until the problem is resolved.
Have the following information ready when you call Sybase Technical Support:
Adaptive Server version and SWR rollup level.
Server error log.
All versions
16
Attempt to BEGIN TRANsaction in database ’%.*s’ failed because database is READ ONLY.
Error 3906 is raised when a transaction, explicit or implicit, is attempted while the database is in read-only mode.
Error 3906 is raised with the following states:
State |
Meaning |
|---|---|
1 |
Attempted to start a transaction when the database is in read-only mode. Applies to all possible transaction types. |
2 |
Attempted to start a subordinate transaction (child transaction started by a parent transaction in a parallel setting) when the database is in read-only mode. |
Error 3906 can be raised in two distinct cases, described below.
A user may have attempted to start a transaction while the database is in read-only mode. This is not allowed.
The error may occur when a view or procedure must be resolved in a read-only database. Re-resolution must update the sysprocedures table, but since the database is read-only, Error 3906 is raised. This scenario can occur during a load into a read-only database, when views and procedures must be re-resolved.
Corrective action depends on the scenario in which Error 3906 was raised, as described in the above cases.
Re-try the transaction when the database is no longer read-only.
If Error 3906 was raised when you attempted to select from a view or execute a stored procedure, you can correct the problem by making the database temporarily available for writes and re-compiling objects. Keep in mind, however, that if the database is used as a warm standby, this activity will create additional records in the log, which will invalidate the database as a warm standby.
To re-resolve compiled objects in the database:
Put the database in read-write mode.
1> sp_dboption <database_name>, "read only", false 2> go
Execute all compiled objects such as stored procedures and views once.
Return the database to read-only mode.
1> sp_dboption <database_name>, "read only", true 2> go
Starting with Version 11.9.x, which introduced the standby access mode to allow access to the database during load sequences, you can run alter database while in standby access. However since transactions cannot be started in this mode, you must re-establish the LCT after the database is fully online following the completion of the load sequence. Follow the steps in Case 2 above.
All versions
16
Attempt to BEGIN TRANsaction in database ’%.*s’ failed because database is in BYPASS RECOVERY mode.
Adaptive Server can start various types of transactions such as local (in response to a local command), internal (for the server’s own use), external (started by an external client like a TP Monitor) and subordinate (child transactions started by a parent transaction in parallel).
Bypass recovery starts Adaptive Server without recovering one or more databases. A database in this mode can be accessed even though it is not recovered. You use this mode to allow access to the database for problem analysis, to copy out data, and so on.
Error 3908 is raised when a transaction is attempted while the database is in bypass recovery. Although certain commands are permissible in this mode, no transactions - regardless of type - can be started when the database is in bypass recovery.
Error 3908 is raised with the following states:
State |
Meaning |
|---|---|
1 |
Attempted to start a transaction when the database is not available for update. Applies to all possible transaction types. |
2 |
Attempted to start a subordinate transaction when the database is not available for update. |
Do not attempt to start a transaction while the database is in bypass recovery. Check if any automated jobs may have submitted a batch job that attempted such a transaction. First restore the database to the original working status it had (prior to bypass status) before attempting any transactions.
Use the following steps to reset the database status:
Although a status of zero is usually appropriate, it
is not the only possible status value you can use. Reset the database
to the actual, normal status it had prior to entering bypass recovery
status.
Reset the database status to 0:
1> sp_configure "allow updates", 1 2> go 1> begin tran 2> go 1> use master 2> go 1> update sysdatabases set status=0 2> where name=<database_name> 3> go
Check that the above update command affected only one row (if more than one row was affected, issue a rollback transaction.) Then commit the transaction and shut down Adaptive Server as follows:
1> commit tran 2> go 1> shutdown with nowait 2> go
Restart Adaptive Server. Run dbcc checkdb and dbcc checkalloc on the affected database to make sure there are no errors.
All versions
16
An attempt was made to startup a multi-database update in database ’%S_DBID’ after starting up the master transaction in tempdb. This could render the database ’%S_DBID’ unrecoverable and this update is therefore not allowed.
Error 3917 is raised when you initiate a transaction in tempdb and the transaction attempts to update one or more tables in another database. For example:
1> use tempdb 2> go 1> begin tran 2> go 1> update geo..nation 2> set n_comment="This is a grade V earthquake zone" 3> where n_nationkey = 4 4> go
Msg 3917, Level 16, State 1: Line 1: An attempt was made to startup a multi-database update in database ’geo’ after starting up the master transaction in tempdb. This could render the database ’geo’ unrecoverable and this update is therefore not allowed.
You cannot start update transactions in tempdb because tempdb is truncated upon recovery. If the transaction is left in a prepare state and it becomes necessary to restart the server, this will render the user database (the one being updated) unrecoverable.
3917 errors may also be seen when the tempdb transaction log gets filled up, and are accompanied by Error 1105 (Can’t allocate space for object ’%.*s’ in database ’%.*s’ because ’%.*s’ segment is full/has no free extents. If you ran out of space in syslogs, dump the transaction log. Otherwise, use alter database or sp_extendsegment to increase size of the segment.).
Check the ASE error log to help determine the circumstances in which the error is raised.
If Error 3917 was raised when you attempted a transaction containing an update or insert statement, it means that the transaction was incorrectly initiated from tempdb. Take one of the following steps, as applicable:
Add ’use <database_name>’ in the SQL script to change the database from tempdb to the database being updated, and retry the transaction; or
Change the default database for the user executing the transaction to the database where the insert is taking place.
If Error 1105 in tempdb accompanies the 3917 error, this is probably due to an Adaptive Server problem which prevents the checkpoint process from executing because the transaction log is filled up. Shut down and restart the server. Call Sybase Technical Support to upgrade to a version in which the problem is fixed.
Have the following information ready when you call Sybase Technical Support:
Adaptive Server version and SWR rollup level
Server error log
All versions
