Quick Scan Report – Slow or No Error Log Access

What this check looks for

The scan’s own internal flag saying it gave up on the error log. When the error log could not be read, this finding is raised at Urgent severity, because of what it silences rather than what it is.

Why it matters

This is not a finding about your databases. It is a finding about the scan, and it means a whole category of checks returned nothing without saying so.

The checks that read the error log, and which therefore produced no result on this run:

An empty result from those checks reads exactly like a clean instance, and that is why this one is raised so loudly. A scan that reports no corruption findings because it could not look is worse than one that reports a problem, because it produces confidence rather than action.

Three things cause it, and they need different responses:

• Permission. Reading the error log needs sysadmin, or membership in the securityadmin fixed server role, or an explicit grant on xp_readerrorlog. A scan run by a login with VIEW SERVER STATE but nothing more can read most DMVs and not this.
• Size. A log that has grown to hundreds of megabytes because nothing cycles it takes so long to read that the scan gives up. That is the more common cause on a neglected instance, and it has its own checks.
• The file genuinely being unavailable, because the log directory has moved, filled, or is on storage that is not responding. That last one is worth taking seriously, since a log directory that cannot be read may be a storage problem rather than a configuration one.

How to confirm it yourself

Try to read it as the account the scan uses:

EXEC sp_readerrorlog 0, 1;

A permission error names the cause directly. A very long wait before anything returns points at size.

How large the logs are, which is the usual answer:

EXEC sp_enumerrorlogs;

The size column is in bytes. Anything in the hundreds of megabytes is a problem in its own right.

Where they are, in case the directory is the issue:

SELECT SERVERPROPERTY('ErrorLogFileName') AS [error_log_path];

What the account can do:

SELECT IS_SRVROLEMEMBER('sysadmin')      AS [is_sysadmin],
       IS_SRVROLEMEMBER('securityadmin') AS [is_securityadmin],
       HAS_PERMS_BY_NAME('xp_readerrorlog', 'OBJECT', 'EXECUTE') AS [can_read_errorlog],
       SUSER_SNAME()                     AS [login];

And whether the volume the logs live on is healthy:

SELECT DISTINCT vs.[volume_mount_point],
       CAST(vs.[available_bytes] / 1073741824.0 AS DECIMAL(12,1)) AS [free_gb]
  FROM sys.master_files AS mf WITH (NOLOCK)
 CROSS APPLY sys.dm_os_volume_stats(mf.[database_id], mf.[file_id]) AS vs;

How to fix it

Work out which of the three, then fix that.

If it is permission, grant the minimum that works. securityadmin is the documented role for reading the error log and it is considerably less than sysadmin:

ALTER SERVER ROLE [securityadmin] ADD MEMBER [YourScanLogin];

or grant execute on the procedure directly, which is narrower still:

USE [master];
GO
GRANT EXECUTE ON [sys].[xp_readerrorlog] TO [YourScanLogin];

If it is size, fix the log rather than the permission. Cycle it, then keep it cycled:

EXEC msdb.dbo.sp_cycle_errorlog;

as a weekly Agent job, with the retention raised so weekly cycling still leaves months of history:

EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE',
     N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', REG_DWORD, 30;

Then find out why it grew. Backup success messages are the usual answer, and trace flag 3226 suppresses them without losing anything, since backup history is in msdb regardless:

DBCC TRACEON (3226, -1);

Add -T3226 as a startup parameter to keep it across restarts.

If the directory is unavailable, that is the one to escalate. Check the path, the free space and the Windows event log for storage errors, because a log directory that cannot be read is sometimes the first visible symptom of a disk problem.

Then re-run the scan. The point of fixing this is the checks it unblocks, and none of them has reported anything yet.

How long it takes

About an hour, most of it deciding the right permission or clearing an oversized log.

Related reports

Related checks

Frequently asked questions

Is this a problem with my SQL Server? Usually not directly. It is the scan reporting that it could not look, and the important consequence is the checks that returned nothing as a result.

Why is it Urgent when nothing is broken? Because of what it hides. A corruption check that could not run looks identical to a corruption check that found nothing.

We do not want to grant sysadmin for a scan. You should not have to. securityadmin, or an explicit grant on xp_readerrorlog, is enough and is much narrower.

The log is 2 GB. Is that the cause? Almost certainly. Cycle it, raise the retention, and suppress the backup success messages with trace flag 3226.