searchsanjaysharma
asked on
How to correct error in Sql Server: An inconsistency was detected during an internal operation in database 'Nawada'(ID:6) on page (1:14194556). Please contact technical support. Reference number 4.
I have a database Nawada, and Table name is txndependents
for which i am not able to fetch record because of above error.
The output of dbcc checkdb is as follows: This has stuck my work, Please help, so that i can correct the error.
DBCC results for 'TxnDependents'.
Msg 8928, Level 16, State 1, Line 1
Object ID 1093578934, index ID 1, partition ID 72057594040614912, alloc unit ID 72057594045071360 (type In-row data): Page (1:14194556) could not be processed. See other errors for details.
Msg 8944, Level 16, State 18, Line 1
Table error: Object ID 1093578934, index ID 1, partition ID 72057594040614912, alloc unit ID 72057594045071360 (type In-row data), page (1:14194556), row 0. Test (columnOffsets->offTbl [varColumnNumber] >= priorOffset) failed. Values are 25 and 67.
Msg 8944, Level 16, State 18, Line 1
Table error: Object ID 1093578934, index ID 1, partition ID 72057594040614912, alloc unit ID 72057594045071360 (type In-row data), page (1:14194556), row 0. Test (columnOffsets->offTbl [varColumnNumber] >= priorOffset) failed. Values are 25 and 67.
There are 24621219 rows in 320099 pages for object "TxnDependents".
CHECKDB found 0 allocation errors and 3 consistency errors in table 'TxnDependents' (object ID 1093578934).
for which i am not able to fetch record because of above error.
The output of dbcc checkdb is as follows: This has stuck my work, Please help, so that i can correct the error.
DBCC results for 'TxnDependents'.
Msg 8928, Level 16, State 1, Line 1
Object ID 1093578934, index ID 1, partition ID 72057594040614912, alloc unit ID 72057594045071360 (type In-row data): Page (1:14194556) could not be processed. See other errors for details.
Msg 8944, Level 16, State 18, Line 1
Table error: Object ID 1093578934, index ID 1, partition ID 72057594040614912, alloc unit ID 72057594045071360 (type In-row data), page (1:14194556), row 0. Test (columnOffsets->offTbl [varColumnNumber] >= priorOffset) failed. Values are 25 and 67.
Msg 8944, Level 16, State 18, Line 1
Table error: Object ID 1093578934, index ID 1, partition ID 72057594040614912, alloc unit ID 72057594045071360 (type In-row data), page (1:14194556), row 0. Test (columnOffsets->offTbl [varColumnNumber] >= priorOffset) failed. Values are 25 and 67.
There are 24621219 rows in 320099 pages for object "TxnDependents".
CHECKDB found 0 allocation errors and 3 consistency errors in table 'TxnDependents' (object ID 1093578934).
Raja Jegan R
Rebuild your Primary key or Clustered key in txndependents table which should ideally fix consistency issues.
Can you check to see if you have full & transaction log backups?
DONT RESTORE YET, this is a check.
DONT RESTORE YET, this is a check.
@rrjegan if you have a corrupted clustered index you cannot just rebuild it as this is the leaf level data! Although i do agree that you can rebuild non-clustered indexes.
searchsanjeysharma,
Could you tell me if anything has happened recently to the system? Disk failure / Power Failure etc?
Could you tell me if anything has happened recently to the system? Disk failure / Power Failure etc?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
As you say replair allow data loss could loose data so the better option would be to do a tail log backup to ensure you have to most recent transactions and take the database offline so nothing more can go into the database. Then.....
restore full backup in norecovery
apply all the transaction log backups including the tail log backup which has been taken.
This will mean there is no data loss. But obviously this is dependant upon if the backups are available. Thus the original response.
restore full backup in norecovery
apply all the transaction log backups including the tail log backup which has been taken.
This will mean there is no data loss. But obviously this is dependant upon if the backups are available. Thus the original response.
If there is any data loss, then you can try restoring from the available backups as mentioned by you..
Repair will not cause data loss? It depends. If you have to use REPAIR_ALLOW_DATA_LOSS, then you're going to lose data. That's why the option is named that - seriously
Quote from Paul Randall
http://www.sqlskills.com/aboutpaulsrandal.asp
ASKER
ok
ASKER
ok