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, implement 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: Commands and “Backing Up and Restoring User Databases” in the Adaptive Server Enterprise configuration guide for your platform. Also refer to “Using the special dump transaction options” in the chapter “Developing a Backup and Recovery Plan” in the System Administration Guide: Volume 2.
WARNING! Use dump transaction with no_log only when there are no active users in the database.
All versions
