Sql-server – SQL Server 2014 DBCC CHECKDB notification

If the sequence is:

1. DBCC CHECKDB reported errors.
2. REPAIR_REBUILD fixed the database, no errors reported.
3. DBCC CHECKDB reporting errors again.

You probably have failed or failing disks in an array or some other component of the IO subsystem is broken, or breaking. Personally, I'd want off the problem server ASAP!

• Take a tail-log backup.
• Restore last known good full backup and diff/log sequence to a different server.
• Switch service to the second server.
• Get a fresh cuppa and start diagnosis on the problem server.

Addendum: Root cause of the problem:

as it turned out, I found that as we are using Diskeeper, we are (for corporate reasons) still using an old version : 14.0.896. With this version we run into messages like :

The operating system returned error 1784(failed to retrieve text for this error. Reason: 15100) to SQL Server during a write at offset 0x000000010a4000 in file 'D:\Application-Data\MSSQL\Data\<Database>.mdf:MSSQL_DBCC17'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Msg 3313, Level 21, State 2, Server <Server>, Line 1
During redoing of a logged operation in database '<Database>', an error occurred at log record ID (2349664:1503:4). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
Msg 1823, Level 16, State 1, Server <Server>, Line 1
A database snapshot cannot be created because it failed to start.
Msg 1823, Level 16, State 2, Server <Server>, Line 1
A database snapshot cannot be created because it failed to start.
Msg 7928, Level 16, State 1, Server <Server>, Line 1
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
Msg 5030, Level 16, State 12, Server <Server>, Line 1
The database could not be exclusively locked to perform the operation.
Msg 7926, Level 16, State 1, Server <Server>, Line 1
Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details

Found an explanation on Paul Randal's blog here

Link to DiskKeeper Fix found here

Interesting Diskeeper white paper on database defragmentation here

I think @MartinSmith nailed it in his comment. When you have AUTO_CLOSE set to ON, then the database will shutdown when the last user exits. Likewise, when somebody attempts to use the database it will reopen. When the database reopens, a message about the last time DBCC CHECKDB ran will be logged.

Take the below example (sample code, not meant to be run anywhere near a production environment) to show proof of this:

create database AutoCloseDb;
go

alter database AutoCloseDb
set auto_close on;
go

dbcc checkdb('AutoCloseDb');
go

-- rotate the below "use" statements a few times in order
-- to cause the database to close and reopen
--
use AutoCloseDb;
go

use master;
go

After we do a few rotations of use AutoCloseDb; followed by use master;, we would see something similar to the below in the SQL Server error log (I use the below PowerShell code to retrieve this):

Add-Type -Path "C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies\Microsoft.SqlServer.Smo.dll"

$SqlServer = New-Object Microsoft.SqlServer.Management.Smo.Server("<your SQL Server name>")

$SqlServer.ReadErrorLog() |
    Where-Object {$_.Text -like "*AutoCloseDb*"} |
    Select-Object LogDate, Text |
    Format-List

And in my test environment, the output is the following:

LogDate : 11/15/2013 5:47:17 AM Text : Starting up database 'AutoCloseDb'.

LogDate : 11/15/2013 5:47:18 AM Text : CHECKDB for database 'AutoCloseDb' finished without errors on 2013-11-15 05:39:19.137 (local time). This is an informational message only; no user action is required.

LogDate : 11/15/2013 5:47:18 AM Text : Starting up database 'AutoCloseDb'.

LogDate : 11/15/2013 5:47:18 AM Text : CHECKDB for database 'AutoCloseDb' finished without errors on 2013-11-15 05:39:19.137 (local time). This is an informational message only; no user action is required.

LogDate : 11/15/2013 5:47:19 AM Text : Starting up database 'AutoCloseDb'.

LogDate : 11/15/2013 5:47:19 AM Text : CHECKDB for database 'AutoCloseDb' finished without errors on 2013-11-15 05:39:19.137 (local time). This is an informational message only; no user action is required.

LogDate : 11/15/2013 5:48:25 AM Text : Starting up database 'AutoCloseDb'.

LogDate : 11/15/2013 5:48:26 AM Text : CHECKDB for database 'AutoCloseDb' finished without errors on 2013-11-15 05:39:19.137 (local time). This is an informational message only; no user action is required.

LogDate : 11/15/2013 5:49:30 AM Text : Starting up database 'AutoCloseDb'.

LogDate : 11/15/2013 5:49:30 AM Text : CHECKDB for database 'AutoCloseDb' finished without errors on 2013-11-15 05:39:19.137 (local time). This is an informational message only; no user action is required.

If it is indeed AUTO_CLOSE that is causing this logging behavior in your case, you should see the similar message of "Starting up database ..." in your error log.

If this is not what you're seeing, then please modify your question to include other error log events surrounding the DBCC CHECKDB logging.