1

Accidental DBA here (DB developer/jack of all trades), and first-time poster. So please be gentle. I have an alert on our SQL Server for error 825, and it fired in February. Then twice in June, and now three times in the past three weeks. The databases are for a vendor application. DBCC CHECKDB ran in production after the errors, and I also restored to a test server and ran again, with no errors. The errors occurred on two of the databases, one of which holds 99% of the application's data. No rows in suspect_pages.

I also wrote to the software/database vendor, and they pretty told me to do what I already did, and sent a bunch of cut-n-paste research that I've already found.

Everything I found says hardware or drivers. Our network/hardware is maintained by a third-party provider, and they say they don't see anything wrong with the disks. We run VMware on EMC - that's about all I know about hardware. SQL is Standard Edition 2008R2 SP3, running on Server 2008R2 Standard.

Oh, I changed DBCC CHECKDB to run daily.

We've been told we should hire a DBA because our disks are healthy.

Any advice?

Thanks, Pat

Improve this question
2
  • 1
    I've only seen 823-825 errors once and it was a storage subsystem issue. We had a SAN controller that was acting up. Since it threw 825, that means the retry was successful and life went on but with increasing frequency of the errors, it sounds like the issue may be getting worse. I wish I had more to tell you but these errors usually point to infrastructure issues, not SQL server.
    – Kris Gruttemeyer
    Sep 21, 2017 at 19:18
  • 1
    A little-known sign of impending doom: error 825
    – Scott Hodgin - Retired
    Sep 21, 2017 at 19:20

1 Answer 1

Reset to default
1

Here you can find the explnation of this error by Paul Randal: A little-known sign of impending doom: error 825

From SQL Server 2005 onwards, if you ever see an 823 or 824, SQL Server has actually tried that I/O a total of 4 times before it finally declares a lost cause and surfaces the high-severity I/O error to the connection’s console, killing the connection into the bargain. The idea behind this read-retry logic came from Exchange, where adding the logic reduced the amount of immediate downtime that customers experienced. While in concept this was something I agreed with at the time, I didn’t agree with the way it was implemented.

If the I/O continues to fail, then the 823/824 is surfaced – that’s fine. But what if the I/O succeeds on one of the retries? No high-severity error is raised, and the query completes, blissfully unaware that anything untoward happened. However, something did go badly wrong – the I/O subsystem failed to read 8KB of data correctly until the read was attempted again. Basically, the I/O subsystem had a problem, which luckily wasn’t fatal this time. And that’s what I don’t like – the I/O subsystem went wrong but there are no flashing lights and alarm bells that fire for the DBA, as with an 823 or 824. If read-retry is required to get a read to complete, the only notification of this is a severity-10 informational message in the error log – error 825.
Additional messages in the SQL Server error log and system event log may provide more detail. This error condition threatens database integrity and must be corrected. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

What this message is really saying is that your I/O subsystem is going wrong and you must do something about it. And unless you’re regularly scanning the error log looking for these, you’ll be none-the-wiser.

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.