This section contains error messages pertaining to Adaptive Server timestamps.
21
Overflow on High component of timestamp occurred in database %d. Database table possibly corrupt.
This error may be caused by a hardware problem.
Each database has one global timestamp which is kept in memory in a structure called a dbtable. The timestamp is not a date and time; rather, it is a sequence number (6 bytes, consisting of a high and low portion) which keeps track of modifications of pages within the database. Each time a page in the database is modified, the page gets the current timestamp and the global timestamp gets incremented. The global timestamp “travels” with a database through dumps, loads, and upgrades. Timestamps are critical during recovery, to ensure that transactions are properly rolled forward or rolled back. The global timestamp is also used for timestamp columns.
The maximum value for timestamps is very high (0xffff 0xffffffff), so it is very unlikely that under normal circumstances a database will reach this limit. However, use of some unsupported database maintenance commands can cause the global timestamp to reach the maximum value.
Each time dbtable is created for the database, Adaptive Server checks the timestamp value. Error 6901 is raised if the timestamp value exceeds the maximum.
Database dump/load is not an option to address this problem since that will not reset the timestamp value. The only way to recover from Error 6901 is to drop and re-create the database, using the following steps:
bcp out all table data.
defncopy out all procedures, rules, defaults and triggers.
Use the drop database command to drop the database.
Use the create database command to re-create the database.
Create all tables.
bcp in all table data.
Create indexes.
defncopy in all procedures, rules, defaults and triggers.
Check that the user IDs in sysusers in the restored database are consistent with master..syslogins. Mismatched user IDs in databases can lead to permission problems.
Scripts are recommended for reliable re-creation of
the database objects.
Refer to the glossary for additional information about timestamps and dbtable. Refer to “Developing a Backup and Recovery Plan” in the System Administration Guide for complete information about how to safely re-create databases.
All versions
21
Page timestamp value falls between the old and new timestamps from log. Page #=%ld, object id = %ld, page timestamp=%04x %08lx. Log: old timestamp=%04x %08lx, new timestamp=%04x %08lx.
This error may be caused by a hardware problem.
The objective of recovery algorithms in Adaptive Server is to bring all the databases to a consistent state: that is, each transaction is either completely applied to the database or no part of it is applied. (Database recovery occurs at Adaptive Server startup as well as when a load database or load transaction command is processed.)
Whenever a page is modified during run time, the page timestamp before the change and the page timestamp after the change are recorded in the log record for that modification. By comparing the timestamp on the page at recovery time with that of the timestamps in the log record, Adaptive Server can tell whether the page is in the state before or after the change was made to it.
Error 6902 occurs during Adaptive Server recovery if the timestamp of the page which is being recovered is neither the old log timestamp nor the new log timestamp. This is a fatal error and causes the recovery process to fail.
Error 6902 is probably a result of a more serious underlying error. Common causes of this error are:
Data corruption during normal processing
Abnormal shutdown of Adaptive Server during a transaction update
Hardware errors.
Recover your database from backups or call Sybase Technical Support.
To prevent this error from occurring in the future, use one of the following sections, depending on what caused the 6902 error.
shutdown with nowait or abnormal shutdown of Adaptive Server should be avoided, if possible, after a heavy update period in your databases:
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.
Check the Adaptive Server error log to determine whether there are other indications of hardware problems, such as kernel messages reporting I/O errors.
Check the operating system error log or diagnostics utilities for I/O errors.
Using dump transaction with no_log can, in some circumstances, result in a 6902 error, especially when used after a heavy update period. Therefore, do not use dump transaction with no_log unless your transaction log is 100 percent full. Try using dump transaction with truncate_only first and use the no_log option only as a last resort.
If you find that the no_log option is used periodically, you might not be performing database or transaction log dumps often enough, or you may not have enough space allocated to the database or transaction log. Check for any occurrences of dump transaction with no_log in any of your scripts or procedures and replace them with dump transaction with truncate_only. For more information about dump transaction with no_log, refer to “dump transaction” in the Reference Manual and ”Backing Up and Restoring User Databases” in the System Administration Guidefor details about the special dump transaction options.
WARNING! Use dump transaction with no_log only when there are no active users in the database.
All versions
