Tuesday, February 14, 2012

Checking a database for physical damage

Hi,
Today I had one disk of my server array crashed, it is on raid 5 with
hot spare disks.
SQL Server reported some errors on event logger but apparently the hot
spare disks were used correctly since it is working right now.
So far is fine, but just in case I ran this command:
DBCC CHECKDB (MyProd) WITH ALL_ERRORMSGS
And it showed no errors.
Are there any other commands that I can run to check for integrity in a
database in a case like this?If the CHECKDB was clean, you are in good shape. You might also include
DBCC CHECKCATALOG as part of your scheduled integrity checks but it unlikely
that a hardware error will introduce catalog problems.
You mention SQL Server errors but SQL Server should be oblivious to the
problem, assuming the controller gracefully handles such errors. If the
errors are due to the I/O subsystem become sluggish during the rebuild,
check to see if your array controller allows you to configure the rebuild
priority.
--
Hope this helps.
Dan Guzman
SQL Server MVP
<craigkenisston@.hotmail.com> wrote in message
news:1165648156.056709.236200@.f1g2000cwa.googlegroups.com...
> Hi,
> Today I had one disk of my server array crashed, it is on raid 5 with
> hot spare disks.
> SQL Server reported some errors on event logger but apparently the hot
> spare disks were used correctly since it is working right now.
> So far is fine, but just in case I ran this command:
> DBCC CHECKDB (MyProd) WITH ALL_ERRORMSGS
> And it showed no errors.
> Are there any other commands that I can run to check for integrity in a
> database in a case like this?
>|||Dan,
Thank for your comment. I did not expect to have SQL Server errors
either. But they were.
I guess as you suggest, the problem went during the rebuild, not
directly because the failure.
The errors I had were:
18052 :
Error: 3624, Severity: 20, State: 1.
And this:
17066 :
SQL Server Assertion: File:
<p:\sql\ntdbms\storeng\drs\include\record.inl>, line=1447
Failed Assertion = 'm_SizeRec > 0 && m_SizeRec <= MAXDATAROW'.
I also had other errores, but the only message they have is about
telling "The description for Event ID ( XXXX ) in Source ( MSSQLSERVER
) cannot be found. "
Regards,
Dan Guzman wrote:
> If the CHECKDB was clean, you are in good shape. You might also include
> DBCC CHECKCATALOG as part of your scheduled integrity checks but it unlikely
> that a hardware error will introduce catalog problems.
> You mention SQL Server errors but SQL Server should be oblivious to the
> problem, assuming the controller gracefully handles such errors. If the
> errors are due to the I/O subsystem become sluggish during the rebuild,
> check to see if your array controller allows you to configure the rebuild
> priority.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> <craigkenisston@.hotmail.com> wrote in message
> news:1165648156.056709.236200@.f1g2000cwa.googlegroups.com...
> > Hi,
> >
> > Today I had one disk of my server array crashed, it is on raid 5 with
> > hot spare disks.
> > SQL Server reported some errors on event logger but apparently the hot
> > spare disks were used correctly since it is working right now.
> >
> > So far is fine, but just in case I ran this command:
> > DBCC CHECKDB (MyProd) WITH ALL_ERRORMSGS
> >
> > And it showed no errors.
> > Are there any other commands that I can run to check for integrity in a
> > database in a case like this?
> >|||The assertion error indicates garbage was returned to SQL Server. I find it
strange that the controller would return bad data during the rebuild. Even
during the rebuild, the controller ought to be able to reconstruct the
original data and return it to SQL, albeit more slowly than a healthy array.
Anyway, I'm glad your DBCCs are clean and you are out of the woods.
--
Hope this helps.
Dan Guzman
SQL Server MVP
<craigkenisston@.hotmail.com> wrote in message
news:1165681327.852727.312450@.f1g2000cwa.googlegroups.com...
> Dan,
> Thank for your comment. I did not expect to have SQL Server errors
> either. But they were.
> I guess as you suggest, the problem went during the rebuild, not
> directly because the failure.
> The errors I had were:
> 18052 :
> Error: 3624, Severity: 20, State: 1.
> And this:
> 17066 :
> SQL Server Assertion: File:
> <p:\sql\ntdbms\storeng\drs\include\record.inl>, line=1447
> Failed Assertion = 'm_SizeRec > 0 && m_SizeRec <= MAXDATAROW'.
>
> I also had other errores, but the only message they have is about
> telling "The description for Event ID ( XXXX ) in Source ( MSSQLSERVER
> ) cannot be found. "
>
> Regards,
>
> Dan Guzman wrote:
>> If the CHECKDB was clean, you are in good shape. You might also include
>> DBCC CHECKCATALOG as part of your scheduled integrity checks but it
>> unlikely
>> that a hardware error will introduce catalog problems.
>> You mention SQL Server errors but SQL Server should be oblivious to the
>> problem, assuming the controller gracefully handles such errors. If the
>> errors are due to the I/O subsystem become sluggish during the rebuild,
>> check to see if your array controller allows you to configure the rebuild
>> priority.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> <craigkenisston@.hotmail.com> wrote in message
>> news:1165648156.056709.236200@.f1g2000cwa.googlegroups.com...
>> > Hi,
>> >
>> > Today I had one disk of my server array crashed, it is on raid 5 with
>> > hot spare disks.
>> > SQL Server reported some errors on event logger but apparently the hot
>> > spare disks were used correctly since it is working right now.
>> >
>> > So far is fine, but just in case I ran this command:
>> > DBCC CHECKDB (MyProd) WITH ALL_ERRORMSGS
>> >
>> > And it showed no errors.
>> > Are there any other commands that I can run to check for integrity in a
>> > database in a case like this?
>> >
>

No comments:

Post a Comment