Fatal error 644???

Question

Post reply

Fatal error 644???

Eric Lenington

SSC Veteran

Points: 250
More actions
March 1, 2004 at 11:14 pm

#83874

We get this error from time to time for no apparent reason (i.e., the SP we're calling, which does a simple UPDATE of a keyed table, runs hundreds of thousands of times with no problems, then suddenly fails like this). It seems that once it fails once, it will fail more frequently thereafter (but still only a small fraction of the time). It seems like the problem is in the ODBC driver on the client (MDAC 2.7 on the client; connected via TCP/IP to SQL2000 server; Driver Name is "SQL Server"), because it will stop for a while after the client is restarted.
I have not been able to find anything meaningful about this error. Any clues?
(21) State[HY000] Message[[Microsoft][ODBC SQL Server Driver][SQL Server]Warning: Fatal error 644 occurred at Mar 1 2004 10:00PM
Note: It is usually followed by this error:
State[08S01] Message[[Microsoft][ODBC SQL Server Driver]Communication link failure]

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Dinesh Asanka SSChampion Points: 11058 More actions · Answer 1

This is BOL says

Explanation

This error occurs when the nonclustered index indicated by the index ID is in error. The corruption is detected when a process tries to delete a nonexistent row.

Action

Execute DBCC CHECKDB without a repair clause to determine the extent of the damage. Then, execute DBCC CHECKDB with REPAIR_REBUILD clause to correct the damage. If problems persist, either drop and re-create the index (as shown below) or contact your primary support provider

My Blog: http://dineshasanka.spaces.live.com/

Eric Lenington SSC Veteran Points: 250 More actions · Answer 2

Yes, I found that same explanation, but it doesn't seem to fit here. If it's non-clustered index corruption, how do you explain:

1) There is no non-clustered index on any table affected direclty or indirectly by the SP that causes this error.

2) What Index ID?

3) Restarting the client "fixes" the problem (it will eventually happen again, but it stays fixed for 100's of thousands of transactions before the error happens again); if there is index corruption on the server, why would restarting the client have any effect?

Tnx!

5409045121009-7368 SSCoach Points: 15740 More actions · Answer 3

May help a bit

http://dbforums.com/arch/30/2002/7/422872

Donna D. SSC Enthusiast Points: 155 More actions · Answer 4

We recently had this error occur a number of times and each time it occurred our t-log backups were not able to be restored. We also had one occasion where it caused consistency errors in two indexes. We were able to fix the consistency errors by dropping and re-creating the indexes.

The problem appears to have been related to disk read caching. At Microsoft's suggestion, we changed the disk system from 50% read, 50 % write cache to 0% read, 75% write cache. It's been two weeks now and the problems have not recurred. Our system has been fairly stable for two years, so it's interesting that we first saw the 644 errors about a week after we applied SP3a.

This KB article was the most pertinent to our situation:

http://support.microsoft.com/?id=826433

I hope that helps...I'd be especially wary about your t-log backups. If we hadn't been log-shipping, we wouldn't have known that our t-log backup chain was broken. That helped me to get approval to open a case with Microsoft and get the issue resolved more quickly.