Corrupted table

When I try and examine a table in one of my MS SQL Server 2000 databases I
get the following error from Enterprise Manager:
[Microsoft][ODBC..] I/O error (bad page ID) detected during read at offset
0X00000000038000 in file ...MDF
How do I go about fixing this?
Thanks,
Hi
In Query Analyzer, run DBCC CHECKDB to get an idea of how widespread the
corruption is. Check all the DBs on the server.
Start looking for you most recent backup.
If the corruption is not too bad, you might be able to run DBCC CECKDB
REPAIR_REBUILD
else, you would need to use DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS (but you may
loose data).
Generally, corruption is caused by hardware faults.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Andrew Chalk" <achalk@.XXXmagnacartasoftware.com> wrote in message
news:O4XR1rJWFHA.3280@.TK2MSFTNGP09.phx.gbl...
> When I try and examine a table in one of my MS SQL Server 2000 databases I
> get the following error from Enterprise Manager:
> [Microsoft][ODBC..] I/O error (bad page ID) detected during read at offset
> 0X00000000038000 in file ...MDF
> How do I go about fixing this?
> Thanks,
>
>
|||"Andrew Chalk" <achalk@.XXXmagnacartasoftware.com> wrote in
news:O4XR1rJWFHA.3280@.TK2MSFTNGP09.phx.gbl:

> I/O error (bad page ID) detected during read at offset
Run...
DBCC CHECKDB
Regards
JTC ^..^
|||Also look at http://www.karaszi.com/SQLServer/inf...suspect_db.asp
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:OgvrizJWFHA.3320@.TK2MSFTNGP12.phx.gbl...
> Hi
> In Query Analyzer, run DBCC CHECKDB to get an idea of how widespread the
> corruption is. Check all the DBs on the server.
> Start looking for you most recent backup.
> If the corruption is not too bad, you might be able to run DBCC CECKDB
> REPAIR_REBUILD
> else, you would need to use DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS (but you
> may loose data).
> Generally, corruption is caused by hardware faults.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Andrew Chalk" <achalk@.XXXmagnacartasoftware.com> wrote in message
> news:O4XR1rJWFHA.3280@.TK2MSFTNGP09.phx.gbl...
>
|||Thanks Mike. I was able to Export the table SQL definition, delete the table
and then recreate it from the script.
- Andrew
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:uzMoM3JWFHA.584@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> Also look at http://www.karaszi.com/SQLServer/inf...suspect_db.asp
> --
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:OgvrizJWFHA.3320@.TK2MSFTNGP12.phx.gbl...
databases
>
|||Hi Andrew,
Now you should be in good shape, but still run a DBCC CHECKDB(DBNAME) and
ensure that database is in good shape.
Note:
As part of your routine maintenance please schedule a DBCC CHECKDB for all
production databases. This will help you to identify issues earlier.
Thanks
Hari
SQL Server MVP
"Andrew Chalk" <achalk@.XXXmagnacartasoftware.com> wrote in message
news:e2s03xOWFHA.628@.tk2msftngp13.phx.gbl...
> Thanks Mike. I was able to Export the table SQL definition, delete the
> table
> and then recreate it from the script.
> - Andrew
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:uzMoM3JWFHA.584@.TK2MSFTNGP15.phx.gbl...
> databases
>
|||Andrew,
A key here that Mike mentioned is "Generally, corruption is caused by
hardware faults".
now that you solved the immediate issue of data\table corruption. The next
step is to figure out "WHY".
If you dont do this, your data is likely going to become corrupt again very
soon.
I suspect a disk is going haywire on you or your RAID Controller is kicking
the bucket.
I just went through this with two different customers. One turned out to be
disk, hte other turned out to be RAID Controller.
cheers
Greg Jackson
PDX, Oregon
|||I'll do that.
- Andrew
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:efyvtDTWFHA.3280@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Hi Andrew,
> Now you should be in good shape, but still run a DBCC CHECKDB(DBNAME) and
> ensure that database is in good shape.
> Note:
> As part of your routine maintenance please schedule a DBCC CHECKDB for all
> production databases. This will help you to identify issues earlier.
> Thanks
> Hari
> SQL Server MVP
> "Andrew Chalk" <achalk@.XXXmagnacartasoftware.com> wrote in message
> news:e2s03xOWFHA.628@.tk2msftngp13.phx.gbl...
http://www.karaszi.com/SQLServer/inf...suspect_db.asp[vbcol=seagreen]
CECKDB
>
|||This is on a development machine rather than a production server so I
suspect it may have been roughly rebooted periodically. There hasn't been
any other evidence of disk problems so i am just backing up frequently for
now.
Thanks,
Andrew
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:OPRePnVWFHA.2128@.TK2MSFTNGP15.phx.gbl...
> Andrew,
> A key here that Mike mentioned is "Generally, corruption is caused by
> hardware faults".
> now that you solved the immediate issue of data\table corruption. The next
> step is to figure out "WHY".
> If you dont do this, your data is likely going to become corrupt again
very
> soon.
> I suspect a disk is going haywire on you or your RAID Controller is
kicking
> the bucket.
> I just went through this with two different customers. One turned out to
be
> disk, hte other turned out to be RAID Controller.
>
> cheers
>
> Greg Jackson
> PDX, Oregon
>