This error usually means that your disk isn't responding fast enough. You may have a disk failure comming, or a SCSI cable going bad. If you are on a SAN you could have a bad fibre cable, or a heat problem within the array. Or you may simple need more spindles in your array that is having the problem. If it's a disk failure problem you will want to run a DBCC CHECKDB on the database to ensure that the database didn't get corrupted. Check perfmon and look for high queueing or high latency to the disk. UPDATE: I contacted the vendor of our CRM tool to find out if they had any experience with this issue. they set me up with one of their senior DBAs. After some poking around in Enterprise manager and my describing what we do weekly with our maintenance plans we saw that as a result of shrinking the database every week we were creating the problem. We noticed that the timestamp of the database file was exactly the time of the buf latch error starting. We surmised it was useless to shrink the database since it was going to expand almost immediately after the shrink anyway and it was impacting performance. We have gone an entire day without the error resurfacing.

This error usually means that your disk isn't responding fast enough. You may have a disk failure comming, or a SCSI cable going bad. If you are on a SAN you could have a bad fibre cable, or a heat problem within the array. Or you may simple need more spindles in your array that is having the problem. If it's a disk failure problem you will want to run a DBCC CHECKDB on the database to ensure that the database didn't get corrupted. Check perfmon and look for high queueing or high latency to the disk. UPDATE: I contacted the vendor of our CRM tool to find out if they had any experience with this issue. they set me up with one of their senior DBAs. After some poking around in Enterprise manager and my describing what we do weekly with our maintenance plans we saw that as a result of shrinking the database every week we were creating the problem. We noticed that the timestamp of the database file was exactly the time of the buf latch error starting. We surmised it was useless to shrink the database since it was going to expand almost immediately after the shrink anyway and it was impacting performance. We have gone an entire day without the error resurfacing.