internal consistency error on restore
-
Every night, we backup a production database on machine A to a drive on machine B.
We restore it from B to a server that is used for reporting, machine C.
The database is around 12G.
The hardware and raid arrays are all Compaq.
Occasionally we get an error on the restore:
An internal consistency error occurred. Contact Technical Support for assistance. [SQLSTATE 42000] (Error 3270) RESTORE DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013).
The SQL server logs are clear.
The event logs are clear.
Restore verifyonly reports no errors.
dbcc checkdb on the production database reports no errors.
Restoring to a different machine fails with the same error.
Machine B is used for backing up many other files (although I don't think any are anywhere near 12 G).
No other problems are apparent on machine B.
I have seen some posts about similar problems.
Does anyone have a resolution to this?
I am currently working with Microsoft.
They suspect a hardware problem.
Are there any utilities that will analyze a backup file?
Is the file format of a backup file described anywhere?
Thanks for any help.
John
-
shot in a dark: do you have the same service packs/MDACS applied on all machines?
-
Are you restoring from a compressed drive/directory? that caused us a similar problem some time ago.
-
We had an inhouse machine used as a playground for testing new things.
One thing we tested was a conversion from a 3rd party apps database (approx 4GB of dbase stuff) to our database (SQL-based).
The customer provided their DB zipped. On our playground machine, no matter what I did, if I extracted the zip from the machine's HDD (which was an IDE in RAID 1) there were ALWAYS consistency errors and these seemed to be in random spots. The OS ran perfectly, chkdsk never found any errors, etc... But, for a big file (~2GB) it just didn't work - I never found out why even after trying new drivers for RAID, etc (and it was an NTFS filesytem so filesizes weren't an issue). Using another machine to extract the zip worked perfectly.
Perhaps you too have a lemon?
-
Peter how did you handle the compressed backup restore?
-
This maybe a case of Corrupted Database BAckup or a Corrupted hardware that the Database is on.
DBCC UPDATEUSAGE(DBNAME)
DBCC CHECKALLOC (DBNAME)
Also try this: DBCC PAGE (DBNAME,1,1,0)
Maninder
www.dbanation.com -
Just in case anyone searches and wants to know what happened.....
I think our server hardware guy had local drives and a tape drive on the same scsi channel.
He moved the tape drive to its own scsi channel and the problem went away.
The hard drives and tape drives never had an error in any log files.
With lots of user files being backed up, the system never had any problems.
It was just with a big sql file where the problem occured.
Good luck
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply