Monday, March 26, 2012

Error: 823

Hi,

I am I notice this message on the event logs.

Error: 823, Severity: 24, State: 2
I/O error (bad page ID) detected during read at offset 0x000003182da000 in file 'e:\sqlData\FSDocsOnline.mdf'.

If I was to run:

DBCC CHECKDB
( 'database_name'
[ , NOINDEX
| { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
} ]
) [ WITH { [ ALL_ERRORMSGS ]
[ , [ NO_INFOMSGS ] ]
[ , [ TABLOCK ] ]
[ , [ ESTIMATEONLY ] ]
[ , [ PHYSICAL_ONLY ] ]
}
]

Will it fix my problem or will I need to restore the database. Which have no backup.

LystraYou might be able to fix the database, but I'd be more comfortable with either restoring a backup, or better yet trying to copy the data out one table at a time (saving the backup for a last resort).

A lot depends on just what is broken and how it broke. I don't have a good way to guess what caused the problem, so I'd assume that it will be tough to fix.

-PatP|||Well there is no Backup for this database. The last time it was backup was in 10/03. And the files have since been deleted.

In order to copy the time out one at a time what would this accomplish. And to do this should I use the bCP out method?

Thanking you in advance.

Lystra|||Brett would say yes to the BCP part.|||The method you use for the copy isn't really significant. You can BCP to flat files, or you can just use an INSERT if both databases are on the same server, or DTS if they are on different servers.

The trick is to copy data until the copy fails (due to the problem with the disk), then find a way to resume the copy just past the problem. The easiest way to do this is using PK values to copy what you can, then move a few PK values higher and start again. If there was only one flaw, then you can copy from the low PK values up, then from the high PK values down and you will have all of the recoverable data. If you have more than one flaw, then you'll have to fuss with the copy a bit, trying to "jump" the flaws.

-PatPsql

No comments:

Post a Comment