January 21, 2009 at 11:27 am
This is the error from Commvault :
2492341 [bwcimsdb1/SQLiDA] [01/21/2009 06:52:31 ]: Error encountered during backup. Error: [ERROR: [Microsoft][ODBC SQL Server Driver][SQL Server]Time-out occurred while waiting for buffer latch type 4 for page (1:2515), database ID 4. [Microsoft][ODBC SQL Server Driver][SQL Server]Could not insert a backup or restore history/detail record in the msdb database. This may indicate a problem with the msdb database. The backup/restore operation was still successful. [Microsoft][ODBC SQL Server Driver][SQL Server]BACKUP DATABASE successfully processed 3141483 pages in 439.343 seconds (58.576 MB/sec). [Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated
In the native maint plan can't get past the integrity check on msdb ... I ran this query (DBCC CHECKDB('msdb') WITH NO_INFOMSGS, ALL_ERRORMSGS) and got the following but not sure I understand what it's telling me ...
Msg 8929, Level 16, State 1, Line 1
Object ID 949578421, index ID 0, partition ID 72057594042253312, alloc unit ID 72057594046513152 (type In-row data): Errors found in off-row data with ID 523042816 owned by data record identified by RID = (1:1523:1)
Msg 8929, Level 16, State 1, Line 1
Object ID 949578421, index ID 0, partition ID 72057594042253312, alloc unit ID 72057594046513152 (type In-row data): Errors found in off-row data with ID 768606208 owned by data record identified by RID = (1:1525:0)
Msg 8914, Level 16, State 1, Line 1
Incorrect PFS free space information for page (1:1665) in object ID 949578421, index ID 0, partition ID 72057594042253312, alloc unit ID 72057594046513152 (type In-row data). Expected value 0_PCT_FULL, actual value 50_PCT_FULL.
Msg 8914, Level 16, State 1, Line 1
Incorrect PFS free space information for page (1:1667) in object ID 949578421, index ID 0, partition ID 72057594042253312, alloc unit ID 72057594046513152 (type In-row data). Expected value 0_PCT_FULL, actual value 50_PCT_FULL.
Msg 8914, Level 16, State 1, Line 1
January 23, 2009 at 12:52 am
Obviously you have a corrupted msdb database. The best option is to restore msdb from a backup which was taken before the corruption occured.
If you don't have a good backup you can try DBCC CHECKDB with one of the repair options, but I wold be very carefull with that, especially on a system database.
[font="Verdana"]Markus Bohse[/font]
January 23, 2009 at 1:06 am
Is that the full output from CheckDB? It doesn't look like it. Can you please the full output. (If it's large, save it to a text file, zip and attach)
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
January 23, 2009 at 8:26 am
Gail,
You are correct ... I only copied the first few lines ... I have attached the entire results set ... I have been looking at the DBCC CHECKDB with the repair_allow_data_loss parameter but have never had to use it before and am a little nervous as to what it might do ... So, even tho I hate to do it, I'm considering copying prod msdb to dev (and corrupting my dev msdb) to run tests ... Have you used this parameter on the CHECKDB before and if so, what was the outcome ... Also, thanks for the response ...
January 23, 2009 at 12:47 pm
Keena Ferguson (1/23/2009)
Gail,You are correct ... I only copied the first few lines ... I have attached the entire results set ... I have been looking at the DBCC CHECKDB with the repair_allow_data_loss parameter but have never had to use it before and am a little nervous as to what it might do
You should be. 🙂
... So, even tho I hate to do it, I'm considering copying prod msdb to dev (and corrupting my dev msdb) to run tests
...
No need to corrupt dev's msdb. You can restore the backup under a new name, as a user database and run your tests without harming anything
Have you used this parameter on the CHECKDB before and if so, what was the outcome ... Also, thanks for the response ...
I have. As it's name implies, it loses data. How much is very hard to tell. (will look at checkDB output when I get a few minutes).
Do you have a clean, undamaged backup of msdb? Restoring a backup is usually the preferred way to fix corruption problems.
Edit: I've asked the moderator to move this to the data corruption forum
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
January 25, 2009 at 7:39 pm
Moving to data corruption.
One thing I'd try to do is script out as much as possible before you mess with the db. Once you get things scripted out, you're in much better shape.
I'd restore this as another db name, say msdb_corrupt, and then check it out. The REPAIR_ALLOW_DATA_LOSS is problematic because there isn't a good way to determine what needs to be repaired. Paul Randal has discussed this in detail at times and talked about the problems they face and how they can end up just throwing data away.
May 18, 2010 at 6:37 am
Can we restore a CommVault SQL backup under defferent name ? I was looking to change name but didnt find any option for that ?
May 18, 2010 at 6:45 am
Please post new questions in a new thread. Thank you.
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
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply