April 9, 2014 at 2:35 am
restored full backup with norecovery , getting below error while restore the diff backup with recovery .
Error:
Unexpected termination on thread: 0, Return code: x80770004
RESTORE
DATABASE is terminating abnormally.
Problems were identified while planning for the RESTORE statement.
Previous messages provide details.
A previous restore operation was interrupted and did not complete processing on file 'abc_data'. Either restore the backup set that was interrupted or restart the restore sequence.
A previous restore operation was interrupted and did not complete processing on file 'abc_Data'. Either restore the backup set that was interrupted or restart the restore sequence.
any help to resolve this ?
April 9, 2014 at 3:01 am
charipg (4/9/2014)
A previous restore operation was interrupted and did not complete processing on file 'abc_data'. Either restore the backup set that was interrupted or restart the restore sequence.
i.e. Restore the full again, it didn't complete last time.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 9, 2014 at 5:57 am
Please don't cross post questions to multiple forums. It just confuses the discussion.
Gail, I said the same thing on the other one.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 9, 2014 at 6:14 am
full restaoration will take again half day.
is there any other way to solve it ?
April 9, 2014 at 6:19 am
In general, not always, but usually, the error message is telling you what's wrong and what you need to do to resolve it. You had an incomplete restore, specifically on a file (which possibly suggests extra steps you haven't detailed here), you either need to complete that restore operation or restart it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 9, 2014 at 6:53 am
charipg (4/9/2014)
full restaoration will take again half day.
Then you may want to get started.
Probably longer than half a day, since the last restore failed part way through for some reason we don't know.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 9, 2014 at 8:44 am
ok..thanks for the advice.
April 11, 2014 at 12:18 am
You may also try to improve the restore time by testing MAXTRANSFERSIZE and BUFFERCOUNT values.
April 11, 2014 at 1:37 am
If you think that your backup is corrupt you can use RESTORE VERIFYONLY to check if the backup is good?
---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
April 11, 2014 at 3:48 am
free_mascot (4/11/2014)
If you think that your backup is corrupt you can use RESTORE VERIFYONLY to check if the backup is good?
Which will check just the header unless your backup is done with checksum. If your backup was done with checksum then verify only will redo the checksum validation and check the header. But, it doesn't check all of the header, so you can still have a bad backup after running checksum and verifyonly. The only way to ensure you have a good backup is to run a restore.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply