Integrity check ugly errors

  • An integrity check job hung on a large database with some ugly errors that I can't seem to find anything on.  This hang also prevented T-log backups to occur for log shipping.  Once the integrity job SPID was killed (after running 3 hours), log shipping caught up.  Anyone ever see these errors in the SQL errorlog before?  There are no Application or System log errors on either server.  BTW, the server is SQL 2000 sp4 and is also a cluster on Windows 2003....

    2006-06-15 04:50:05.51 spid501   WARNING: EC 6a6740c0, 7 waited 300 sec. on latch 6a5d23c4, class MISC.  Not a BUF latch.                           0

    2006-06-15 04:50:05.51 spid501   Waiting for type 0x4, current count 0xa, current owning EC 0x6A66C0C0.                                             0

    2006-06-15 04:55:05.52 spid501   WARNING: EC 6a6700c0, 6 waited 600 sec. on latch 6a5d23c4, class MISC.  Not a BUF latch.                           0

    2006-06-15 04:55:05.52 spid501   WARNING: EC 6a6780c0, 8 waited 600 sec. on latch 6a5d23c4, class MISC.  Not a BUF latch.                           0

    Any info would be appreciated.

  • Hello,

    Check out...

    http://support.microsoft.com/default.aspx/kb/310834

    Are you using an MSA1000 by any chance?  I've run across this problem, and the long-term solution was to upgrade the firmware on the SAN.  Can't remember the "bad" version.

    If you get these messages during normal operation then I've got something you might try. We had a procedure that normally ran about 45 minutes, but would sometimes fail and we'd get the message(s) you indicated in your post.

    Try running a DBCC DROPCLEANBUFFERS and retry the operation.  It is a perfromance killer, but it will help identify the problem.  If the problem persists after that, then you might actualy have a database problem.

    In my case, the DBCC DROPCLEANBUFFERS made the problem go away.  Until we upgraded the SAN firmware.

    Good Luck!

    jg

     

  • I'm not sure about the hardware but I'll look into it.  If the DROPCLEANBUFFERS is a "performance killer" I hesitate to run it on this particular server.  Do you recall how long it took and what size your database was?

    The article looks pretty good but so far nothing jumps out at me but I'll do some digging.  Thanks for the info.

  • The DROPCLEANBUFFERS dbcc command makes SQL server perform like it was just started up, for the most part.  It causes the (page) buffer cache to be invalidated, resulting in everything that was in memory to be re-read from disk.

    jg

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

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