20
Logical page '%ld' in database '%S_DBID', cache '%.*s' is already hashed.
This error may be caused by a hardware problem.
This error may be serious, especially if it occurs on a table’s data page, which means that a page is currently in the data cache and is in use by a table or index but is not marked as allocated. An attempt to allocate it raises error 813.
The same page could be allocated again after it is removed from the data cache, resulting in a loss of whatever data resides on the page.
WARNING! Pages encountering error 813 will not be included in a database dump. This is because database dumps are performed by reading allocation pages and not by traversing page chains. Therefore, this error should be corrected before dumping the database.
After the page is removed from the data cache, further attempts to access this page may raise 2500 series errors (allocation errors) when running dbcc checkalloc, dbcc tablealloc, or dbcc indexalloc.
To clear the error:
Execute the checkpoint command on the database specified in the error message. This will cause modified pages in the data cache to be flushed to disk.
Run dbcc checkalloc or dbcc checkalloc with the fix option on the database. As a result, you might get allocation errors because the page displayed in the error message will be linked but not allocated. Refer to “dbcc” in Reference Manual: Commands for information about running these commands.
If you do get allocation errors:
Check your hardware error log or diagnostics utilities for I/O errors.
Check your operating system error log file and the Adaptive Server error log to determine if hardware errors may have caused the corruption. (Look for messages reporting I/O errors.)
Refer to the write-ups in this manual.
If you still have 813 errors after fixing any other errors reported during step 2, shut down and restart Adaptive Server. This will probably clear error 813.
If errors still occur, call Sybase Technical Support. They might be able to help you recover from this error if the corruption is not too widespread. However, recovery from backups might be necessary.
Using the dump transaction with no_log command can result in an 813 error. Therefore, do not use dump transaction with no_log unless it is absolutely necessary (when dump transaction with truncate_only will not truncate the log). Try using dump transaction with truncate_only first, then use the no_log option only as a last resort. Refer to “Error 1105” for details.
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 on this series of errors, refer to the information in this section and in “Fixing and preventing allocation errors” in the chapter “Other Useful Tasks” in the most recent version of Troubleshooting and Disaster Recovery.
All versions
