CHECKDB fails on MSDB and Master system databases I get the following error within my maintenance plans:


  Executing the query "DBCC CHECKDB(N'master')  WITH NO_INFOMSGS  "
  failed with the following error: "The database could not be
  exclusively locked to perform the operation.  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.".
  Possible failure reasons: Problems with the query, "ResultSet"
  property not set correctly, parameters not set correctly, or
  connection not established correctly.


I get the following when I run the code from the query analyzer:

USE [master]
GO
DBCC CHECKDB(N'master')  WITH NO_INFOMSGS,  PHYSICAL_ONLY



  Msg 5030, Level 16, State 12, Line 1 The database could not be
  exclusively locked to perform the operation. Msg 7926, Level 16, State
  1, 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.


I've searched high and low trying to find a fix, but no dice.

FACTS:


SQL Server 2008 R2 Standard 64-bit (10.50.4000.0)
Windows Server 2008 R2 64-bit w/SP1
VMWare Virtual Machine
Production server, so I can't reboot server/instance without internal change management process
SQL Server Agent &amp; Database Engine service accounts have full access to the folders and files where the MDFs and LDFs are housed
Restarted SQL Server Agent via Config Mgr.
SQL Server Agent has read permissions on the entire volume
There are no read-only FGs
DBs are not in Single-user mode, read-only, or in emergency mode
Not running TABLOCK with DBCC command
The DBs are on NTFS


The following are a few places I've read out of many, but these are the most applicable to my matter as I see it.  I've performed the suggested "fixes" with no change in result or error message output from the SQL Server Error Logs.

Paul Randal's Input

Microsoft
There is an internal snapshot that SQL Server will try to create when you run certain DBCC commands.  There is really good information about this on the BOL reference for DBCC.


  When you execute one of these DBCC commands, the Database Engine
  creates a database snapshot and brings it to a transactionally
  consistent state. The DBCC command then runs the checks against this
  snapshot. After the DBCC command is completed, this snapshot is
  dropped.
  
  Sometimes an internal database snapshot is not required or cannot be
  created. When this occurs, the DBCC command executes against the
  actual database. If the database is online, the DBCC command uses
  table-locking to ensure the consistency of the objects that it is
  checking. This behavior is the same as if the WITH TABLOCK option were
  specified.


The master database is particularly interesting with this, as if the internal snapshot can't be created then DBCC CHECKDB will fail against master.  As per the above reference:


  DBCC CHECKDB fails when it is run against master if an internal database snapshot cannot be created.


So, what can cause the internal snapshot creation to fail?  The above reference has a nice list:


  An internal database snapshot is not created when a DBCC command is
  executed: 
  
  
  Against master, and the instance of SQL Server is running in single-user mode.
  Against a database other than master, but the database has been put in single-user mode by using the ALTER DATABASE statement. 
  Against a read-only database.
  Against a database that has been set in emergency mode by using the ALTER DATABASE statement. 
  Against tempdb. In this case, a database snapshot cannot be created because of internal restrictions.
  Using the WITH TABLOCK option. In this case, DBCC honors the request by not creating a database snapshot.
  
  
  The DBCC commands use table locks instead of the internal database
  snapshots when the command is executed against the following: 
  
  
  A read-only filegroup 
  An FAT file system
  A volume that does not support 'named streams'
  A volume that does not support 'alternate streams'
  


My recommendation is to look at that information and find which one is applying to your situation.  That should answer your question and move towards the resolution.