Help-Corrupt table

I have a table that got corrupted last night somehow.
dbcc checktable on the table returns:
Server: Msg 7995, Level 16, State 3, Line 1
Database 'MPF' consistency errors in sysobjects,
sysindexes, syscolumns, or systypes prevent further CHECK
processing.
DBCC execution completed. If DBCC printed error messages,
contact your system administrator.
I've tried all 3 options including REPAIR_ALLOW_DATA_LOSS
and they all get the same results (above). I can't select
from the table either. I backed up the db and restored it
to another server...same thing. What all are my options
at this point? Is there anyway to fix the table without
going to backup?
Thanks,
VanHave you tried a DBCC CHECKDB ?
Peter
"The length of this document defends it well against the
risk of its being read."
Winston Churchill
>--Original Message--
>I have a table that got corrupted last night somehow.
>dbcc checktable on the table returns:
>Server: Msg 7995, Level 16, State 3, Line 1
>Database 'MPF' consistency errors in sysobjects,
>sysindexes, syscolumns, or systypes prevent further CHECK
>processing.
>DBCC execution completed. If DBCC printed error messages,
>contact your system administrator.
>I've tried all 3 options including REPAIR_ALLOW_DATA_LOSS
>and they all get the same results (above). I can't
select
>from the table either. I backed up the db and restored
it
>to another server...same thing. What all are my options
>at this point? Is there anyway to fix the table without
>going to backup?
>Thanks,
>Van
>.
>|||Yes. DBCC CheckTable is basically the same thing except
it only does one table. DBCC CheckDB generated the same
error.
>--Original Message--
>Have you tried a DBCC CHECKDB ?
>Peter
>"The length of this document defends it well against the
>risk of its being read."
>Winston Churchill
>
>>--Original Message--
>>I have a table that got corrupted last night somehow.
>>dbcc checktable on the table returns:
>>Server: Msg 7995, Level 16, State 3, Line 1
>>Database 'MPF' consistency errors in sysobjects,
>>sysindexes, syscolumns, or systypes prevent further
CHECK
>>processing.
>>DBCC execution completed. If DBCC printed error
messages,
>>contact your system administrator.
>>I've tried all 3 options including
REPAIR_ALLOW_DATA_LOSS
>>and they all get the same results (above). I can't
>select
>>from the table either. I backed up the db and restored
>it
>>to another server...same thing. What all are my options
>>at this point? Is there anyway to fix the table without
>>going to backup?
>>Thanks,
>>Van
>>.
>.
>|||In that case no - sorry, you will need to restore from
backup.
If you still have access to your Databases Data then you
could re-create it using the generate SQL (but that might
not work as it looks at the tables that caused the error),
DTS it, delete the old one, then rename the new one.
BTW CHECKTABLE and CHECKDB are different if you check BOL
under DBCC CHECKDB you will see 'DBCC CHECKDB performs the
same checking as if both a DBCC CHECKALLOC statement and a
DBCC CHECKTABLE statement were executed for each table in
the database.'
Anyway sorry I can't be of more help.
Peter
"Age is an issue of mind over matter. If you don't mind,
it doesn't matter."
Mark Twain
>--Original Message--
>Yes. DBCC CheckTable is basically the same thing except
>it only does one table. DBCC CheckDB generated the same
>error.
>>--Original Message--
>>Have you tried a DBCC CHECKDB ?
>>Peter
>>"The length of this document defends it well against the
>>risk of its being read."
>>Winston Churchill
>>
>>--Original Message--
>>I have a table that got corrupted last night somehow.
>>dbcc checktable on the table returns:
>>Server: Msg 7995, Level 16, State 3, Line 1
>>Database 'MPF' consistency errors in sysobjects,
>>sysindexes, syscolumns, or systypes prevent further
>CHECK
>>processing.
>>DBCC execution completed. If DBCC printed error
>messages,
>>contact your system administrator.
>>I've tried all 3 options including
>REPAIR_ALLOW_DATA_LOSS
>>and they all get the same results (above). I can't
>>select
>>from the table either. I backed up the db and restored
>>it
>>to another server...same thing. What all are my
options
>>at this point? Is there anyway to fix the table
without
>>going to backup?
>>Thanks,
>>Van
>>.
>>.
>.
>|||http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"VanColeJones" <anonymous@.discussions.microsoft.com> wrote in message
news:064801c518fd$15f1d550$a601280a@.phx.gbl...
> Yes. DBCC CheckTable is basically the same thing except
> it only does one table. DBCC CheckDB generated the same
> error.
>>--Original Message--
>>Have you tried a DBCC CHECKDB ?
>>Peter
>>"The length of this document defends it well against the
>>risk of its being read."
>>Winston Churchill
>>
>>--Original Message--
>>I have a table that got corrupted last night somehow.
>>dbcc checktable on the table returns:
>>Server: Msg 7995, Level 16, State 3, Line 1
>>Database 'MPF' consistency errors in sysobjects,
>>sysindexes, syscolumns, or systypes prevent further
> CHECK
>>processing.
>>DBCC execution completed. If DBCC printed error
> messages,
>>contact your system administrator.
>>I've tried all 3 options including
> REPAIR_ALLOW_DATA_LOSS
>>and they all get the same results (above). I can't
>>select
>>from the table either. I backed up the db and restored
>>it
>>to another server...same thing. What all are my options
>>at this point? Is there anyway to fix the table without
>>going to backup?
>>Thanks,
>>Van
>>.
>>.|||I see a hypothetical index on the corrupt table named "ĸ8=04". It's not really a lower case "k". It's something else and the square is somekind a carrage return or something because there is a blank line between this index name and the next. This index is listed as a clustered, hypothetical index. I already have a clustered index on this table (different fields). Not sure if a clustered hypothetical index is valid. And the name? I tried to drop it. Said it didn't exist but left the square out of the name (like it didn't see the square when it tried to drop it. So I u used brackets to refference it, and it says it's still not there (with the square this time).
>--Original Message--
>In that case no - sorry, you will need to restore from >backup.
>If you still have access to your Databases Data then you >could re-create it using the generate SQL (but that might >not work as it looks at the tables that caused the error), >DTS it, delete the old one, then rename the new one.
>BTW CHECKTABLE and CHECKDB are different if you check BOL >under DBCC CHECKDB you will see 'DBCC CHECKDB performs the >same checking as if both a DBCC CHECKALLOC statement and a >DBCC CHECKTABLE statement were executed for each table in >the database.'
>Anyway sorry I can't be of more help.
>Peter
>"Age is an issue of mind over matter. If you don't mind, >it doesn't matter." >Mark Twain >
>>--Original Message--
>>Yes. DBCC CheckTable is basically the same thing except >>it only does one table. DBCC CheckDB generated the same >>error.
>>--Original Message--
>>Have you tried a DBCC CHECKDB ?
>>Peter
>>"The length of this document defends it well against the >>risk of its being read." >>Winston Churchill >>
>>--Original Message--
>>I have a table that got corrupted last night somehow. >>dbcc checktable on the table returns:
>>Server: Msg 7995, Level 16, State 3, Line 1
>>Database 'MPF' consistency errors in sysobjects, >>sysindexes, syscolumns, or systypes prevent further >>CHECK >>processing.
>>DBCC execution completed. If DBCC printed error >>messages, >>contact your system administrator.
>>I've tried all 3 options including >>REPAIR_ALLOW_DATA_LOSS >>and they all get the same results (above). I can't >>select >>from the table either. I backed up the db and restored >>it >>to another server...same thing. What all are my >options >>at this point? Is there anyway to fix the table >without >>going to backup?
>>Thanks,
>>Van
>>.
>>.
>>.
>.
>|||Hmm Interesting, this maybe of help.
http://support.microsoft.com/default.aspx?scid=3Dkb;en-
us;818097
Peter
"All generalizations are false, including this one."
Mark Twain
>--Original Message--
>I see a hypothetical index on the corrupt table >named "ĸ8=04". It's not really a lower case "k". It's >something else and the square is somekind a carrage return >or something because there is a blank line between this >index name and the next. This index is listed as a >clustered, hypothetical index. I already have a clustered >index on this table (different fields). Not sure if a >clustered hypothetical index is valid. And the name? I >tried to drop it. Said it didn't exist but left the >square out of the name (like it didn't see the square when >it tried to drop it. So I u used brackets to refference >it, and it says it's still not there (with the square this >time).
>>--Original Message--
>>In that case no - sorry, you will need to restore from >>backup.
>>If you still have access to your Databases Data then you >>could re-create it using the generate SQL (but that might >>not work as it looks at the tables that caused the >error), >>DTS it, delete the old one, then rename the new one.
>>BTW CHECKTABLE and CHECKDB are different if you check BOL >>under DBCC CHECKDB you will see 'DBCC CHECKDB performs >the >>same checking as if both a DBCC CHECKALLOC statement and >a >>DBCC CHECKTABLE statement were executed for each table in >>the database.'
>>Anyway sorry I can't be of more help.
>>Peter
>>"Age is an issue of mind over matter. If you don't mind, >>it doesn't matter." >>Mark Twain >>
>>--Original Message--
>>Yes. DBCC CheckTable is basically the same thing except >>it only does one table. DBCC CheckDB generated the same >>error.
>>--Original Message--
>>Have you tried a DBCC CHECKDB ?
>>Peter
>>"The length of this document defends it well against >the >>risk of its being read." >>Winston Churchill >>
>>--Original Message--
>>I have a table that got corrupted last night somehow. >>dbcc checktable on the table returns:
>>Server: Msg 7995, Level 16, State 3, Line 1
>>Database 'MPF' consistency errors in sysobjects, >>sysindexes, syscolumns, or systypes prevent further >>CHECK >>processing.
>>DBCC execution completed. If DBCC printed error >>messages, >>contact your system administrator.
>>I've tried all 3 options including >>REPAIR_ALLOW_DATA_LOSS >>and they all get the same results (above). I can't >>select >>from the table either. I backed up the db and >restored >>it >>to another server...same thing. What all are my >>options >>at this point? Is there anyway to fix the table >>without >>going to backup?
>>Thanks,
>>Van
>>.
>>.
>>.
>>.
>.
>|||Thanks, that was it. Had to get the hotfix and test it and all, but that was the problem.
Thanks,
Van
>--Original Message--
>I see a hypothetical index on the corrupt table >named "ĸ8=04". It's not really a lower case "k". It's >something else and the square is somekind a carrage return >or something because there is a blank line between this >index name and the next. This index is listed as a >clustered, hypothetical index. I already have a clustered >index on this table (different fields). Not sure if a >clustered hypothetical index is valid. And the name? I >tried to drop it. Said it didn't exist but left the >square out of the name (like it didn't see the square when >it tried to drop it. So I u used brackets to refference >it, and it says it's still not there (with the square this >time).
>>--Original Message--
>>In that case no - sorry, you will need to restore from >>backup.
>>If you still have access to your Databases Data then you >>could re-create it using the generate SQL (but that might >>not work as it looks at the tables that caused the >error), >>DTS it, delete the old one, then rename the new one.
>>BTW CHECKTABLE and CHECKDB are different if you check BOL >>under DBCC CHECKDB you will see 'DBCC CHECKDB performs >the >>same checking as if both a DBCC CHECKALLOC statement and >a >>DBCC CHECKTABLE statement were executed for each table in >>the database.'
>>Anyway sorry I can't be of more help.
>>Peter
>>"Age is an issue of mind over matter. If you don't mind, >>it doesn't matter." >>Mark Twain >>
>>--Original Message--
>>Yes. DBCC CheckTable is basically the same thing except >>it only does one table. DBCC CheckDB generated the same >>error.
>>--Original Message--
>>Have you tried a DBCC CHECKDB ?
>>Peter
>>"The length of this document defends it well against >the >>risk of its being read." >>Winston Churchill >>
>>--Original Message--
>>I have a table that got corrupted last night somehow. >>dbcc checktable on the table returns:
>>Server: Msg 7995, Level 16, State 3, Line 1
>>Database 'MPF' consistency errors in sysobjects, >>sysindexes, syscolumns, or systypes prevent further >>CHECK >>processing.
>>DBCC execution completed. If DBCC printed error >>messages, >>contact your system administrator.
>>I've tried all 3 options including >>REPAIR_ALLOW_DATA_LOSS >>and they all get the same results (above). I can't >>select >>from the table either. I backed up the db and >restored >>it >>to another server...same thing. What all are my >>options >>at this point? Is there anyway to fix the table >>without >>going to backup?
>>Thanks,
>>Van
>>.
>>.
>>.
>>.
>.
>|||That KB has nothing whatsoever do to with the problem described. CHECKDB
won't do anything different from CHECKTABLE in this case. You've got system
table corruption that DBCC repairs will not fix so you must restore from
your last known good backup. Tibor's link is a good set of steps to follow.
Regards
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:068c01c51903$51607780$a601280a@.phx.gbl...
Hmm Interesting, this maybe of help.
http://support.microsoft.com/default.aspx?scid=kb;en-
us;818097
Peter
"All generalizations are false, including this one."
Mark Twain
>--Original Message--
>I see a hypothetical index on the corrupt table
>named "ĸ8 ". It's not really a lower case "k". It's
>something else and the square is somekind a carrage
return
>or something because there is a blank line between this
>index name and the next. This index is listed as a
>clustered, hypothetical index. I already have a
clustered
>index on this table (different fields). Not sure if a
>clustered hypothetical index is valid. And the name? I
>tried to drop it. Said it didn't exist but left the
>square out of the name (like it didn't see the square
when
>it tried to drop it. So I u used brackets to refference
>it, and it says it's still not there (with the square
this
>time).
>>--Original Message--
>>In that case no - sorry, you will need to restore from
>>backup.
>>If you still have access to your Databases Data then you
>>could re-create it using the generate SQL (but that
might
>>not work as it looks at the tables that caused the
>error),
>>DTS it, delete the old one, then rename the new one.
>>BTW CHECKTABLE and CHECKDB are different if you check
BOL
>>under DBCC CHECKDB you will see 'DBCC CHECKDB performs
>the
>>same checking as if both a DBCC CHECKALLOC statement and
>a
>>DBCC CHECKTABLE statement were executed for each table
in
>>the database.'
>>Anyway sorry I can't be of more help.
>>Peter
>>"Age is an issue of mind over matter. If you don't mind,
>>it doesn't matter."
>>Mark Twain
>>
>>--Original Message--
>>Yes. DBCC CheckTable is basically the same thing
except
>>it only does one table. DBCC CheckDB generated the
same
>>error.
>>--Original Message--
>>Have you tried a DBCC CHECKDB ?
>>Peter
>>"The length of this document defends it well against
>the
>>risk of its being read."
>>Winston Churchill
>>
>>--Original Message--
>>I have a table that got corrupted last night
somehow.
>>dbcc checktable on the table returns:
>>Server: Msg 7995, Level 16, State 3, Line 1
>>Database 'MPF' consistency errors in sysobjects,
>>sysindexes, syscolumns, or systypes prevent further
>>CHECK
>>processing.
>>DBCC execution completed. If DBCC printed error
>>messages,
>>contact your system administrator.
>>I've tried all 3 options including
>>REPAIR_ALLOW_DATA_LOSS
>>and they all get the same results (above). I can't
>>select
>>from the table either. I backed up the db and
>restored
>>it
>>to another server...same thing. What all are my
>>options
>>at this point? Is there anyway to fix the table
>>without
>>going to backup?
>>Thanks,
>>Van
>>.
>>.
>>.
>>.
>.
>|||Oops - mistyped the URL and looked at the wrong KB article. Well done Peter.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:e4R1dHRGFHA.1292@.TK2MSFTNGP10.phx.gbl...
> That KB has nothing whatsoever do to with the problem described. CHECKDB
> won't do anything different from CHECKTABLE in this case. You've got
system
> table corruption that DBCC repairs will not fix so you must restore from
> your last known good backup. Tibor's link is a good set of steps to
follow.
> Regards
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
> news:068c01c51903$51607780$a601280a@.phx.gbl...
> Hmm Interesting, this maybe of help.
> http://support.microsoft.com/default.aspx?scid=kb;en-
> us;818097
> Peter
> "All generalizations are false, including this one."
> Mark Twain
>
> >--Original Message--
> >I see a hypothetical index on the corrupt table
> >named "ĸ8 ". It's not really a lower case "k". It's
> >something else and the square is somekind a carrage
> return
> >or something because there is a blank line between this
> >index name and the next. This index is listed as a
> >clustered, hypothetical index. I already have a
> clustered
> >index on this table (different fields). Not sure if a
> >clustered hypothetical index is valid. And the name? I
> >tried to drop it. Said it didn't exist but left the
> >square out of the name (like it didn't see the square
> when
> >it tried to drop it. So I u used brackets to refference
> >it, and it says it's still not there (with the square
> this
> >time).
> >
> >>--Original Message--
> >>In that case no - sorry, you will need to restore from
> >>backup.
> >>
> >>If you still have access to your Databases Data then you
> >>could re-create it using the generate SQL (but that
> might
> >>not work as it looks at the tables that caused the
> >error),
> >>DTS it, delete the old one, then rename the new one.
> >>
> >>BTW CHECKTABLE and CHECKDB are different if you check
> BOL
> >>under DBCC CHECKDB you will see 'DBCC CHECKDB performs
> >the
> >>same checking as if both a DBCC CHECKALLOC statement and
> >a
> >>DBCC CHECKTABLE statement were executed for each table
> in
> >>the database.'
> >>
> >>Anyway sorry I can't be of more help.
> >>Peter
> >>
> >>"Age is an issue of mind over matter. If you don't mind,
> >>it doesn't matter."
> >>Mark Twain
> >>
> >>
> >>--Original Message--
> >>Yes. DBCC CheckTable is basically the same thing
> except
> >>it only does one table. DBCC CheckDB generated the
> same
> >>error.
> >>
> >>--Original Message--
> >>Have you tried a DBCC CHECKDB ?
> >>
> >>Peter
> >>
> >>"The length of this document defends it well against
> >the
> >>risk of its being read."
> >>Winston Churchill
> >>
> >>
> >>--Original Message--
> >>I have a table that got corrupted last night
> somehow.
> >>dbcc checktable on the table returns:
> >>
> >>Server: Msg 7995, Level 16, State 3, Line 1
> >>Database 'MPF' consistency errors in sysobjects,
> >>sysindexes, syscolumns, or systypes prevent further
> >>CHECK
> >>processing.
> >>DBCC execution completed. If DBCC printed error
> >>messages,
> >>contact your system administrator.
> >>
> >>I've tried all 3 options including
> >>REPAIR_ALLOW_DATA_LOSS
> >>and they all get the same results (above). I can't
> >>select
> >>from the table either. I backed up the db and
> >restored
> >>it
> >>to another server...same thing. What all are my
> >>options
> >>at this point? Is there anyway to fix the table
> >>without
> >>going to backup?
> >>
> >>Thanks,
> >>
> >>Van
> >>.
> >>
> >>.
> >>
> >>.
> >>
> >>.
> >>
> >.
> >
>|||This is just a followup if anybody's curious. This hotfix didn't totally fix the error. DBCC CheckTable and CheckDB were still giving errors. Exception_Access_Violations were still occuring and the SQL server was actually stopping itself. The hotfix did at least make it so that I could at least select from the table and recreate it without having to go to backup. So I just recreated the table and dropped the old one. All is good now...
>--Original Message--
>Thanks, that was it. Had to get the hotfix and test it >and all, but that was the problem.
>Thanks,
>Van
>>--Original Message--
>>I see a hypothetical index on the corrupt table >>named "ĸ8=04". It's not really a lower case "k". It's >>something else and the square is somekind a carrage >return >>or something because there is a blank line between this >>index name and the next. This index is listed as a >>clustered, hypothetical index. I already have a >clustered >>index on this table (different fields). Not sure if a >>clustered hypothetical index is valid. And the name? I >>tried to drop it. Said it didn't exist but left the >>square out of the name (like it didn't see the square >when >>it tried to drop it. So I u used brackets to refference >>it, and it says it's still not there (with the square >this >>time).
>>--Original Message--
>>In that case no - sorry, you will need to restore from >>backup.
>>If you still have access to your Databases Data then you >>could re-create it using the generate SQL (but that >might >>not work as it looks at the tables that caused the >>error), >>DTS it, delete the old one, then rename the new one.
>>BTW CHECKTABLE and CHECKDB are different if you check >BOL >>under DBCC CHECKDB you will see 'DBCC CHECKDB performs >>the >>same checking as if both a DBCC CHECKALLOC statement and >>a >>DBCC CHECKTABLE statement were executed for each table >in >>the database.'
>>Anyway sorry I can't be of more help.
>>Peter
>>"Age is an issue of mind over matter. If you don't mind, >>it doesn't matter." >>Mark Twain >>
>>--Original Message--
>>Yes. DBCC CheckTable is basically the same thing >except >>it only does one table. DBCC CheckDB generated the >same >>error.
>>--Original Message--
>>Have you tried a DBCC CHECKDB ?
>>Peter
>>"The length of this document defends it well against >>the >>risk of its being read." >>Winston Churchill >>
>>--Original Message--
>>I have a table that got corrupted last night >somehow. >>dbcc checktable on the table returns:
>>Server: Msg 7995, Level 16, State 3, Line 1
>>Database 'MPF' consistency errors in sysobjects, >>sysindexes, syscolumns, or systypes prevent further >>CHECK >>processing.
>>DBCC execution completed. If DBCC printed error >>messages, >>contact your system administrator.
>>I've tried all 3 options including >>REPAIR_ALLOW_DATA_LOSS >>and they all get the same results (above). I can't >>select >>from the table either. I backed up the db and >>restored >>it >>to another server...same thing. What all are my >>options >>at this point? Is there anyway to fix the table >>without >>going to backup?
>>Thanks,
>>Van
>>.
>>.
>>.
>>.
>>.
>.
>