• I realize that a full checkDB is better. However, this server has 10TB of data on it and a full checkDB would simply take too long. Also, this is historical data, no updates are occuring so I took the faster approach. I do a full checkDB on occasion, but it just takes too long to schedule.

    As for the SQL log, yes, I see something very intersting that I missed before. Every 5 minutes SPID 31 is generating the following message. "A time-out occurred while waiting for buffer latch -- type 4, bp 00000005EFFDE380, page 5:8088, stat 0x7c0040d, database id: 19, allocation unit Id: 10851164356608/292326141067264, task 0x0000000004C7A988 : 0, waittime 300, flags 0x100000003a, owning task 0x0000000004C7A988. Not continuing to wait." SPID 31 is a BACKGROUND GHOST CLEANUP of the database that the checkDB is stuck on. The checkDB is running as SPID 57.

    Tracing these back to the first one, I see another message about this database just a few minutes before these started. "SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [G:\WM07DSDM\WM07DSDM2_Data3.ndf] in database [WM07DSDM] (19). The OS file handle is 0x0000000000000A88. The offset of the latest long I/O is: 0x00000003f30000". This was from SPID 4, the LAZY WRITER spid.