August 19, 2011 at 6:54 pm
In the middle of an overnight migration of a rather large database. Plan was to backup and restore using netbackup. Dry run worked fine- twice. Now, at cutover time, of course it is not working. Contingency plan is detach and attach, but was wondering if anyone has seen this before. The restore get 99.9% through, but fails to bring the database online, leaves it in the "restoring" state The error log shows errors like :
BlkHeader from strip 0 at 4ff3bec00 expected at 4ff3bec00 size f000 prevsize f000
the log contains 20 or so errors like this all in the same second...
when I attempted to "restore database dbname with recovery" it just gives "the databse can not be restored because the log has not been applied"
any thoughts?
here's to hoping for detach/attach...
August 19, 2011 at 10:36 pm
detach/attach did the trick... no urgency to this at all any more... but still curious.
August 20, 2011 at 1:23 pm
Sounds like some kind of hardware issue. Was the restore run across the network? Might have glitched there. You're using a third party product? Might have been something in there (not sure what). See if that tool has a log you can check.
I usually copy the backup locally and then restore 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
August 21, 2011 at 7:19 am
yeah, was a restore across the network using netbackup. netbackup just got "the connection was forcibly closed by the remote host".... thing is, we restore this way lots of times w/o a problem. This time, we tried twice using same backup. Both times, it got to 99% then errored out... my theory is something was wrong with the backup (despite the assurances from the backup team that the backup was fine).
August 21, 2011 at 8:05 am
NJ-DBA (8/21/2011)
yeah, was a restore across the network using netbackup. netbackup just got "the connection was forcibly closed by the remote host".... thing is, we restore this way lots of times w/o a problem. This time, we tried twice using same backup. Both times, it got to 99% then errored out... my theory is something was wrong with the backup (despite the assurances from the backup team that the backup was fine).
Might be a different definition of a "fine" backup...
I'd consider a backup to be fine only if it's possible to restore from it 😉
August 21, 2011 at 5:35 pm
I'm with Lutz. Sounds like an issue with the backup, but I wouldn't discount the network.
"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 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply