Error 823 (customer is down)

Ok, I know an 823 is a hardware error.
I detached the database, then I copied all *.*DF to another directory. I
then tried to attached the database from that new location and received:
Error 823: I/O error (bad page ID) deteced during read at offset
0x0000003e17x000 in file 'filename'
WHen I try to connect using the original directory, I receive the same
message.
I did get a message while I was detaching that it couldn't close the
database cleanly, and that the detach failed, but then the database
wasn't visible in EM, so I assumed it was really detached.
What are my options besides restoring the database?
Darin
*** Sent via Developersdex http://www.developersdex.com ***Hi Darin
This sounds like the files themselves may be corrupted, if you have a recent
backup you may have to go back to that.
Check out
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_1_2a0j.asp
http://msdn2.microsoft.com/en-us/library/aa337267.aspx
If you are sure the hardware is ok and don't have a backup and the filename
is the log file, you may want to rename the log file and try attaching the
data file only see sp_attach_single_file_db kin books online, otherwise a
call to PSS may be the best and quickest option.
John
"Darin" wrote:
> Ok, I know an 823 is a hardware error.
> I detached the database, then I copied all *.*DF to another directory. I
> then tried to attached the database from that new location and received:
> Error 823: I/O error (bad page ID) deteced during read at offset
> 0x0000003e17x000 in file 'filename'
> WHen I try to connect using the original directory, I receive the same
> message.
> I did get a message while I was detaching that it couldn't close the
> database cleanly, and that the detach failed, but then the database
> wasn't visible in EM, so I assumed it was really detached.
> What are my options besides restoring the database?
> Darin
> *** Sent via Developersdex http://www.developersdex.com ***
>|||Hi
Before in-initialising replication make sure you know what caused the
problem and that it is cured!
John
"Darin" wrote:
> The local system doesn't have a backup. This is a subscriber in a
> replication environment, so I can copy the data from the main server
> (very time comsuming).
> Also, the links you sent are to run dbcc checkdb, but I can't attache
> the DB therefore I can't run checkdb.
> Also, the file that is returning the error isn't the log, it is the main
> MDF (1 mdf, 7 ndf, 1 ldf).
> Darin
> *** Sent via Developersdex http://www.developersdex.com ***
>|||Hi Darin
Before snap-shotting your subscriber, you might look into whether the 823
error has corrupted a page owned by a non-clustered index or a table
(clustered index or heap). If the page is owned by an non-clustered index,
you simply rebuild the index. If the page is owned up a table, you might
remove that table from the publication & re-snapshot the individual table in
its own publication..
Regards,
Greg Linwood
SQL Server MVP
http://blogs.sqlserver.org.au/blogs/greg_linwood
"Darin" <darin_nospam@.nospamever> wrote in message
news:umE28vOBHHA.2316@.TK2MSFTNGP04.phx.gbl...
> Ok, I know an 823 is a hardware error.
> I detached the database, then I copied all *.*DF to another directory. I
> then tried to attached the database from that new location and received:
> Error 823: I/O error (bad page ID) deteced during read at offset
> 0x0000003e17x000 in file 'filename'
> WHen I try to connect using the original directory, I receive the same
> message.
> I did get a message while I was detaching that it couldn't close the
> database cleanly, and that the detach failed, but then the database
> wasn't visible in EM, so I assumed it was really detached.
> What are my options besides restoring the database?
> Darin
> *** Sent via Developersdex http://www.developersdex.com ***