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.codecomments.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/d...serr_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.codecomments.com ***
>|||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.codecomments.com ***|||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.
Darin
*** Sent via Developersdex http://www.codecomments.com ***|||If the error followed the files then the database itself is corrupt and
nothing is going to fix it other than starting over. Reinitializing
replication can take a long time but it beats waiting for a miracle healing
which isn't likely to happen.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Darin" <darin_nospam@.nospamever> wrote in message
news:OtztSrPBHHA.1196@.TK2MSFTNGP03.phx.gbl...
> 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.codecomments.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.codecomments.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.codecomments.com ***