January 4, 2007 at 2:20 pm
Hi
I recently had a hard disk failure on which was running Win2003 SQL2000 SP4.
This server is a sharepoint backend server, I repaired the disk to the point that it could be mirrored across to a new and then set about looking at the databases. There was a schedule in place to backup all 4 DBs daily, the backup process at no time after verifying the backup had any errors. All but one of the DBs reports this error when I attempt to run DBCC or similar query I/O error (bad page ID) detected during read at offset etc. (error 823) I have restored back to the earliest DBs I have and I still get the same error.
Any ideas on how I can recover as much as possible if not all of the DBs? What is the best way to restore from a transaction log? I have found a few articles on it and they all take a slightly different approach for differnet situations however I'm not entirely sure which applies to me.
All help will be very much appreciated.
Thx,
Joe
January 5, 2007 at 5:24 am
Have you tried running DBCC CHECKDB with the repair options?
January 5, 2007 at 7:02 am
If the DBCC repair doesn't fix the problem another idea is to copy over the database .mdf and .ldf files and run a sp_attach_db.
Check the database id of the object in error, if its an index, recreate the index.
January 10, 2007 at 5:47 am
Hi,
This link will give you more information :
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B828339
Minaz Amin
"More Green More Oxygen !! Plant a tree today"
April 14, 2007 at 9:33 pm
823 error means that the page is corrupt. If the backup was taken after the corruption, that would be present in restored database as well.
run dbcc checktable on all tables, identify the tables that are corrupt. run
select * from tablename order by PK
select * from tablename order by PK DESC
this will tell you how much of data is readable in table. this is what you can salvage without much of efforts (select into command).
DBCC CHECKDB/CHECKTABLE with necessary repair option is also an option for you.
April 16, 2007 at 6:54 am
Hello,
You might want to check the location of the bad data. If your corruption exists in a non-clustered index, you are in luck, because you can drop and re-create the index without losing any data.
I think that the repair with data loss would do the same thing for you, but I'm not so sure it will tell you that's all it did. I'd want to know.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply