10
WARNING - the timestamp in database '%.*s' is approaching the maximum allowed.
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 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 a higher than expected global timestamp value.
Each time dbtable is created for the database, Adaptive Server checks whether the timestamp value is approaching the maximum by comparing the current timestamp value with a threshold value defined by Adaptive Server. Error 935 is raised if the timestamp value exceeds this threshold.
Error 935 gives you advance warning about a serious impending problem.
WARNING! After error 935 is raised, only a few more transactions are possible in the database. If you do not address the problem, the timestamp value will reach the maximum and the database will no longer be usable.
A database dump and load is not an option to address this problem. When you receive error 935, re-create the database in question as soon as possible using these 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: Volume 2 for complete information about how to safely re-create databases.
All versions
