I've had a sudden rush of about 22 assertion errors come out in the SQL
Server log, that stopped the active replication dead in it's tracks. Most of
the other clients and processes seemed unaffected but I can't understand the
source of some of these errors...
- This first one has been identified under kb 828337 BUT that doesn't help
me drill down to the source of the problem! It occurred the most - about 19
times in 4 minutes.
SQL Server Assertion: File: <p:\sql\ntdbms\storeng\drs\include\record.inl>,
line=1447
Failed Assertion = 'm_SizeRec > 0 && m_SizeRec <= MAXDATAROW'.
- This next one is mentioned in kb 324630 BUT I was not running DBCC
INDEXDEFRAG as suggested and the SQL Server is SP 3.
Location: page.cpp:1668
Expression: pageFull == 0
SPID: 6
Process ID: 2228
- This one seems more interesting since I cannot find any suitable
information about it on-line
Location: page.cpp:2610
Expression: spaceNeeded <= spaceContig && spaceNeeded <= space_usable
SPID: 6
Process ID: 2228
Any help to track down potential causes and or silent problems resulting
from this would be most appreciated - I am unwilling to run DBCC CHECKDB on a
database of this size (~100GB). The server has 13GB free disk space as well
so I can't see it being a problem related to anything so simple!
This really looks like a bug. Open a support incident with MS on this one.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Robert" <MSDNNospam209@.nospam.nospam> wrote in message
news:50F9478D-E5AA-473F-B79C-0C42CD4F16DD@.microsoft.com...
> I've had a sudden rush of about 22 assertion errors come out in the SQL
> Server log, that stopped the active replication dead in it's tracks. Most
> of
> the other clients and processes seemed unaffected but I can't understand
> the
> source of some of these errors...
> - This first one has been identified under kb 828337 BUT that doesn't help
> me drill down to the source of the problem! It occurred the most - about
> 19
> times in 4 minutes.
> SQL Server Assertion: File:
> <p:\sql\ntdbms\storeng\drs\include\record.inl>,
> line=1447
> Failed Assertion = 'm_SizeRec > 0 && m_SizeRec <= MAXDATAROW'.
> - This next one is mentioned in kb 324630 BUT I was not running DBCC
> INDEXDEFRAG as suggested and the SQL Server is SP 3.
> Location: page.cpp:1668
> Expression: pageFull == 0
> SPID: 6
> Process ID: 2228
> - This one seems more interesting since I cannot find any suitable
> information about it on-line
> Location: page.cpp:2610
> Expression: spaceNeeded <= spaceContig && spaceNeeded <= space_usable
> SPID: 6
> Process ID: 2228
> Any help to track down potential causes and or silent problems resulting
> from this would be most appreciated - I am unwilling to run DBCC CHECKDB
> on a
> database of this size (~100GB). The server has 13GB free disk space as
> well
> so I can't see it being a problem related to anything so simple!
>
|||Hello Robert,
I understand that you encounter many asssertion errors in SQL logs. I'd
like to confirm if you have SQL 2000 SP4 and latest culmulative patch
installed. There is a related known issue was fixed in SP4
841776FIX: Additional diagnostics have been added to SQL Server 2000 to
detect unreported read operation failures
http://support.microsoft.com/default.aspx?scid=kb;EN-US;841776
Please note this issue is most likely caused by hardware or driver related
issues, you may want to enable trace flag 806 as descirbed in 841776 to see
more detailed errors.
Also, as Hilary mentioned, since the issue is related to internal error, if
you cannot solve the issue by above method, to find out the root cause of
this issue we may need to analyze memory dumps, this work has to be done by
contacting Microsoft Product Support Services. Therefore, we probably will
not be able to resolve the issue through the newsgroups. If the issue is
urgent, I recommend that you open a Support incident with Microsoft Product
Support Services so that a dedicated Support Professional can assist with
this case. If you need any help in this regard, please let me know.
For a complete list of Microsoft Product Support Services phone numbers,
please go to the following address on the World Wide Web:
http://support.microsoft.com/directory/overview.asp
Please let's know if you ahve any questions or concerns. Thank you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
<http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscriptions/support/default.aspx>.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Robert,
You may have to run the DBCC CHECKDB afterall..
The KBA Peter has below talks about check that SQL will perform after you
install the fix and turn on the trace flag. And it also appears that you'd
probably take some degree of performance hit with the trace flag
enabled...because every read from the disk will be audited by SQL for
consistency once you turnon the trace flag.
But I'd think if the damage has been done already, in some form or fashion,
you'd want to know about it. You could may be restore the backup of the
database on another server and run CHECKDB there.
Thanks
Emaniel
"Peter Yang [MSFT]" wrote:
> Hello Robert,
> I understand that you encounter many asssertion errors in SQL logs. I'd
> like to confirm if you have SQL 2000 SP4 and latest culmulative patch
> installed. There is a related known issue was fixed in SP4
> 841776FIX: Additional diagnostics have been added to SQL Server 2000 to
> detect unreported read operation failures
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;841776
> Please note this issue is most likely caused by hardware or driver related
> issues, you may want to enable trace flag 806 as descirbed in 841776 to see
> more detailed errors.
> Also, as Hilary mentioned, since the issue is related to internal error, if
> you cannot solve the issue by above method, to find out the root cause of
> this issue we may need to analyze memory dumps, this work has to be done by
> contacting Microsoft Product Support Services. Therefore, we probably will
> not be able to resolve the issue through the newsgroups. If the issue is
> urgent, I recommend that you open a Support incident with Microsoft Product
> Support Services so that a dedicated Support Professional can assist with
> this case. If you need any help in this regard, please let me know.
> For a complete list of Microsoft Product Support Services phone numbers,
> please go to the following address on the World Wide Web:
> http://support.microsoft.com/directory/overview.asp
> Please let's know if you ahve any questions or concerns. Thank you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Community Support
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications
> <http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> <http://msdn.microsoft.com/subscriptions/support/default.aspx>.
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment