This section contains error messages for Adaptive Server database recovery. Database recovery occurs during Adaptive Server start-up, load database, and load transaction.
21
Rec_logbounds: getnext SCAN_RID of last checkpoint failed on Rid from sysdatabases. %S_RID.
When you restart Adaptive Server, recovery scans the log to find the last checkpoint record to determine the active portion of the log. Error 3401 is raised when recovery is unable to find a checkpoint record.
Error 3401 occurs with the following states:
State |
Meaning |
1 |
An attempt to start a log scan failed. |
2 |
A log scan was started, but an attempt to find a checkpoint record in the log failed. |
If you have a good backup, restore the database as follows:
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 the values in sysusages for the original database (and that all other sysusages values match the original values). For more information about creating a database for load, refer to create database in the Adaptive Server Reference Manual.
Load the database from backup. (Refer to load database in the Adaptive Server Reference Manual.)
Use the online database command to make the database available for use.
If you do not have a good backup, contact Sybase Technical Support. They may be able to help you recover from this error.
Have the following information ready when you call Sybase Technical Support:
Server version and SWR rollup level
Text of all error messages.
All versions
22
During recovery initialization, page %ld was encountered. This page belongs to object %ld, not the log.
This error may be caused by a hardware problem.
During recovery, Adaptive Server scans the transaction log until the last page is found. During this scan, if a page is found that is allocated to syslogs but the object ID on the page header is not the same as that of syslogs, Error 3403 occurs.
Situations that may cause this error include the following:
A bad page allocation or write occurred due to an Adaptive Server problem.
Adaptive Server went down after the allocation page was updated but before the transaction log page was written. The database was later rebuilt without the transaction log pages being cleared and entries from the old log still exist.
This is a serious error and you will have to rebuild the affected database either using bcp or from clean backups.
If you have a good backup, restore the database from your backup:
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). For more information about creating a database for load, refer to “create database” in the Adaptive Server Reference Manual.
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 you do not have a good backup, copy the data from the corrupted table into a new (dummy) table or into a file. Then rename your old, corrupted table and copy the data back into a new table using the original name. For information about doing this, refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
To prevent some occurrences of this error in the future, checkpoint each database that is being used before shutting down Adaptive Server.
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
Rec_complete: Could not open controlling database (id %d) of controlling database in multi-db transaction.
The Adaptive Server transaction log records all changes in the database. When database activity occurs in the context of a transaction, BEGINXACT and ENDXACT records are written in the transaction log to mark the transaction boundary. If the transaction spans databases, it is known as a multi-database transaction; the database where the transaction was started (in the case of explicit transactions, the database where the first begin transaction was issued) is referred to as the controlling database.
When Adaptive Server is brought back up after a shutdown, the recovery process uses the transaction log to bring all the databases to a consistent state. Error 3404 is raised when Adaptive Server attempts to recover a multi-database transaction, but is unable to open the controlling database for the transaction.
Specifically, Error 3404 results when Adaptive Server is attempting to recover a transaction that started in a user database but modified data in master database. When this happens, Adaptive Server is unable to access the transaction log for the user database since the device on which the log resides is not yet open. Consequently master cannot be recovered. This error is frequently accompanied by Errors 913 and 3414.
Use one of these options to correct this problem:
Restore the database specified in Error 3404 from a clean backup.
Contact Sybase Technical Support. They may be able to help you re-create the database in question.
To avoid a recurrence of this error, do not start transactions in user databases that modify tables in master.
Before calling Technical Support, have the following information available:
Server release and SWR Rollup level
Server error log
Text of all error messages
All versions
10
Database '%.*s' (dbid %d): Recovery failed. Check the SQL Server errorlog for further information as to the cause.
This error occurs during startup when Adaptive Server could not complete the recovery of the database listed in the error message.
You cannot use the database until whatever caused the error has been corrected because Adaptive Server marks the database suspect.
Error 926 is a related error which is raised when attempting to access a database that could not recover. Refer to the writeup for Error 926.
To determine why recovery failed, examine the Adaptive Server error log for any errors prior to the 3414 error. It is important to identify the errors before the first occurrence of the 3414 error because subsequent attempts to start Adaptive Server may not give the detailed error information you need to diagnose the problem.
If you do not have sufficient information to recover from the previous errors, you can recover from known, clean backups or contact Sybase Technical Support for assistance.
All versions
21
Not enough deses to open '%.*s'.
This error occurs during startup when Adaptive Server could not complete recovery of the system database listed in the error message.
Error 3418 is called for the following system databases which existed in sysdatabases prior to starting recovery:
model
sybsecurity
sybsystemprocs
Possible reasons for Error 3418 include:
During database recovery, Adaptive Server failed to find the corresponding row in sysdatabases (State 1 or State 3 is returned with the 3418 error).
Adaptive Server was unable to open a database for recovery (State 2 is returned with the 3418 error).
When Error 3418 occurs, Adaptive Server shuts down automatically. Since the affected databases are required for Adaptive Server to start successfully, manual intervention is required to start Adaptive Server when this error occurs.
To determine why recovery failed, examine the Adaptive Server error log.
Contact Sybase Technical Support for assistance with the manual intervention required to start Adaptive Server and recover from this error.
All versions
21
Transaction (%ld, %d) not found in transaction table.
This error may be caused by a hardware problem.
This error occurs during recovery when 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 Adaptive Server marks the database suspect.
If the error occurred during start-up (rather than during load database or load transaction), determine which database had the error by looking at your Adaptive 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.
If you need assistance from Sybase Technical Support, have the following information available when you call:
Server release and SWR Rollup level
Server error log
Text of all error messages
All versions
21
Error recovering database '%.*s' - could not connect to commit service to check completion status of xact: %S_RID.
The two-phase commit service allows an application to coordinate updates within a Server or among two or more Adaptive Servers. The commit service uses one Adaptive Server, the commit server, as a central recordkeeper that helps the application determine whether to commit or roll back transactions in case of failure.
During database recovery, each outstanding transaction is handled in one of the following ways:
If the transaction committed, it is redone.
If the transaction aborted or failed to complete, it is rolled back.
If the transaction reached the prepare-to-commit stage of the two-phase commit, Adaptive Server must find out whether the controlling transaction committed. If the controlling transaction is at the same site, Adaptive Server can directly examine the log. But if the transaction was handled by the commit service, Adaptive Server must query the commit service to find out whether the controlling transaction has been committed.
Adaptive Server queries the commit service using the probe utility. As a standard client, probe requires the following:
A valid interface must exist for the commit server.
The commit service must be running and not in single-user mode.
The probe version must be the same as the Adaptive Server version.
In version 11.0.x, the probe binary must exist in the $SYBASE/bin directory. (Not required in versions 11.5 and higher.)
Error 3429 occurs when Adaptive Server uses probe to query the commit service to find out whether the controlling transaction committed, and probe cannot connect to the commit service because the connection is refused or times out.
After Error 3429 occurs, Error 3414 is raised and the database status is set to “suspect.”
Solve the problem that is preventing probe from connecting to the commit service. Make sure that the commit service Adaptive Server is running. If it is hung or otherwise inaccessible, shut down and restart the commit service Adaptive Server.
For the affected database, execute one of the procedures supplied in “How to Reset a Database's “suspect” Status” in the Encyclopedia of Tasks chapter.
Shut down and restart Adaptive Server to recover the database.
Refer to the Open Client DB-Library/C Reference Manual for information about the two-phase commit service.
All versions
20
Cannot change sortorder. Server shutting down. Restart to continue with sortorder unchanged.
When you restart a server after changing the server’s sort order, the recovery process must rebuild system tables in both master database and user databases, and rebuild indexes that are affected by the sort order change. Error 3434 occurs when recovery is unable to recreate a system index or table following the sort order change.
The error can be raised:
When you change from a case-sensitive sort order to a case-insensitive sort order, and conflicts arise between key values that are differentiated only by case. For example, key values ’Joe’ and ’joe’ will cause a conflict when rebuilding the index with a case-insensitive sort order.
Error 3436 (“Cannot rebuild index %d for the ’%.*s’ table in the ’%.*s’ database.”) precedes Error 3434 in this situation.
When one or more databases for load exist in the server. You cannot change sort order when the server contains a database that was created for load.
Error 3434 rolls back the transaction in progress, reverts to the original sort order, and shuts down the server.
Check the error log to obtain more information about the error. Actions depend on the likely cause of the error:
If the error is related to key value conflicts, determine the table and index from the 3436 error message, and check for ’duplicate key’ messages in the error log. Correct the reported conflict and retry the sort order change.
If the server contains a database created for loading a dump (for load database), take the following steps to correct the problem:
Drop the for-load database(s).
Manually change the sort order on the server. See “How to Manually Change Sort Order or Default Character Set” in the Encyclopedia of Tasks chapter for details.
Restart the server.
After changing the sort order, refer to "If You Changed the Sort Order or Default Character Set" in the System Administration Guide and do the steps described there. It is very important that you do these steps to guarantee the integrity of your data.
You can achieve similar results without changing the sort order to case insensitive by using the upper or lower functions in your queries. For example, if tableX has col1 with values "sybase", "Sybase", and "SYBASE", you could run the following isql statement:
select cols from tableX where lower(col1) = "sybase"
This treats all of the values as lowercase for the query.
In many cases, you cannot reload your data from a database dump after reconfiguring the sort order. Refer to "Database Dumps and Configuration Changes" in the System Administration Guide for details.
All versions
10
SQL Server could not bring database '%.*s' online.
This error occurs when Adaptive Server cannot bring a database online for one of the following reasons:
An attempt to update the database log version fails. Adaptive Server tries to update the log version if it is earlier than the current Adaptive Server log version.
Adaptive Server failed to clear the offline status bit after an upgrade.
Look at the error messages that precede the 3445 message to determine why the 3445 error occurred, and resolve those problems.
If you cannot solve the problem:
Determine the current log version for the database. For example, to determine the log version of a database called test_db, use the following commands:
1> load database test_db from 'test.dump' with headeronly 2> go
Backup Server session id is: 6. Use this value when executing the `sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server.
Backup Server: 6.28.1.1: Dumpfile name `test_db952820A2F8' section number 0001 mounted on disk file `/remote/solaris/rel1100/install/test.dump'
This is a database dump of database ID 6, name `test_db', from Oct 9 1995 11:35AM. SQL Server version: SQL Server/11.0/B/Sun_svr4/OS5.2/1/OPT/Fri Aug 1805:10:26 PDT 1995. Backup Server version: Backup Server/11.0/B/Sun_svr4/OS5.4/1/OPT/Thu Aug 17 21:54:21 PDT 1995.
Database contains 1536 pages; checkpoint RID=(Rid pageid = 0x405; row num = 0xd); next objectID=3031; sort order ID=50, status=0; charset ID=1. Database log version=2; database upgrade version=1.
Call Sybase Technical Support. Have the following information ready:
Server version and SWR Rollup level
Server error log
Text of all error messages
Output from step 1.
All versions
16
You do not have privilege to bring database '%.*s' online.
The online database command marks a database available for public use after a normal load sequence and, if needed, upgrades a loaded user database and transaction log dumps to the current version of Adaptive Server.
Only a System Administrator, Database Owner, or Operator can execute online database. Error 3446 occurs when you do not have any of these privileges and you attempt to execute an online database command.
Make sure you have the needed privileges or ask a user who does have the needed privileges to run the online database command.
Refer to the Reference Manual for information about online database.
Refer to the Security Administration Guide for information about using the “sa” account and roles in Adaptive Server.
Refer to “grant” in the Adaptive Server Reference Manual for information about granting roles.
All versions
10
Database `%.*s' appears to be in the process of being loaded; SQL Server will not bring it online automatically. Use the ONLINE DATABASE command to bring this database online.
During a load database, Adaptive Server takes the database being loaded offline. When the load is complete, you bring the database back online manually with the online database command. If your backup strategy involves loading a sequence of transaction logs after a load database, the fact that the database will be unavailable for use until you enter the online database command will allow you to complete your loads without interference from other processes changing that database.
Error 3447 occurs during the recovery phase of Adaptive Server start-up, when the recovery process attempts to bring all the recovered databases online automatically and Adaptive Server sees that the database named in the error message is being loaded.
This error does not occur for master, as Adaptive Server always brings master online.
Finish the load database sequence and then use online database to make the database available for use.
Refer to the Reference Manual for information about online database.
All versions
20
Database '%.*s': upgrade item %d depends on item %d, which could not be installed. Please refer to previous messages for the cause of the failure, correct the problem and try again.
Databases can be upgraded during an online database command or when you are using the sybinit upgrade utility. Many upgrade steps depend on other upgrade steps having been done previously.
Error 3452 occurs when the first upgrade step shown in the message depended on the second reported step, and that second step has failed. The database upgrade does not complete when this error occurs.
You will not be able to bring the database named in the error message online until you resolve the problem that led to the 3452 error.
Find the previous message describing the failure of the dependent (second) step.
Fix the problem that caused the failure. If appropriate, follow the directions for a failed upgrade in the Adaptive Server installation and configuration guide.
If you were running online database when Error 3452 occurred, issue the online database command to restart the database upgrade.
All versions
10
Database '%.*s': SQL Server could not completely upgrade this database; upgrade item %d could not be installed.
Databases can be upgraded during an online database command or when you are using the sybinit upgrade utility. Error 3454 is an informational message telling you that Adaptive Server could not completely upgrade the database listed in the message. The 3454 error is preceded by other errors that show why the upgrade failed.
You cannot bring the database named in the error message online until you resolve the problem that led to the 3454 error.
In the following example, these messages appeared during start-up, when Adaptive Server attempted to bring a database online but failed to upgrade it:
00:95/11/21 18:34:36.51 server Database 'test' appears to be at an older revision than the present installation; SQL Server will assess it, and upgrade it as required. 00:95/11/21 18:34:36.59 server Error: 1105, Severity: 17, State: 1 00:95/11/21 18:34:36.61 server Can't allocate space for object 'sysattributes' in database 'test' because the 'system' segment is full. If you ran out of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE or sp_extendsegment to increase the size of the segment. 00:95/11/21 18:34:36.63 server Error: 3460, Severity: 20, State: 1 00:95/11/21 18:34:36.65 server Database 'test': upgrade could not record the installation of upgrade item '80'. Please refer to previous error messages to determine the problem. Fix the problem, then try again. 00:95/11/21 18:34:36.68 server Error: 3451, Severity: 20, State: 1 00:95/11/21 18:34:36.70 server Database 'test': upgrade has failed for this database. Please refer to previous messages for the cause of the failure, correct the problem and try again.
00:95/11/21 18:34:36.73 server Error: 3454, Severity: 20, State: 1 00:95/11/21 18:34:36.75 server Database 'test': SQL Server could not completely upgrade this database; upgrade item 80 could not be installed. 00:95/11/21 18:34:36.76 server SQL Server could not bring database 'test' online.
Look at the error messages preceding the 3454 error message to determine what happened.
Refer to the recovery steps suggested for those errors.
Correct the problem.
If the error occurred when you were running online database, issue the online database command for that database after the problem is fixed. Adaptive Server will automatically try to finish the upgrade.
If the error occurred during an Adaptive Server upgrade, follow the recovery directions in the Adaptive Server installation and configuration guide.
All versions
10
SQL Server could not completely upgrade database '%.*s', but the database was online when upgrade began, so it will be left online.
When Adaptive Server tries to bring an already online database to the online state and it finds that some elements of the database have not been upgraded, it tries to complete the database upgrade. Error 3470 occurs when that attempt to upgrade the database fails.
Determine the current upgrade version for the database. For example, to determine the upgrade version of a database called test_db, use the following commands:
1> load database test_db from 'test.dump' with headeronly 2> go
Backup Server session id is: 6. Use this value when executing the `sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server.
Backup Server: 6.28.1.1: Dumpfile name `test_db952820A2F8' section number 0001 mounted on disk file `/remote/solaris/rel1100/install/test.dump'
This is a database dump of database ID 6, name `test_db', from Oct 9 1995 11:35AM. SQL Server version: SQL Server/11.0/B/Sun_svr4/OS5.2/1/OPT/Fri Aug 1805:10:26 PDT 1995. Backup Server version: Backup Server/11.0/B/Sun_svr4/OS5.4/1/OPT/Thu Aug 17 21:54:21 PDT 1995.
Database contains 1536 pages; checkpoint RID=(Rid pageid = 0x405; row num = 0xd); next object ID=3031; sort order ID=50, status=0; charset ID=1. Database log version=2; database upgrade version=1.
Call Sybase Technical Support. Have the following information ready:
Server version and SWR Rollup level
Server error log
Text of all error messages
Output from step 1
Output from sp_configure "upgrade version".
All versions
