Yesterday, we noticed that one of our RAID 5 drives failed.
Then, I got the following errors when I ran the DBCC Checkdb on my database.
Server: Msg 2533, Level 16, State 1, Line 1
Table error: Page (1:199065) allocated to object ID 1006626629, index ID 0
was not seen. Page may be invalid or have incorrect object ID information
in its header.
Server: Msg 2533, Level 16, State 1, Line 1
Table error: Page (1:199066) allocated to object ID 1006626629, index ID 0
was not seen. Page may be invalid or have incorrect object ID information
in its header.
Server: Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 1006626629, index ID 1. Page (1:199065) was not seen
in the scan although its parent (1:198489) and previous (1:199064) refer to
it. Check any previous errors.
Server: Msg 8980, Level 16, State 1, Line 1
Table error: Object ID 1006626629, index ID 1. Index node page (1:198489),
slot 177 refers to child page (1:199066) and previous child (1:199065), but
they were not encountered.
Server: Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 1006626629, index ID 1. Page (1:199067) is missing a
reference from previous page (1:199066). Possible chain linkage problem.
CHECKDB found 0 allocation errors and 5 consistency errors in table
'INT_AUX_LST_CUSTOM' (object ID 1006626629).
CHECKDB found 0 allocation errors and 5 consistency errors in database
'sca_master'.
repair_allow_data_loss is the minimum repair level for the errors found by
DBCC CHECKDB (sca_master ).
I found nothing on error 2533.
I found the following on other errors and suggest that these errors were
correctd in service pack 1. However, I am already running SQL SERVER SP3,
with hotfix.
http://support.microsoft.com/defaul...kb;EN-US;291566
I think the above errors occurred because of the drive failure. We replace
the failed drive but these errors are still coming up.
The server is still online and being used by the users.
Questions:
If I run the DBCC CHECKDB with repair_allow_data_loss option, is there
any way of finding how much data is lost?
Is there any way to avoid no data loss?
Thanks in advance.
Prasad KoukuntlaBTW, we running the following version
Microsoft SQL Server 2000 - 8.00.818 (Intel X86)
May 31 2003 16:08:15
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
"Prasad Koukuntla" <prasad.koukuntla@.scapromo.com> wrote in message
news:erelMZDDEHA.3784@.TK2MSFTNGP10.phx.gbl...
> Yesterday, we noticed that one of our RAID 5 drives failed.
> Then, I got the following errors when I ran the DBCC Checkdb on my
database.
> Server: Msg 2533, Level 16, State 1, Line 1
> Table error: Page (1:199065) allocated to object ID 1006626629, index ID 0
> was not seen. Page may be invalid or have incorrect object ID information
> in its header.
> Server: Msg 2533, Level 16, State 1, Line 1
> Table error: Page (1:199066) allocated to object ID 1006626629, index ID 0
> was not seen. Page may be invalid or have incorrect object ID information
> in its header.
> Server: Msg 8976, Level 16, State 1, Line 1
> Table error: Object ID 1006626629, index ID 1. Page (1:199065) was not
seen
> in the scan although its parent (1:198489) and previous (1:199064) refer
to
> it. Check any previous errors.
> Server: Msg 8980, Level 16, State 1, Line 1
> Table error: Object ID 1006626629, index ID 1. Index node page (1:198489),
> slot 177 refers to child page (1:199066) and previous child (1:199065),
but
> they were not encountered.
> Server: Msg 8978, Level 16, State 1, Line 1
> Table error: Object ID 1006626629, index ID 1. Page (1:199067) is missing
a
> reference from previous page (1:199066). Possible chain linkage problem.
> CHECKDB found 0 allocation errors and 5 consistency errors in table
> 'INT_AUX_LST_CUSTOM' (object ID 1006626629).
> CHECKDB found 0 allocation errors and 5 consistency errors in database
> 'sca_master'.
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKDB (sca_master ).
>
> I found nothing on error 2533.
> I found the following on other errors and suggest that these errors were
> correctd in service pack 1. However, I am already running SQL SERVER SP3,
> with hotfix.
> http://support.microsoft.com/defaul...kb;EN-US;291566
> I think the above errors occurred because of the drive failure. We replace
> the failed drive but these errors are still coming up.
> The server is still online and being used by the users.
> Questions:
> If I run the DBCC CHECKDB with repair_allow_data_loss option, is there
> any way of finding how much data is lost?
> Is there any way to avoid no data loss?
> Thanks in advance.
> Prasad Koukuntla
>
>
>|||Here's a start if you have corruption of a suspect database:
http://www.karaszi.com/sqlserver/in..._suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Prasad Koukuntla" <prasad.koukuntla@.scapromo.com> wrote in message
news:erelMZDDEHA.3784@.TK2MSFTNGP10.phx.gbl...
> Yesterday, we noticed that one of our RAID 5 drives failed.
> Then, I got the following errors when I ran the DBCC Checkdb on my
database.
> Server: Msg 2533, Level 16, State 1, Line 1
> Table error: Page (1:199065) allocated to object ID 1006626629, index ID 0
> was not seen. Page may be invalid or have incorrect object ID information
> in its header.
> Server: Msg 2533, Level 16, State 1, Line 1
> Table error: Page (1:199066) allocated to object ID 1006626629, index ID 0
> was not seen. Page may be invalid or have incorrect object ID information
> in its header.
> Server: Msg 8976, Level 16, State 1, Line 1
> Table error: Object ID 1006626629, index ID 1. Page (1:199065) was not
seen
> in the scan although its parent (1:198489) and previous (1:199064) refer
to
> it. Check any previous errors.
> Server: Msg 8980, Level 16, State 1, Line 1
> Table error: Object ID 1006626629, index ID 1. Index node page (1:198489),
> slot 177 refers to child page (1:199066) and previous child (1:199065),
but
> they were not encountered.
> Server: Msg 8978, Level 16, State 1, Line 1
> Table error: Object ID 1006626629, index ID 1. Page (1:199067) is missing
a
> reference from previous page (1:199066). Possible chain linkage problem.
> CHECKDB found 0 allocation errors and 5 consistency errors in table
> 'INT_AUX_LST_CUSTOM' (object ID 1006626629).
> CHECKDB found 0 allocation errors and 5 consistency errors in database
> 'sca_master'.
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKDB (sca_master ).
>
> I found nothing on error 2533.
> I found the following on other errors and suggest that these errors were
> correctd in service pack 1. However, I am already running SQL SERVER SP3,
> with hotfix.
> http://support.microsoft.com/defaul...kb;EN-US;291566
> I think the above errors occurred because of the drive failure. We replace
> the failed drive but these errors are still coming up.
> The server is still online and being used by the users.
> Questions:
> If I run the DBCC CHECKDB with repair_allow_data_loss option, is there
> any way of finding how much data is lost?
> Is there any way to avoid no data loss?
> Thanks in advance.
> Prasad Koukuntla
>
>
>|||Thank you Tibor.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:%23SPFgdDDEHA.2804@.tk2msftngp13.phx.gbl...
> Here's a start if you have corruption of a suspect database:
> http://www.karaszi.com/sqlserver/in..._suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Prasad Koukuntla" <prasad.koukuntla@.scapromo.com> wrote in message
> news:erelMZDDEHA.3784@.TK2MSFTNGP10.phx.gbl...
> database.
0
information
0
information
> seen
> to
(1:198489),
> but
missing
> a
by
SP3,
replace
there
>|||Tibor,
I tried the repair_allow_data_loss option with DBCC CHECKDB but that did not
fix all errors.
I was able to drop and recreate the table and its indexes. I copied the
data back into the table. However, there was minor data loss (74 records).
This is better than losing a day's worth of data. I may be able recover this
data as the subscribers may have this data.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:%23SPFgdDDEHA.2804@.tk2msftngp13.phx.gbl...
> Here's a start if you have corruption of a suspect database:
> http://www.karaszi.com/sqlserver/in..._suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Prasad Koukuntla" <prasad.koukuntla@.scapromo.com> wrote in message
> news:erelMZDDEHA.3784@.TK2MSFTNGP10.phx.gbl...
> database.
0
information
0
information
> seen
> to
(1:198489),
> but
missing
> a
by
SP3,
replace
there
>
Showing posts with label raid. Show all posts
Showing posts with label raid. Show all posts
Friday, February 17, 2012
DBCC CHECKDB error resolved with dbreindex - safe?
We had a hard drive failure in one of our RAID arrays. We've resolved the
hardware issue; however, DBCC CHECKDB is showing errors in at least some of
our databases. The way we structure our databases is with two data files,
the second containing all of our table indexes. The RAID array that failed
contained these "index-only" data files.
Since DBCC CHECKDB reported that the minimum repair option would be
'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database from
our last full plus differential backups. It's approximately 45 databases,
and I was hoping to avoid this.
Since CHECKDB seems to be reporting an error on only a single table in each
database AND the hardware failure was on the array that contains only
indexes, I thought simply reindexing the table reporting an error might be
an option. So I took one of the databases showing an error and reindexed
the offending table with DBCC DBREINDEX. It completed successfully, so I
reran the DBCC CHECKDB and it reported no errors.
I realize restoring from backups might be the safest route to go, but if I
only reindex a table and the dbcc checkdb comes up clean, am I at risk for
any data loss?
I appreciate your insight on this situation.
Thanks
-joeIf the error was in the index then rebuilding the index will in most cases
fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
from scratch. So as long as there are no hardware issues to prevent a clean
rebuild you should be OK. The problem comes into play more when it is data
corruption than indexes.
Andrew J. Kelly SQL MVP
"Joe Ross" <joeross7@.hotmail.com> wrote in message
news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
> We had a hard drive failure in one of our RAID arrays. We've resolved the
> hardware issue; however, DBCC CHECKDB is showing errors in at least some
> of our databases. The way we structure our databases is with two data
> files, the second containing all of our table indexes. The RAID array
> that failed contained these "index-only" data files.
> Since DBCC CHECKDB reported that the minimum repair option would be
> 'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database
> from our last full plus differential backups. It's approximately 45
> databases, and I was hoping to avoid this.
> Since CHECKDB seems to be reporting an error on only a single table in
> each database AND the hardware failure was on the array that contains only
> indexes, I thought simply reindexing the table reporting an error might be
> an option. So I took one of the databases showing an error and reindexed
> the offending table with DBCC DBREINDEX. It completed successfully, so I
> reran the DBCC CHECKDB and it reported no errors.
> I realize restoring from backups might be the safest route to go, but if I
> only reindex a table and the dbcc checkdb comes up clean, am I at risk for
> any data loss?
> I appreciate your insight on this situation.
> Thanks
> -joe
>|||Thank you. This is how I understood it, but it's reassuring to get
confirmation from an expert.
Much appreciated,
-joe
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ej%23s64F7FHA.2484@.TK2MSFTNGP10.phx.gbl...
> If the error was in the index then rebuilding the index will in most cases
> fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
> from scratch. So as long as there are no hardware issues to prevent a
> clean rebuild you should be OK. The problem comes into play more when it
> is data corruption than indexes.
> --
> Andrew J. Kelly SQL MVP
>
> "Joe Ross" <joeross7@.hotmail.com> wrote in message
> news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
>|||Andrew, There's another SQL 2005 launch event December 19th in Waltham if
you'd care to post it on NESQL.
Please email me if you'd like more details.
--
burt_king@.yahoo.com
"Joe Ross" wrote:
> Thank you. This is how I understood it, but it's reassuring to get
> confirmation from an expert.
> Much appreciated,
> -joe
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ej%23s64F7FHA.2484@.TK2MSFTNGP10.phx.gbl...
>
>
hardware issue; however, DBCC CHECKDB is showing errors in at least some of
our databases. The way we structure our databases is with two data files,
the second containing all of our table indexes. The RAID array that failed
contained these "index-only" data files.
Since DBCC CHECKDB reported that the minimum repair option would be
'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database from
our last full plus differential backups. It's approximately 45 databases,
and I was hoping to avoid this.
Since CHECKDB seems to be reporting an error on only a single table in each
database AND the hardware failure was on the array that contains only
indexes, I thought simply reindexing the table reporting an error might be
an option. So I took one of the databases showing an error and reindexed
the offending table with DBCC DBREINDEX. It completed successfully, so I
reran the DBCC CHECKDB and it reported no errors.
I realize restoring from backups might be the safest route to go, but if I
only reindex a table and the dbcc checkdb comes up clean, am I at risk for
any data loss?
I appreciate your insight on this situation.
Thanks
-joeIf the error was in the index then rebuilding the index will in most cases
fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
from scratch. So as long as there are no hardware issues to prevent a clean
rebuild you should be OK. The problem comes into play more when it is data
corruption than indexes.
Andrew J. Kelly SQL MVP
"Joe Ross" <joeross7@.hotmail.com> wrote in message
news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
> We had a hard drive failure in one of our RAID arrays. We've resolved the
> hardware issue; however, DBCC CHECKDB is showing errors in at least some
> of our databases. The way we structure our databases is with two data
> files, the second containing all of our table indexes. The RAID array
> that failed contained these "index-only" data files.
> Since DBCC CHECKDB reported that the minimum repair option would be
> 'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database
> from our last full plus differential backups. It's approximately 45
> databases, and I was hoping to avoid this.
> Since CHECKDB seems to be reporting an error on only a single table in
> each database AND the hardware failure was on the array that contains only
> indexes, I thought simply reindexing the table reporting an error might be
> an option. So I took one of the databases showing an error and reindexed
> the offending table with DBCC DBREINDEX. It completed successfully, so I
> reran the DBCC CHECKDB and it reported no errors.
> I realize restoring from backups might be the safest route to go, but if I
> only reindex a table and the dbcc checkdb comes up clean, am I at risk for
> any data loss?
> I appreciate your insight on this situation.
> Thanks
> -joe
>|||Thank you. This is how I understood it, but it's reassuring to get
confirmation from an expert.
Much appreciated,
-joe
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ej%23s64F7FHA.2484@.TK2MSFTNGP10.phx.gbl...
> If the error was in the index then rebuilding the index will in most cases
> fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
> from scratch. So as long as there are no hardware issues to prevent a
> clean rebuild you should be OK. The problem comes into play more when it
> is data corruption than indexes.
> --
> Andrew J. Kelly SQL MVP
>
> "Joe Ross" <joeross7@.hotmail.com> wrote in message
> news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
>|||Andrew, There's another SQL 2005 launch event December 19th in Waltham if
you'd care to post it on NESQL.
Please email me if you'd like more details.
--
burt_king@.yahoo.com
"Joe Ross" wrote:
> Thank you. This is how I understood it, but it's reassuring to get
> confirmation from an expert.
> Much appreciated,
> -joe
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ej%23s64F7FHA.2484@.TK2MSFTNGP10.phx.gbl...
>
>
DBCC CHECKDB error resolved with dbreindex - safe?
We had a hard drive failure in one of our RAID arrays. We've resolved the
hardware issue; however, DBCC CHECKDB is showing errors in at least some of
our databases. The way we structure our databases is with two data files,
the second containing all of our table indexes. The RAID array that failed
contained these "index-only" data files.
Since DBCC CHECKDB reported that the minimum repair option would be
'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database from
our last full plus differential backups. It's approximately 45 databases,
and I was hoping to avoid this.
Since CHECKDB seems to be reporting an error on only a single table in each
database AND the hardware failure was on the array that contains only
indexes, I thought simply reindexing the table reporting an error might be
an option. So I took one of the databases showing an error and reindexed
the offending table with DBCC DBREINDEX. It completed successfully, so I
reran the DBCC CHECKDB and it reported no errors.
I realize restoring from backups might be the safest route to go, but if I
only reindex a table and the dbcc checkdb comes up clean, am I at risk for
any data loss?
I appreciate your insight on this situation.
Thanks
-joeIf the error was in the index then rebuilding the index will in most cases
fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
from scratch. So as long as there are no hardware issues to prevent a clean
rebuild you should be OK. The problem comes into play more when it is data
corruption than indexes.
--
Andrew J. Kelly SQL MVP
"Joe Ross" <joeross7@.hotmail.com> wrote in message
news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
> We had a hard drive failure in one of our RAID arrays. We've resolved the
> hardware issue; however, DBCC CHECKDB is showing errors in at least some
> of our databases. The way we structure our databases is with two data
> files, the second containing all of our table indexes. The RAID array
> that failed contained these "index-only" data files.
> Since DBCC CHECKDB reported that the minimum repair option would be
> 'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database
> from our last full plus differential backups. It's approximately 45
> databases, and I was hoping to avoid this.
> Since CHECKDB seems to be reporting an error on only a single table in
> each database AND the hardware failure was on the array that contains only
> indexes, I thought simply reindexing the table reporting an error might be
> an option. So I took one of the databases showing an error and reindexed
> the offending table with DBCC DBREINDEX. It completed successfully, so I
> reran the DBCC CHECKDB and it reported no errors.
> I realize restoring from backups might be the safest route to go, but if I
> only reindex a table and the dbcc checkdb comes up clean, am I at risk for
> any data loss?
> I appreciate your insight on this situation.
> Thanks
> -joe
>|||Thank you. This is how I understood it, but it's reassuring to get
confirmation from an expert.
Much appreciated,
-joe
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ej%23s64F7FHA.2484@.TK2MSFTNGP10.phx.gbl...
> If the error was in the index then rebuilding the index will in most cases
> fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
> from scratch. So as long as there are no hardware issues to prevent a
> clean rebuild you should be OK. The problem comes into play more when it
> is data corruption than indexes.
> --
> Andrew J. Kelly SQL MVP
>
> "Joe Ross" <joeross7@.hotmail.com> wrote in message
> news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
>> We had a hard drive failure in one of our RAID arrays. We've resolved
>> the hardware issue; however, DBCC CHECKDB is showing errors in at least
>> some of our databases. The way we structure our databases is with two
>> data files, the second containing all of our table indexes. The RAID
>> array that failed contained these "index-only" data files.
>> Since DBCC CHECKDB reported that the minimum repair option would be
>> 'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database
>> from our last full plus differential backups. It's approximately 45
>> databases, and I was hoping to avoid this.
>> Since CHECKDB seems to be reporting an error on only a single table in
>> each database AND the hardware failure was on the array that contains
>> only indexes, I thought simply reindexing the table reporting an error
>> might be an option. So I took one of the databases showing an error and
>> reindexed the offending table with DBCC DBREINDEX. It completed
>> successfully, so I reran the DBCC CHECKDB and it reported no errors.
>> I realize restoring from backups might be the safest route to go, but if
>> I only reindex a table and the dbcc checkdb comes up clean, am I at risk
>> for any data loss?
>> I appreciate your insight on this situation.
>> Thanks
>> -joe
>|||Andrew, There's another SQL 2005 launch event December 19th in Waltham if
you'd care to post it on NESQL.
Please email me if you'd like more details.
--
burt_king@.yahoo.com
"Joe Ross" wrote:
> Thank you. This is how I understood it, but it's reassuring to get
> confirmation from an expert.
> Much appreciated,
> -joe
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ej%23s64F7FHA.2484@.TK2MSFTNGP10.phx.gbl...
> > If the error was in the index then rebuilding the index will in most cases
> > fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
> > from scratch. So as long as there are no hardware issues to prevent a
> > clean rebuild you should be OK. The problem comes into play more when it
> > is data corruption than indexes.
> >
> > --
> > Andrew J. Kelly SQL MVP
> >
> >
> > "Joe Ross" <joeross7@.hotmail.com> wrote in message
> > news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
> >> We had a hard drive failure in one of our RAID arrays. We've resolved
> >> the hardware issue; however, DBCC CHECKDB is showing errors in at least
> >> some of our databases. The way we structure our databases is with two
> >> data files, the second containing all of our table indexes. The RAID
> >> array that failed contained these "index-only" data files.
> >>
> >> Since DBCC CHECKDB reported that the minimum repair option would be
> >> 'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database
> >> from our last full plus differential backups. It's approximately 45
> >> databases, and I was hoping to avoid this.
> >>
> >> Since CHECKDB seems to be reporting an error on only a single table in
> >> each database AND the hardware failure was on the array that contains
> >> only indexes, I thought simply reindexing the table reporting an error
> >> might be an option. So I took one of the databases showing an error and
> >> reindexed the offending table with DBCC DBREINDEX. It completed
> >> successfully, so I reran the DBCC CHECKDB and it reported no errors.
> >>
> >> I realize restoring from backups might be the safest route to go, but if
> >> I only reindex a table and the dbcc checkdb comes up clean, am I at risk
> >> for any data loss?
> >>
> >> I appreciate your insight on this situation.
> >>
> >> Thanks
> >> -joe
> >>
> >
> >
>
>
hardware issue; however, DBCC CHECKDB is showing errors in at least some of
our databases. The way we structure our databases is with two data files,
the second containing all of our table indexes. The RAID array that failed
contained these "index-only" data files.
Since DBCC CHECKDB reported that the minimum repair option would be
'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database from
our last full plus differential backups. It's approximately 45 databases,
and I was hoping to avoid this.
Since CHECKDB seems to be reporting an error on only a single table in each
database AND the hardware failure was on the array that contains only
indexes, I thought simply reindexing the table reporting an error might be
an option. So I took one of the databases showing an error and reindexed
the offending table with DBCC DBREINDEX. It completed successfully, so I
reran the DBCC CHECKDB and it reported no errors.
I realize restoring from backups might be the safest route to go, but if I
only reindex a table and the dbcc checkdb comes up clean, am I at risk for
any data loss?
I appreciate your insight on this situation.
Thanks
-joeIf the error was in the index then rebuilding the index will in most cases
fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
from scratch. So as long as there are no hardware issues to prevent a clean
rebuild you should be OK. The problem comes into play more when it is data
corruption than indexes.
--
Andrew J. Kelly SQL MVP
"Joe Ross" <joeross7@.hotmail.com> wrote in message
news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
> We had a hard drive failure in one of our RAID arrays. We've resolved the
> hardware issue; however, DBCC CHECKDB is showing errors in at least some
> of our databases. The way we structure our databases is with two data
> files, the second containing all of our table indexes. The RAID array
> that failed contained these "index-only" data files.
> Since DBCC CHECKDB reported that the minimum repair option would be
> 'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database
> from our last full plus differential backups. It's approximately 45
> databases, and I was hoping to avoid this.
> Since CHECKDB seems to be reporting an error on only a single table in
> each database AND the hardware failure was on the array that contains only
> indexes, I thought simply reindexing the table reporting an error might be
> an option. So I took one of the databases showing an error and reindexed
> the offending table with DBCC DBREINDEX. It completed successfully, so I
> reran the DBCC CHECKDB and it reported no errors.
> I realize restoring from backups might be the safest route to go, but if I
> only reindex a table and the dbcc checkdb comes up clean, am I at risk for
> any data loss?
> I appreciate your insight on this situation.
> Thanks
> -joe
>|||Thank you. This is how I understood it, but it's reassuring to get
confirmation from an expert.
Much appreciated,
-joe
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:ej%23s64F7FHA.2484@.TK2MSFTNGP10.phx.gbl...
> If the error was in the index then rebuilding the index will in most cases
> fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
> from scratch. So as long as there are no hardware issues to prevent a
> clean rebuild you should be OK. The problem comes into play more when it
> is data corruption than indexes.
> --
> Andrew J. Kelly SQL MVP
>
> "Joe Ross" <joeross7@.hotmail.com> wrote in message
> news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
>> We had a hard drive failure in one of our RAID arrays. We've resolved
>> the hardware issue; however, DBCC CHECKDB is showing errors in at least
>> some of our databases. The way we structure our databases is with two
>> data files, the second containing all of our table indexes. The RAID
>> array that failed contained these "index-only" data files.
>> Since DBCC CHECKDB reported that the minimum repair option would be
>> 'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database
>> from our last full plus differential backups. It's approximately 45
>> databases, and I was hoping to avoid this.
>> Since CHECKDB seems to be reporting an error on only a single table in
>> each database AND the hardware failure was on the array that contains
>> only indexes, I thought simply reindexing the table reporting an error
>> might be an option. So I took one of the databases showing an error and
>> reindexed the offending table with DBCC DBREINDEX. It completed
>> successfully, so I reran the DBCC CHECKDB and it reported no errors.
>> I realize restoring from backups might be the safest route to go, but if
>> I only reindex a table and the dbcc checkdb comes up clean, am I at risk
>> for any data loss?
>> I appreciate your insight on this situation.
>> Thanks
>> -joe
>|||Andrew, There's another SQL 2005 launch event December 19th in Waltham if
you'd care to post it on NESQL.
Please email me if you'd like more details.
--
burt_king@.yahoo.com
"Joe Ross" wrote:
> Thank you. This is how I understood it, but it's reassuring to get
> confirmation from an expert.
> Much appreciated,
> -joe
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:ej%23s64F7FHA.2484@.TK2MSFTNGP10.phx.gbl...
> > If the error was in the index then rebuilding the index will in most cases
> > fix the problem. If you do a DBCC DBREINDEX you are rebuilding the index
> > from scratch. So as long as there are no hardware issues to prevent a
> > clean rebuild you should be OK. The problem comes into play more when it
> > is data corruption than indexes.
> >
> > --
> > Andrew J. Kelly SQL MVP
> >
> >
> > "Joe Ross" <joeross7@.hotmail.com> wrote in message
> > news:O25cjrE7FHA.744@.TK2MSFTNGP10.phx.gbl...
> >> We had a hard drive failure in one of our RAID arrays. We've resolved
> >> the hardware issue; however, DBCC CHECKDB is showing errors in at least
> >> some of our databases. The way we structure our databases is with two
> >> data files, the second containing all of our table indexes. The RAID
> >> array that failed contained these "index-only" data files.
> >>
> >> Since DBCC CHECKDB reported that the minimum repair option would be
> >> 'REPAIR_ALLOW_DATA_LOSS', I thought I would be restoring each database
> >> from our last full plus differential backups. It's approximately 45
> >> databases, and I was hoping to avoid this.
> >>
> >> Since CHECKDB seems to be reporting an error on only a single table in
> >> each database AND the hardware failure was on the array that contains
> >> only indexes, I thought simply reindexing the table reporting an error
> >> might be an option. So I took one of the databases showing an error and
> >> reindexed the offending table with DBCC DBREINDEX. It completed
> >> successfully, so I reran the DBCC CHECKDB and it reported no errors.
> >>
> >> I realize restoring from backups might be the safest route to go, but if
> >> I only reindex a table and the dbcc checkdb comes up clean, am I at risk
> >> for any data loss?
> >>
> >> I appreciate your insight on this situation.
> >>
> >> Thanks
> >> -joe
> >>
> >
> >
>
>
Subscribe to:
Posts (Atom)