DBCC CHECKDB error on msdb

Hello,
I ran DBCC CHECKDB against msdb and received this error:
Msg 8951, Level 16, State 1, Line 1
Table error: table 'backupmediaset' (ID 1858105660). Data row does not have
a matching index row in the index 'backupmediasetuuid' (ID 2). Possible
missing or invalid keys for the index row matching:
Msg 8955, Level 16, State 1, Line 1
Data row (1:1296:37) identified by (media_set_id = 202398) with index values
'media_uuid = '6696C13F-D39D-40F7-B9C0-7634F288F353' and media_set_id = 202398'.
What's the next step for me to correct this? Or, was it already corrected
by CHECKDB?Ant-nee,
If DBCC had tried to do a fix your output would list the results. So, it is
not fixed. There are 'repair' options for DBCC CHECKDB but read carefully
about what they consider to be a 'repair' before running them.
The Books Online recommends restoring from a good backup of the database.
However, since this is a non-clustered index it should be fixable by simply
dropping and recreating the NC index as scripted (from SQL Server 2005)
below:
USE [msdb]
GO
IF EXISTS (SELECT * FROM sys.indexes WHERE object_id =OBJECT_ID(N'[dbo].[backupmediaset]') AND name = N'backupmediasetuuid')
DROP INDEX [backupmediasetuuid] ON [dbo].[backupmediaset] WITH ( ONLINE =OFF )
CREATE NONCLUSTERED INDEX [backupmediasetuuid] ON [dbo].[backupmediaset]
([media_uuid] ASC)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF,
IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS =ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
Then rerun DBCC CHECKDB of course.
RLF
"Ant-nee" <Antnee@.discussions.microsoft.com> wrote in message
news:EC19F97E-D1D1-42B3-B272-DF9F6A93D6D8@.microsoft.com...
> Hello,
> I ran DBCC CHECKDB against msdb and received this error:
> Msg 8951, Level 16, State 1, Line 1
> Table error: table 'backupmediaset' (ID 1858105660). Data row does not
> have
> a matching index row in the index 'backupmediasetuuid' (ID 2). Possible
> missing or invalid keys for the index row matching:
> Msg 8955, Level 16, State 1, Line 1
> Data row (1:1296:37) identified by (media_set_id = 202398) with index
> values
> 'media_uuid = '6696C13F-D39D-40F7-B9C0-7634F288F353' and media_set_id => 202398'.
> What's the next step for me to correct this? Or, was it already corrected
> by CHECKDB?|||Russell,
THANKS! This fixed the problem.
"Russell Fields" wrote:
> Ant-nee,
> If DBCC had tried to do a fix your output would list the results. So, it is
> not fixed. There are 'repair' options for DBCC CHECKDB but read carefully
> about what they consider to be a 'repair' before running them.
> The Books Online recommends restoring from a good backup of the database.
> However, since this is a non-clustered index it should be fixable by simply
> dropping and recreating the NC index as scripted (from SQL Server 2005)
> below:
> USE [msdb]
> GO
> IF EXISTS (SELECT * FROM sys.indexes WHERE object_id => OBJECT_ID(N'[dbo].[backupmediaset]') AND name = N'backupmediasetuuid')
> DROP INDEX [backupmediasetuuid] ON [dbo].[backupmediaset] WITH ( ONLINE => OFF )
> CREATE NONCLUSTERED INDEX [backupmediasetuuid] ON [dbo].[backupmediaset]
> ([media_uuid] ASC)
> WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF,
> IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS => ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
> Then rerun DBCC CHECKDB of course.
> RLF
>
> "Ant-nee" <Antnee@.discussions.microsoft.com> wrote in message
> news:EC19F97E-D1D1-42B3-B272-DF9F6A93D6D8@.microsoft.com...
> > Hello,
> >
> > I ran DBCC CHECKDB against msdb and received this error:
> >
> > Msg 8951, Level 16, State 1, Line 1
> > Table error: table 'backupmediaset' (ID 1858105660). Data row does not
> > have
> > a matching index row in the index 'backupmediasetuuid' (ID 2). Possible
> > missing or invalid keys for the index row matching:
> > Msg 8955, Level 16, State 1, Line 1
> > Data row (1:1296:37) identified by (media_set_id = 202398) with index
> > values
> > 'media_uuid = '6696C13F-D39D-40F7-B9C0-7634F288F353' and media_set_id => > 202398'.
> >
> > What's the next step for me to correct this? Or, was it already corrected
> > by CHECKDB?
>
>