The following messages seems happen every two weeks. it may cause by hardware
error, but HP Array Utility hasn't detected any error. Any ideas, does it
make sense to move database to the local hard drive?
Error: 823, Severity: 24, State: 2
I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
Data:Words
0000: 00000337 00000018 00000009 00550053
0010: 0044004e 00540041 00310041 00070000
0020: 00530000 004e0055 00440035 00000042
SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA 1000,
the database is on SAN disks.Sounds like you may have some corruption in the database.
Try running the DBCC CHECKCATALOG and see what you get back. BOL has some
great suggestions on the usage as well as some others like DBCC CHECKTABLE
and DBCC CHECKxxxxxx
Rick Sawtell
MCT, MCSD, MCDBA
"Joshua" <Joshua@.discussions.microsoft.com> wrote in message
news:A1DF380C-CB99-4125-A713-7E14303C6125@.microsoft.com...
> The following messages seems happen every two weeks. it may cause by
> hardware
> error, but HP Array Utility hasn't detected any error. Any ideas, does it
> make sense to move database to the local hard drive?
> Error: 823, Severity: 24, State: 2
> I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
> file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
> Data:Words
> 0000: 00000337 00000018 00000009 00550053
> 0010: 0044004e 00540041 00310041 00070000
> 0020: 00530000 004e0055 00440035 00000042
> SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA
> 1000,
> the database is on SAN disks.
Showing posts with label hardware. Show all posts
Showing posts with label hardware. Show all posts
Monday, March 26, 2012
Error 823, Severity 24, State 2
Here is my problem:
About a month ago or so, I had some hardware problems with a dell server
running sharepoint portal server and SQL 2000 on the same server where the
server just died a couple of times requiring restart. We got the hardware
problems resolved, and at first, we had some errors about torn pages and
database suspect and we restored from a backup. Databases were no longer in
suspect mode and everything looked fine.
A couple of days ago, while looking at possibly moving the SQL databases to
a SQL cluster we have, I noticed that we are getting some errors while
performing certain actions on the server.
First, if I try to go and do a SQL backup from within SQL Enterprise
manager, I get:
Error 823: I/O error (torn page) detected during read at offset
0x00000000b18000 in file 'e:\Program files\microsoft SQL
server\mssql\data\<database name>'
Here is the kicker... this happens on EVERY database on that server at same
offset, and then it gets me into the sql server backup window to do the
backup. The backup goes fine and then I get another I/O error (without the
Error 823 in front) at the same offset.
The error that is logged in the eventviewer is
Event ID: 17052
Error: 823, severity: 24, State:2
I/O error (torn page) detected during read at offset 0x00000000b18000 in
file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
I have tried the following:
DBCC CHECKDB returns the following:
DBCC results for 'SSO'.
DBCC results for 'sysobjects'.
There are 61 rows in 1 pages for object 'sysobjects'.
..
..
DBCC results for 'SSO_Config'.
There are 1 rows in 1 pages for object 'SSO_Config'
CHECKDB found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
I ran DBCC CHECKCATALOG on some of the databases and got the following:
DBCC results for 'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Also ran DBCC CHECKALLOC and got:
CHECKALLOC found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
So it seems as if everything is fine. People connect to the databases
through Sharepoint, and that seems to be working fine.
If someone could shed some light on this problem and how to correct, that
would be awesome and i would be very greatful.
Thank you in advance.
Chuck
You should contact Dell for the utilities to perform full hardware
diagnostics on the server.
The following KB's explain how to turn on an additional trace flag that will
allow you to gather more information when 823 errors occur
http://support.microsoft.com/default...b;en-us;828339
http://support.microsoft.com/default...b;en-us;826433
Also, make sure that if you're using /PAE, you have the appropriate
hotfix/patches at the OS level to prevent issues like memory corruption
http://support.microsoft.com/default...b;en-us;838765
You can also run SQLIOStress to simulate a load to determine if you may have
hardware issues
http://support.microsoft.com/default...22120121120120
HTH.
"msnews.microsoft.com" <nonya@.bid.edu> wrote in message
news:eG%23mqey2FHA.1716@.TK2MSFTNGP10.phx.gbl...
> Here is my problem:
> About a month ago or so, I had some hardware problems with a dell server
> running sharepoint portal server and SQL 2000 on the same server where the
> server just died a couple of times requiring restart. We got the hardware
> problems resolved, and at first, we had some errors about torn pages and
> database suspect and we restored from a backup. Databases were no longer
> in suspect mode and everything looked fine.
> A couple of days ago, while looking at possibly moving the SQL databases
> to a SQL cluster we have, I noticed that we are getting some errors while
> performing certain actions on the server.
> First, if I try to go and do a SQL backup from within SQL Enterprise
> manager, I get:
> Error 823: I/O error (torn page) detected during read at offset
> 0x00000000b18000 in file 'e:\Program files\microsoft SQL
> server\mssql\data\<database name>'
> Here is the kicker... this happens on EVERY database on that server at
> same offset, and then it gets me into the sql server backup window to do
> the backup. The backup goes fine and then I get another I/O error
> (without the Error 823 in front) at the same offset.
> The error that is logged in the eventviewer is
> Event ID: 17052
> Error: 823, severity: 24, State:2
> I/O error (torn page) detected during read at offset 0x00000000b18000 in
> file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
> I have tried the following:
> DBCC CHECKDB returns the following:
> DBCC results for 'SSO'.
> DBCC results for 'sysobjects'.
> There are 61 rows in 1 pages for object 'sysobjects'.
> .
> .
> DBCC results for 'SSO_Config'.
> There are 1 rows in 1 pages for object 'SSO_Config'
> CHECKDB found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> I ran DBCC CHECKCATALOG on some of the databases and got the following:
> DBCC results for 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> Also ran DBCC CHECKALLOC and got:
> CHECKALLOC found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> So it seems as if everything is fine. People connect to the databases
> through Sharepoint, and that seems to be working fine.
> If someone could shed some light on this problem and how to correct, that
> would be awesome and i would be very greatful.
> Thank you in advance.
> Chuck
>
sql
About a month ago or so, I had some hardware problems with a dell server
running sharepoint portal server and SQL 2000 on the same server where the
server just died a couple of times requiring restart. We got the hardware
problems resolved, and at first, we had some errors about torn pages and
database suspect and we restored from a backup. Databases were no longer in
suspect mode and everything looked fine.
A couple of days ago, while looking at possibly moving the SQL databases to
a SQL cluster we have, I noticed that we are getting some errors while
performing certain actions on the server.
First, if I try to go and do a SQL backup from within SQL Enterprise
manager, I get:
Error 823: I/O error (torn page) detected during read at offset
0x00000000b18000 in file 'e:\Program files\microsoft SQL
server\mssql\data\<database name>'
Here is the kicker... this happens on EVERY database on that server at same
offset, and then it gets me into the sql server backup window to do the
backup. The backup goes fine and then I get another I/O error (without the
Error 823 in front) at the same offset.
The error that is logged in the eventviewer is
Event ID: 17052
Error: 823, severity: 24, State:2
I/O error (torn page) detected during read at offset 0x00000000b18000 in
file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
I have tried the following:
DBCC CHECKDB returns the following:
DBCC results for 'SSO'.
DBCC results for 'sysobjects'.
There are 61 rows in 1 pages for object 'sysobjects'.
..
..
DBCC results for 'SSO_Config'.
There are 1 rows in 1 pages for object 'SSO_Config'
CHECKDB found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
I ran DBCC CHECKCATALOG on some of the databases and got the following:
DBCC results for 'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Also ran DBCC CHECKALLOC and got:
CHECKALLOC found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
So it seems as if everything is fine. People connect to the databases
through Sharepoint, and that seems to be working fine.
If someone could shed some light on this problem and how to correct, that
would be awesome and i would be very greatful.
Thank you in advance.
Chuck
You should contact Dell for the utilities to perform full hardware
diagnostics on the server.
The following KB's explain how to turn on an additional trace flag that will
allow you to gather more information when 823 errors occur
http://support.microsoft.com/default...b;en-us;828339
http://support.microsoft.com/default...b;en-us;826433
Also, make sure that if you're using /PAE, you have the appropriate
hotfix/patches at the OS level to prevent issues like memory corruption
http://support.microsoft.com/default...b;en-us;838765
You can also run SQLIOStress to simulate a load to determine if you may have
hardware issues
http://support.microsoft.com/default...22120121120120
HTH.
"msnews.microsoft.com" <nonya@.bid.edu> wrote in message
news:eG%23mqey2FHA.1716@.TK2MSFTNGP10.phx.gbl...
> Here is my problem:
> About a month ago or so, I had some hardware problems with a dell server
> running sharepoint portal server and SQL 2000 on the same server where the
> server just died a couple of times requiring restart. We got the hardware
> problems resolved, and at first, we had some errors about torn pages and
> database suspect and we restored from a backup. Databases were no longer
> in suspect mode and everything looked fine.
> A couple of days ago, while looking at possibly moving the SQL databases
> to a SQL cluster we have, I noticed that we are getting some errors while
> performing certain actions on the server.
> First, if I try to go and do a SQL backup from within SQL Enterprise
> manager, I get:
> Error 823: I/O error (torn page) detected during read at offset
> 0x00000000b18000 in file 'e:\Program files\microsoft SQL
> server\mssql\data\<database name>'
> Here is the kicker... this happens on EVERY database on that server at
> same offset, and then it gets me into the sql server backup window to do
> the backup. The backup goes fine and then I get another I/O error
> (without the Error 823 in front) at the same offset.
> The error that is logged in the eventviewer is
> Event ID: 17052
> Error: 823, severity: 24, State:2
> I/O error (torn page) detected during read at offset 0x00000000b18000 in
> file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
> I have tried the following:
> DBCC CHECKDB returns the following:
> DBCC results for 'SSO'.
> DBCC results for 'sysobjects'.
> There are 61 rows in 1 pages for object 'sysobjects'.
> .
> .
> DBCC results for 'SSO_Config'.
> There are 1 rows in 1 pages for object 'SSO_Config'
> CHECKDB found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> I ran DBCC CHECKCATALOG on some of the databases and got the following:
> DBCC results for 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> Also ran DBCC CHECKALLOC and got:
> CHECKALLOC found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> So it seems as if everything is fine. People connect to the databases
> through Sharepoint, and that seems to be working fine.
> If someone could shed some light on this problem and how to correct, that
> would be awesome and i would be very greatful.
> Thank you in advance.
> Chuck
>
sql
Error 823, Severity 24, State 2
Here is my problem:
About a month ago or so, I had some hardware problems with a dell server
running sharepoint portal server and SQL 2000 on the same server where the
server just died a couple of times requiring restart. We got the hardware
problems resolved, and at first, we had some errors about torn pages and
database suspect and we restored from a backup. Databases were no longer in
suspect mode and everything looked fine.
A couple of days ago, while looking at possibly moving the SQL databases to
a SQL cluster we have, I noticed that we are getting some errors while
performing certain actions on the server.
First, if I try to go and do a SQL backup from within SQL Enterprise
manager, I get:
Error 823: I/O error (torn page) detected during read at offset
0x00000000b18000 in file 'e:\Program files\microsoft SQL
server\mssql\data\<database name>'
Here is the kicker... this happens on EVERY database on that server at same
offset, and then it gets me into the sql server backup window to do the
backup. The backup goes fine and then I get another I/O error (without the
Error 823 in front) at the same offset.
The error that is logged in the eventviewer is
Event ID: 17052
Error: 823, severity: 24, State:2
I/O error (torn page) detected during read at offset 0x00000000b18000 in
file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
I have tried the following:
DBCC CHECKDB returns the following:
DBCC results for 'SSO'.
DBCC results for 'sysobjects'.
There are 61 rows in 1 pages for object 'sysobjects'.
.
.
DBCC results for 'SSO_Config'.
There are 1 rows in 1 pages for object 'SSO_Config'
CHECKDB found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
I ran DBCC CHECKCATALOG on some of the databases and got the following:
DBCC results for 'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Also ran DBCC CHECKALLOC and got:
CHECKALLOC found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
So it seems as if everything is fine. People connect to the databases
through Sharepoint, and that seems to be working fine.
If someone could shed some light on this problem and how to correct, that
would be awesome and i would be very greatful.
Thank you in advance.
ChuckYou should contact Dell for the utilities to perform full hardware
diagnostics on the server.
The following KB's explain how to turn on an additional trace flag that will
allow you to gather more information when 823 errors occur
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
http://support.microsoft.com/default.aspx?scid=kb;en-us;826433
Also, make sure that if you're using /PAE, you have the appropriate
hotfix/patches at the OS level to prevent issues like memory corruption
http://support.microsoft.com/default.aspx?scid=kb;en-us;838765
You can also run SQLIOStress to simulate a load to determine if you may have
hardware issues
http://support.microsoft.com/default.aspx?scid=kb;en-us;231619#XSLTH4300121122120121120120
HTH.
"msnews.microsoft.com" <nonya@.bid.edu> wrote in message
news:eG%23mqey2FHA.1716@.TK2MSFTNGP10.phx.gbl...
> Here is my problem:
> About a month ago or so, I had some hardware problems with a dell server
> running sharepoint portal server and SQL 2000 on the same server where the
> server just died a couple of times requiring restart. We got the hardware
> problems resolved, and at first, we had some errors about torn pages and
> database suspect and we restored from a backup. Databases were no longer
> in suspect mode and everything looked fine.
> A couple of days ago, while looking at possibly moving the SQL databases
> to a SQL cluster we have, I noticed that we are getting some errors while
> performing certain actions on the server.
> First, if I try to go and do a SQL backup from within SQL Enterprise
> manager, I get:
> Error 823: I/O error (torn page) detected during read at offset
> 0x00000000b18000 in file 'e:\Program files\microsoft SQL
> server\mssql\data\<database name>'
> Here is the kicker... this happens on EVERY database on that server at
> same offset, and then it gets me into the sql server backup window to do
> the backup. The backup goes fine and then I get another I/O error
> (without the Error 823 in front) at the same offset.
> The error that is logged in the eventviewer is
> Event ID: 17052
> Error: 823, severity: 24, State:2
> I/O error (torn page) detected during read at offset 0x00000000b18000 in
> file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
> I have tried the following:
> DBCC CHECKDB returns the following:
> DBCC results for 'SSO'.
> DBCC results for 'sysobjects'.
> There are 61 rows in 1 pages for object 'sysobjects'.
> .
> .
> DBCC results for 'SSO_Config'.
> There are 1 rows in 1 pages for object 'SSO_Config'
> CHECKDB found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> I ran DBCC CHECKCATALOG on some of the databases and got the following:
> DBCC results for 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> Also ran DBCC CHECKALLOC and got:
> CHECKALLOC found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> So it seems as if everything is fine. People connect to the databases
> through Sharepoint, and that seems to be working fine.
> If someone could shed some light on this problem and how to correct, that
> would be awesome and i would be very greatful.
> Thank you in advance.
> Chuck
>
About a month ago or so, I had some hardware problems with a dell server
running sharepoint portal server and SQL 2000 on the same server where the
server just died a couple of times requiring restart. We got the hardware
problems resolved, and at first, we had some errors about torn pages and
database suspect and we restored from a backup. Databases were no longer in
suspect mode and everything looked fine.
A couple of days ago, while looking at possibly moving the SQL databases to
a SQL cluster we have, I noticed that we are getting some errors while
performing certain actions on the server.
First, if I try to go and do a SQL backup from within SQL Enterprise
manager, I get:
Error 823: I/O error (torn page) detected during read at offset
0x00000000b18000 in file 'e:\Program files\microsoft SQL
server\mssql\data\<database name>'
Here is the kicker... this happens on EVERY database on that server at same
offset, and then it gets me into the sql server backup window to do the
backup. The backup goes fine and then I get another I/O error (without the
Error 823 in front) at the same offset.
The error that is logged in the eventviewer is
Event ID: 17052
Error: 823, severity: 24, State:2
I/O error (torn page) detected during read at offset 0x00000000b18000 in
file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
I have tried the following:
DBCC CHECKDB returns the following:
DBCC results for 'SSO'.
DBCC results for 'sysobjects'.
There are 61 rows in 1 pages for object 'sysobjects'.
.
.
DBCC results for 'SSO_Config'.
There are 1 rows in 1 pages for object 'SSO_Config'
CHECKDB found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
I ran DBCC CHECKCATALOG on some of the databases and got the following:
DBCC results for 'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Also ran DBCC CHECKALLOC and got:
CHECKALLOC found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
So it seems as if everything is fine. People connect to the databases
through Sharepoint, and that seems to be working fine.
If someone could shed some light on this problem and how to correct, that
would be awesome and i would be very greatful.
Thank you in advance.
ChuckYou should contact Dell for the utilities to perform full hardware
diagnostics on the server.
The following KB's explain how to turn on an additional trace flag that will
allow you to gather more information when 823 errors occur
http://support.microsoft.com/default.aspx?scid=kb;en-us;828339
http://support.microsoft.com/default.aspx?scid=kb;en-us;826433
Also, make sure that if you're using /PAE, you have the appropriate
hotfix/patches at the OS level to prevent issues like memory corruption
http://support.microsoft.com/default.aspx?scid=kb;en-us;838765
You can also run SQLIOStress to simulate a load to determine if you may have
hardware issues
http://support.microsoft.com/default.aspx?scid=kb;en-us;231619#XSLTH4300121122120121120120
HTH.
"msnews.microsoft.com" <nonya@.bid.edu> wrote in message
news:eG%23mqey2FHA.1716@.TK2MSFTNGP10.phx.gbl...
> Here is my problem:
> About a month ago or so, I had some hardware problems with a dell server
> running sharepoint portal server and SQL 2000 on the same server where the
> server just died a couple of times requiring restart. We got the hardware
> problems resolved, and at first, we had some errors about torn pages and
> database suspect and we restored from a backup. Databases were no longer
> in suspect mode and everything looked fine.
> A couple of days ago, while looking at possibly moving the SQL databases
> to a SQL cluster we have, I noticed that we are getting some errors while
> performing certain actions on the server.
> First, if I try to go and do a SQL backup from within SQL Enterprise
> manager, I get:
> Error 823: I/O error (torn page) detected during read at offset
> 0x00000000b18000 in file 'e:\Program files\microsoft SQL
> server\mssql\data\<database name>'
> Here is the kicker... this happens on EVERY database on that server at
> same offset, and then it gets me into the sql server backup window to do
> the backup. The backup goes fine and then I get another I/O error
> (without the Error 823 in front) at the same offset.
> The error that is logged in the eventviewer is
> Event ID: 17052
> Error: 823, severity: 24, State:2
> I/O error (torn page) detected during read at offset 0x00000000b18000 in
> file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
> I have tried the following:
> DBCC CHECKDB returns the following:
> DBCC results for 'SSO'.
> DBCC results for 'sysobjects'.
> There are 61 rows in 1 pages for object 'sysobjects'.
> .
> .
> DBCC results for 'SSO_Config'.
> There are 1 rows in 1 pages for object 'SSO_Config'
> CHECKDB found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> I ran DBCC CHECKCATALOG on some of the databases and got the following:
> DBCC results for 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> Also ran DBCC CHECKALLOC and got:
> CHECKALLOC found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> So it seems as if everything is fine. People connect to the databases
> through Sharepoint, and that seems to be working fine.
> If someone could shed some light on this problem and how to correct, that
> would be awesome and i would be very greatful.
> Thank you in advance.
> Chuck
>
Error 823, Severity 24, State 2
Here is my problem:
About a month ago or so, I had some hardware problems with a dell server
running sharepoint portal server and SQL 2000 on the same server where the
server just died a couple of times requiring restart. We got the hardware
problems resolved, and at first, we had some errors about torn pages and
database suspect and we restored from a backup. Databases were no longer in
suspect mode and everything looked fine.
A couple of days ago, while looking at possibly moving the SQL databases to
a SQL cluster we have, I noticed that we are getting some errors while
performing certain actions on the server.
First, if I try to go and do a SQL backup from within SQL Enterprise
manager, I get:
Error 823: I/O error (torn page) detected during read at offset
0x00000000b18000 in file 'e:\Program files\microsoft SQL
server\mssql\data\<database name>'
Here is the kicker... this happens on EVERY database on that server at same
offset, and then it gets me into the sql server backup window to do the
backup. The backup goes fine and then I get another I/O error (without the
Error 823 in front) at the same offset.
The error that is logged in the eventviewer is
Event ID: 17052
Error: 823, severity: 24, State:2
I/O error (torn page) detected during read at offset 0x00000000b18000 in
file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
I have tried the following:
DBCC CHECKDB returns the following:
DBCC results for 'SSO'.
DBCC results for 'sysobjects'.
There are 61 rows in 1 pages for object 'sysobjects'.
.
.
DBCC results for 'SSO_Config'.
There are 1 rows in 1 pages for object 'SSO_Config'
CHECKDB found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
I ran DBCC CHECKCATALOG on some of the databases and got the following:
DBCC results for 'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Also ran DBCC CHECKALLOC and got:
CHECKALLOC found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
So it seems as if everything is fine. People connect to the databases
through Sharepoint, and that seems to be working fine.
If someone could shed some light on this problem and how to correct, that
would be awesome and i would be very greatful.
Thank you in advance.
ChuckYou should contact Dell for the utilities to perform full hardware
diagnostics on the server.
The following KB's explain how to turn on an additional trace flag that will
allow you to gather more information when 823 errors occur
http://support.microsoft.com/defaul...kb;en-us;828339
http://support.microsoft.com/defaul...kb;en-us;826433
Also, make sure that if you're using /PAE, you have the appropriate
hotfix/patches at the OS level to prevent issues like memory corruption
http://support.microsoft.com/defaul...kb;en-us;838765
You can also run SQLIOStress to simulate a load to determine if you may have
hardware issues
21120120" target="_blank">http://support.microsoft.com/defaul...br />
21120120
HTH.
"msnews.microsoft.com" <nonya@.bid.edu> wrote in message
news:eG%23mqey2FHA.1716@.TK2MSFTNGP10.phx.gbl...
> Here is my problem:
> About a month ago or so, I had some hardware problems with a dell server
> running sharepoint portal server and SQL 2000 on the same server where the
> server just died a couple of times requiring restart. We got the hardware
> problems resolved, and at first, we had some errors about torn pages and
> database suspect and we restored from a backup. Databases were no longer
> in suspect mode and everything looked fine.
> A couple of days ago, while looking at possibly moving the SQL databases
> to a SQL cluster we have, I noticed that we are getting some errors while
> performing certain actions on the server.
> First, if I try to go and do a SQL backup from within SQL Enterprise
> manager, I get:
> Error 823: I/O error (torn page) detected during read at offset
> 0x00000000b18000 in file 'e:\Program files\microsoft SQL
> server\mssql\data\<database name>'
> Here is the kicker... this happens on EVERY database on that server at
> same offset, and then it gets me into the sql server backup window to do
> the backup. The backup goes fine and then I get another I/O error
> (without the Error 823 in front) at the same offset.
> The error that is logged in the eventviewer is
> Event ID: 17052
> Error: 823, severity: 24, State:2
> I/O error (torn page) detected during read at offset 0x00000000b18000 in
> file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
> I have tried the following:
> DBCC CHECKDB returns the following:
> DBCC results for 'SSO'.
> DBCC results for 'sysobjects'.
> There are 61 rows in 1 pages for object 'sysobjects'.
> .
> .
> DBCC results for 'SSO_Config'.
> There are 1 rows in 1 pages for object 'SSO_Config'
> CHECKDB found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> I ran DBCC CHECKCATALOG on some of the databases and got the following:
> DBCC results for 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> Also ran DBCC CHECKALLOC and got:
> CHECKALLOC found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> So it seems as if everything is fine. People connect to the databases
> through Sharepoint, and that seems to be working fine.
> If someone could shed some light on this problem and how to correct, that
> would be awesome and i would be very greatful.
> Thank you in advance.
> Chuck
>
About a month ago or so, I had some hardware problems with a dell server
running sharepoint portal server and SQL 2000 on the same server where the
server just died a couple of times requiring restart. We got the hardware
problems resolved, and at first, we had some errors about torn pages and
database suspect and we restored from a backup. Databases were no longer in
suspect mode and everything looked fine.
A couple of days ago, while looking at possibly moving the SQL databases to
a SQL cluster we have, I noticed that we are getting some errors while
performing certain actions on the server.
First, if I try to go and do a SQL backup from within SQL Enterprise
manager, I get:
Error 823: I/O error (torn page) detected during read at offset
0x00000000b18000 in file 'e:\Program files\microsoft SQL
server\mssql\data\<database name>'
Here is the kicker... this happens on EVERY database on that server at same
offset, and then it gets me into the sql server backup window to do the
backup. The backup goes fine and then I get another I/O error (without the
Error 823 in front) at the same offset.
The error that is logged in the eventviewer is
Event ID: 17052
Error: 823, severity: 24, State:2
I/O error (torn page) detected during read at offset 0x00000000b18000 in
file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
I have tried the following:
DBCC CHECKDB returns the following:
DBCC results for 'SSO'.
DBCC results for 'sysobjects'.
There are 61 rows in 1 pages for object 'sysobjects'.
.
.
DBCC results for 'SSO_Config'.
There are 1 rows in 1 pages for object 'SSO_Config'
CHECKDB found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
I ran DBCC CHECKCATALOG on some of the databases and got the following:
DBCC results for 'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Also ran DBCC CHECKALLOC and got:
CHECKALLOC found 0 allocation errors and 0 consistency errors in database
'SSO'.
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
So it seems as if everything is fine. People connect to the databases
through Sharepoint, and that seems to be working fine.
If someone could shed some light on this problem and how to correct, that
would be awesome and i would be very greatful.
Thank you in advance.
ChuckYou should contact Dell for the utilities to perform full hardware
diagnostics on the server.
The following KB's explain how to turn on an additional trace flag that will
allow you to gather more information when 823 errors occur
http://support.microsoft.com/defaul...kb;en-us;828339
http://support.microsoft.com/defaul...kb;en-us;826433
Also, make sure that if you're using /PAE, you have the appropriate
hotfix/patches at the OS level to prevent issues like memory corruption
http://support.microsoft.com/defaul...kb;en-us;838765
You can also run SQLIOStress to simulate a load to determine if you may have
hardware issues
21120120" target="_blank">http://support.microsoft.com/defaul...br />
21120120
HTH.
"msnews.microsoft.com" <nonya@.bid.edu> wrote in message
news:eG%23mqey2FHA.1716@.TK2MSFTNGP10.phx.gbl...
> Here is my problem:
> About a month ago or so, I had some hardware problems with a dell server
> running sharepoint portal server and SQL 2000 on the same server where the
> server just died a couple of times requiring restart. We got the hardware
> problems resolved, and at first, we had some errors about torn pages and
> database suspect and we restored from a backup. Databases were no longer
> in suspect mode and everything looked fine.
> A couple of days ago, while looking at possibly moving the SQL databases
> to a SQL cluster we have, I noticed that we are getting some errors while
> performing certain actions on the server.
> First, if I try to go and do a SQL backup from within SQL Enterprise
> manager, I get:
> Error 823: I/O error (torn page) detected during read at offset
> 0x00000000b18000 in file 'e:\Program files\microsoft SQL
> server\mssql\data\<database name>'
> Here is the kicker... this happens on EVERY database on that server at
> same offset, and then it gets me into the sql server backup window to do
> the backup. The backup goes fine and then I get another I/O error
> (without the Error 823 in front) at the same offset.
> The error that is logged in the eventviewer is
> Event ID: 17052
> Error: 823, severity: 24, State:2
> I/O error (torn page) detected during read at offset 0x00000000b18000 in
> file 'e:\Program files\microsoft SQL server\mssql\data\<database name>'
> I have tried the following:
> DBCC CHECKDB returns the following:
> DBCC results for 'SSO'.
> DBCC results for 'sysobjects'.
> There are 61 rows in 1 pages for object 'sysobjects'.
> .
> .
> DBCC results for 'SSO_Config'.
> There are 1 rows in 1 pages for object 'SSO_Config'
> CHECKDB found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> I ran DBCC CHECKCATALOG on some of the databases and got the following:
> DBCC results for 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> Also ran DBCC CHECKALLOC and got:
> CHECKALLOC found 0 allocation errors and 0 consistency errors in database
> 'SSO'.
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator.
> So it seems as if everything is fine. People connect to the databases
> through Sharepoint, and that seems to be working fine.
> If someone could shed some light on this problem and how to correct, that
> would be awesome and i would be very greatful.
> Thank you in advance.
> Chuck
>
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 ***
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 ***
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/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.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 ***
>
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/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.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 ***
>
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 ***
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 ***
Error 823
Hello.
I pray to that someone can help me...
A month ago a compaq server hosting a SQL Server 2000 Server had a hardware
crash. Unfortunatly, the Compaq Smart Array was configured with RAID 0.
Aparently the problem was there a long time ago and there was not a recently
backup file. So, we've delivered the Raid System to a Recovery company.
The data was recovered, I have the .MDF and the .LDF files. The problem is,
after i attach the database to a clean instance of Sql Server, i get the
following error:
******************
Server: Msg 823, Level 24, State 2, Line 1
I/O error (bad page ID) detected during read at offset 0x0000001ef3c000 in
file 'D:\Data\database_Data.MDF'.
Connection Broken
******************
I've tried several possible solutions as CHECKDB, CHECKALLOC and so far,
with no results.
How can I resove this problem? I have read thousands of Forum messages but
i've no solution. I have read Microsoft Knowledge Base Article 826433, that
tells me that there are a build of Sql server, wich have several tools to
try to correct this problem. Tha leads me to another problem... i cannot
find that file versions.
I would thanks any solution, any help.
Regards.
Marco Pais> Hello.
> I pray to that someone can help me...
> A month ago a compaq server hosting a SQL Server 2000 Server had a
hardware
> crash. Unfortunatly, the Compaq Smart Array was configured with RAID 0.
> Aparently the problem was there a long time ago and there was not a
recently
> backup file. So, we've delivered the Raid System to a Recovery company.
> The data was recovered, I have the .MDF and the .LDF files. The problem
is,
> after i attach the database to a clean instance of Sql Server, i get the
> following error:
> ******************
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (bad page ID) detected during read at offset 0x0000001ef3c000 in
> file 'D:\Data\database_Data.MDF'.
> Connection Broken
> ******************
> I've tried several possible solutions as CHECKDB, CHECKALLOC and so far,
> with no results.
> How can I resove this problem? I have read thousands of Forum messages but
> i've no solution. I have read Microsoft Knowledge Base Article 826433,
that
> tells me that there are a build of Sql server, wich have several tools to
> try to correct this problem. Tha leads me to another problem... i cannot
> find that file versions.
> I would thanks any solution, any help.
> Regards.
> Marco Pais
>
--
Hi Marco,
There are two possibilities: either your disk media is giving you problems
restoring or your mdf file itself is corrupt beyond recovery.
Can you copy the database files to on another physical drive and then
attach from that path or from another SQL Server machine that you know has
a good healthy disk system? We are trying to eliminate your raid system as
the root cause of the Error 823.
If your database files won't attach from a clean disk system, then it is
corrupt beyond recovery. Your best option in this situation is to restore
from your last good backup.
Hope this helps,
--
Eric Cárdenas
Senior support professional
This posting is provided "AS IS" with no warranties, and confers no rights.
I pray to that someone can help me...
A month ago a compaq server hosting a SQL Server 2000 Server had a hardware
crash. Unfortunatly, the Compaq Smart Array was configured with RAID 0.
Aparently the problem was there a long time ago and there was not a recently
backup file. So, we've delivered the Raid System to a Recovery company.
The data was recovered, I have the .MDF and the .LDF files. The problem is,
after i attach the database to a clean instance of Sql Server, i get the
following error:
******************
Server: Msg 823, Level 24, State 2, Line 1
I/O error (bad page ID) detected during read at offset 0x0000001ef3c000 in
file 'D:\Data\database_Data.MDF'.
Connection Broken
******************
I've tried several possible solutions as CHECKDB, CHECKALLOC and so far,
with no results.
How can I resove this problem? I have read thousands of Forum messages but
i've no solution. I have read Microsoft Knowledge Base Article 826433, that
tells me that there are a build of Sql server, wich have several tools to
try to correct this problem. Tha leads me to another problem... i cannot
find that file versions.
I would thanks any solution, any help.
Regards.
Marco Pais> Hello.
> I pray to that someone can help me...
> A month ago a compaq server hosting a SQL Server 2000 Server had a
hardware
> crash. Unfortunatly, the Compaq Smart Array was configured with RAID 0.
> Aparently the problem was there a long time ago and there was not a
recently
> backup file. So, we've delivered the Raid System to a Recovery company.
> The data was recovered, I have the .MDF and the .LDF files. The problem
is,
> after i attach the database to a clean instance of Sql Server, i get the
> following error:
> ******************
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (bad page ID) detected during read at offset 0x0000001ef3c000 in
> file 'D:\Data\database_Data.MDF'.
> Connection Broken
> ******************
> I've tried several possible solutions as CHECKDB, CHECKALLOC and so far,
> with no results.
> How can I resove this problem? I have read thousands of Forum messages but
> i've no solution. I have read Microsoft Knowledge Base Article 826433,
that
> tells me that there are a build of Sql server, wich have several tools to
> try to correct this problem. Tha leads me to another problem... i cannot
> find that file versions.
> I would thanks any solution, any help.
> Regards.
> Marco Pais
>
--
Hi Marco,
There are two possibilities: either your disk media is giving you problems
restoring or your mdf file itself is corrupt beyond recovery.
Can you copy the database files to on another physical drive and then
attach from that path or from another SQL Server machine that you know has
a good healthy disk system? We are trying to eliminate your raid system as
the root cause of the Error 823.
If your database files won't attach from a clean disk system, then it is
corrupt beyond recovery. Your best option in this situation is to restore
from your last good backup.
Hope this helps,
--
Eric Cárdenas
Senior support professional
This posting is provided "AS IS" with no warranties, and confers no rights.
Error 823
Hello.
I pray to that someone can help me...
A month ago a compaq server hosting a SQL Server 2000 Server had a hardware
crash. Unfortunatly, the Compaq Smart Array was configured with RAID 0.
Aparently the problem was there a long time ago and there was not a recently
backup file. So, we've delivered the Raid System to a Recovery company.
The data was recovered, I have the .MDF and the .LDF files. The problem is,
after i attach the database to a clean instance of Sql Server, i get the
following error:
******************
Server: Msg 823, Level 24, State 2, Line 1
I/O error (bad page ID) detected during read at offset 0x0000001ef3c000 in
file 'D:\Data\database_Data.MDF'.
Connection Broken
******************
I've tried several possible solutions as CHECKDB, CHECKALLOC and so far,
with no results.
How can I resove this problem? I have read thousands of Forum messages but
i've no solution. I have read Microsoft Knowledge Base Article 826433, that
tells me that there are a build of Sql server, wich have several tools to
try to correct this problem. Tha leads me to another problem... i cannot
find that file versions.
I would thanks any solution, any help.
Regards.
Marco PaisPlease don't post the same question to multiple groups.
My answer from .tools:
You can't correct this error - its a hard error with the underlying disk
(i.e. the OS tells SQL Server it can't read the bytes off the disk). You'll
need to suck as much data out of the database as you can onto new media. I
would contact PSS to help you (http://support.microsoft.com)
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Marco Pais" <mpais@.foruminformatica.pt> wrote in message
news:eS4R5t2PEHA.1392@.TK2MSFTNGP09.phx.gbl...
> Hello.
> I pray to that someone can help me...
> A month ago a compaq server hosting a SQL Server 2000 Server had a
hardware
> crash. Unfortunatly, the Compaq Smart Array was configured with RAID 0.
> Aparently the problem was there a long time ago and there was not a
recently
> backup file. So, we've delivered the Raid System to a Recovery company.
> The data was recovered, I have the .MDF and the .LDF files. The problem
is,
> after i attach the database to a clean instance of Sql Server, i get the
> following error:
> ******************
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (bad page ID) detected during read at offset 0x0000001ef3c000 in
> file 'D:\Data\database_Data.MDF'.
> Connection Broken
> ******************
> I've tried several possible solutions as CHECKDB, CHECKALLOC and so far,
> with no results.
> How can I resove this problem? I have read thousands of Forum messages but
> i've no solution. I have read Microsoft Knowledge Base Article 826433,
that
> tells me that there are a build of Sql server, wich have several tools to
> try to correct this problem. Tha leads me to another problem... i cannot
> find that file versions.
> I would thanks any solution, any help.
> Regards.
> Marco Pais
>sql
I pray to that someone can help me...
A month ago a compaq server hosting a SQL Server 2000 Server had a hardware
crash. Unfortunatly, the Compaq Smart Array was configured with RAID 0.
Aparently the problem was there a long time ago and there was not a recently
backup file. So, we've delivered the Raid System to a Recovery company.
The data was recovered, I have the .MDF and the .LDF files. The problem is,
after i attach the database to a clean instance of Sql Server, i get the
following error:
******************
Server: Msg 823, Level 24, State 2, Line 1
I/O error (bad page ID) detected during read at offset 0x0000001ef3c000 in
file 'D:\Data\database_Data.MDF'.
Connection Broken
******************
I've tried several possible solutions as CHECKDB, CHECKALLOC and so far,
with no results.
How can I resove this problem? I have read thousands of Forum messages but
i've no solution. I have read Microsoft Knowledge Base Article 826433, that
tells me that there are a build of Sql server, wich have several tools to
try to correct this problem. Tha leads me to another problem... i cannot
find that file versions.
I would thanks any solution, any help.
Regards.
Marco PaisPlease don't post the same question to multiple groups.
My answer from .tools:
You can't correct this error - its a hard error with the underlying disk
(i.e. the OS tells SQL Server it can't read the bytes off the disk). You'll
need to suck as much data out of the database as you can onto new media. I
would contact PSS to help you (http://support.microsoft.com)
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Marco Pais" <mpais@.foruminformatica.pt> wrote in message
news:eS4R5t2PEHA.1392@.TK2MSFTNGP09.phx.gbl...
> Hello.
> I pray to that someone can help me...
> A month ago a compaq server hosting a SQL Server 2000 Server had a
hardware
> crash. Unfortunatly, the Compaq Smart Array was configured with RAID 0.
> Aparently the problem was there a long time ago and there was not a
recently
> backup file. So, we've delivered the Raid System to a Recovery company.
> The data was recovered, I have the .MDF and the .LDF files. The problem
is,
> after i attach the database to a clean instance of Sql Server, i get the
> following error:
> ******************
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (bad page ID) detected during read at offset 0x0000001ef3c000 in
> file 'D:\Data\database_Data.MDF'.
> Connection Broken
> ******************
> I've tried several possible solutions as CHECKDB, CHECKALLOC and so far,
> with no results.
> How can I resove this problem? I have read thousands of Forum messages but
> i've no solution. I have read Microsoft Knowledge Base Article 826433,
that
> tells me that there are a build of Sql server, wich have several tools to
> try to correct this problem. Tha leads me to another problem... i cannot
> find that file versions.
> I would thanks any solution, any help.
> Regards.
> Marco Pais
>sql
Subscribe to:
Posts (Atom)