Suspect Database Restore and SQB to MDF Conversion Issues
laurencerooks
Posts: 28
Hello all,
I have run into three big problems and am looking for some assistance. I have a database that has been marked suspect.
Problem #1: I am unable to do a transaction log backup without truncating the log via SQL Backup but am able to via native SQL, which doesn't help me since everything else has been backed up using SQL Backup. The error message produced is access denied, even though I am using the same user with the native SQL backup command.
Problem #2: I am unable to do a restore via SQL Backup. It appears that each time it trys to finish the recovery process and bring the database online, the physical machine restarts. If I do the restore chain individually via SSMS, each request is successful because it has yet to recover the database and bring it online. Once the recovery command is issued, the physical server restarts itself. There are no error messages to post.
Problem #3. The database I'm trying to recover is 35 GB in size, 6 GB compressed using 3 threads. When trying to convert them back to native SQL backup files, I get three files, but they are 9 MB in size each. There are no error messages to post.
Does anyone have any idea what's going on with either of these issues? Thanks in advance.
Laurence Rooks
TTI, Inc.
laurence.rooks@ttiinc.com
I have run into three big problems and am looking for some assistance. I have a database that has been marked suspect.
Problem #1: I am unable to do a transaction log backup without truncating the log via SQL Backup but am able to via native SQL, which doesn't help me since everything else has been backed up using SQL Backup. The error message produced is access denied, even though I am using the same user with the native SQL backup command.
Problem #2: I am unable to do a restore via SQL Backup. It appears that each time it trys to finish the recovery process and bring the database online, the physical machine restarts. If I do the restore chain individually via SSMS, each request is successful because it has yet to recover the database and bring it online. Once the recovery command is issued, the physical server restarts itself. There are no error messages to post.
Problem #3. The database I'm trying to recover is 35 GB in size, 6 GB compressed using 3 threads. When trying to convert them back to native SQL backup files, I get three files, but they are 9 MB in size each. There are no error messages to post.
Does anyone have any idea what's going on with either of these issues? Thanks in advance.
Laurence Rooks
TTI, Inc.
laurence.rooks@ttiinc.com
Comments
If I understand you correctly, all three issues revolve around a database that is marked as suspect, is that right?
If so, I don't think you would want to back it up, as it is broken in some way. You'll want to grab the latest good backups and restore it. There is a short article on SQL Server Central covering suspect databases: maybe this will help?
http://www.sqlservercentral.com/columni ... uspect.asp
Problem #2 shows that I am trying to take the latest good backup and restore it via SQL Backup. The server seems to be restarting whenever the system issues a WITH RECOVERY statement after the last transaction log has been restored.
This still doesn't cover the issue of Problem #1, which is essential when trying to recover everything possible after your database has been marked suspect, which is making a backup of the transaction log with no_truncate.
This also doesn't cover the issue of Problem #3, which points out a bug in the SQB to MTF conversion software, decompressing from level 1 to native SQL backup files.
Laurence