Hi Friends,
SQL Server 2005 users very frequently confronted with various types of assertion failures and one of such error is SQL Server Error 5242, shown as following;
Msg 5242, Level 22, State 1, Line 1
An inconsistency was detected during an internal operation in database ‘YourCorruptDatabase'(ID:10) on page (1:35293). Please contact technical support. Reference number 4.
SQL engine has logical checks in place to detect consistency problems for a row within database pages. Before SQL Server 2005 this would have resulted in fatal error that results a stack dump with an expression containing a word RecBase which is name of a class used to read elements of rows in a page logically.
SQL Server 2005 introduced two errors Msg 5242 and Msg 5243 that report all row consistency errors detected while reading a row part of standard SELECT, UPDATE etc. and you observe similar message as mentioned above in ERRORLOG. Error message says to contact technical support but before you do so, it is recommended to run DBCC CHECKDB and find out if it points to any damaged rows and database corruption and if not, you may take a call to contact technical support team.
Similar to Msg 5242, you may observe Msg 5243 in ERRORLOG. These two errors relate to the case that the offset of the variable length column offset array exceeded the value of offset for the last field of the record. You may run into these errors when running CHECKDB as part of maintenance plans or manually. The DBCC CHECKDB generally examines all the allocated pages in your SQL database and if it comes across a corrupt database page when trying to read this page, it might fail.
If you have enabled torn-page detection or page checksums for your database, you may not come across any of these errors instead you may get another error 824 by the buffer pool at the time of page read. These error codes indicate that you have corruption in structure of record. If you observe any of these errors on log, better not to ignore them and analyze if there is anything wrong with I/O subsystems. It is always recommended to preserve stack-dump and ERRORLOG in case you decide to contact technical support.
There are different repairing tools that are available in market which may help you to recover damaged data but you will have to consider the way they function, limitations (if any) and find out if they match your requirement.
Regards
Kanchan Bhattacharyya
Like us on FaceBook | Follow us on Twitter | Join the fastest growing SQL Server group on FaceBook
Follow me on Twitter | Follow me on FaceBook
