Minion CheckDB is made up of SQL Server stored procedures, functions, tables, and jobs.  The tables store configuration and log data; stored procedures perform CheckDB operations; and the jobs execute and monitor those operations on a schedule.
 
This section provides a brief overview of Minion CheckDB elements at a high level.
 
Note: Minion CheckDB is installed in the master database by default.  You certainly can install Minion in another database (like a DBAdmin database), but when you do, you must also verify that the job steps point to the appropriate database.
 

Configuration Settings Hierarchy

Configuration settings for integrity check operations are stored in tables: Minion.CheckDBSettingsDB and Minion. CheckDBSettingsTable. A default row in Minion.CheckDBSettingsDB (DBName=’MinionDefault’) provides settings for any database that doesn’t have its own specific settings.  This is a hierarchy of granularity, where more specific configuration levels completely override the less specific levels. That is: 
  • Insert a row for a specific database (for example, DBName=’DB1’) into Minion.CheckDBSettingsDB, and that row will override ALL of the default settings for that database. 
  • Insert a row for a specific table in Minion.CheckDBSettingsTable, and that row will override ALL of the default (or, if available, database-specific) settings for that particular table.
In other words, a database-specific row completely overrides the MinionDefault rows, for that 
particular database. And a table-specific row overrides the MinionDefault settings for that 
particular table.
 
Note: A value left at NULL in one of these tables means that Minion will use the setting that the 
SQL Server instance itself uses.
 
Additionally, you can configure settings to apply only on specific days, or during certain hours of the day. (For more information, see the “Discussion: Hierarchy and Precedence” section in “About: Scheduling”.)
 
IMPORTANT: Each level of settings in Minion.CheckDBSettingsDB (that is, the MinionDefault level, and each specified database level) should have one row for CHECKTABLE and one row for CHECKDB. “

Example: Proper Configuration

Let us take a simple example, in which these are the contents of the Minion.CheckDBSettingsDB table (not all columns are shown here):
ID DBName OpLevel OpName Exclude NoInfoMsgs
1 MinionDefault DB CHECKDB 0 0
2 MinionDefault DB CHECKTABLE 0 1
3 DB1 DB CHECKDB 1 0
4 DB1 DB CHECKTABLE 1 0
 
There are 30 databases on this server. As Minion CheckDB runs, the settings for individual databases will be selected as follows: 
  • CheckDB operations of database DB1 will use only the settings from the row with ID=3 or ID=4.  (Since Exclude = 1, that means DB1 will not get integrity checks). 
  • All other databases will use the settings from the row with ID=1 (for CheckDB) or ID=2 (for CheckTable).

Run Time Configuration

The main Minion CheckDB stored procedure – Minion.CheckDBMaster – can be run in one of two ways: with table configuration, or with parameters.
 
Run Minion.CheckDBMaster using table configuration: If you run Minion.CheckDBMaster without parameters, the procedure uses the Minion.CheckDBSettingsServer table to determine its runtime parameters (including the schedule of DBCC CheckDB and DBCC CheckTable jobs, and which databases to Include and Exclude). This is how MC operates by default, to allow for the most flexible integrity check scheduling with as few jobs as possible. 
 
For more information, see the sections “How To: Change Schedules”, “Minion.CheckDBSettingsServer”, and “Minion.CheckDBMaster”.
 
Run Minion.CheckDBMaster with parameters: The procedure takes a number of parameters that are specific to the current maintenance run.  For example: 
  • Use @DBType to specify ‘System’ or ‘User’ databases.
  • Use @OpName to specify CHECKDB, CHECKTABLE, or AUTO.
  • Use @StmtOnly to generate integrity check statements, instead of running them.  
  • Use @Include to specify a specific list of databases, or databases that match a LIKE expression.  Alternately, set @Include=’All’ or @Include=NULL to include all databases.
  • Use @Exclude to exclude a specific list of databases from CheckDB.
  • Use @ReadOnly:
  1. to include ReadOnly databases, 
  2. to exclude ReadOnly databases, or 
  3. to only include ReadOnly databases.
For more information, see the section “How To: Change Schedules” and “Minion.CheckDBMaster”.
 

Database Include and Exclude Precedence

Minion CheckDB allows you to specify lists of databases to include in a CheckDB/CheckTable routine, in a couple of different ways. 
 

Include and Exclude strings

One way to identify which databases should have their integrity checked, is with the Minion.CheckDBSettingsServer Include and Exclude fields; or, for manual executions, the @Include and @Exclude parameters in the Minion.CheckDBMaster stored procedure.  
 
Note: For the purposes of this discussion, we will refer to the @Include/@Exclude parameters, but be aware that the same principles apply to the Include/Exclude fields.
 
@Include and @Exclude may each have one of three kinds of values: 
  • ‘All’ or NULL (which also means ‘All’)
  • ‘Regex’
  • An explicit, comma-delimited list of database names and LIKE expressions (e.g., @Include=’DB1,DB2%’).
Note: For this initial discussion, we are ignoring the existence of the Exclude bit, while we introduce the Include and Exclude parameters. We’ll explain the Exclude bit concept in at the end of the section.
 
The following table outlines the interaction of Include and Exclude:
 
  @Exclude=’All’ or IS NULL @Exclude=[Specific list]
@Include=’All’ or IS NULL Run all CheckDBs Run all, minus databases in the explicit @Exclude list
@Include=[Specific list] Run only for databases specified in the @Include list. Run only specific includes, minus explicit exclude. (But, why would you do this?)
 
Note that regular expressions phrases are defined in a special settings table  (Minion.DBMaintRegexLookup).
 
Let us look at a couple of scenarios, using this table: 
  • @Include IS NULL, @Exclude IS NULL – Run all CheckDBs.
  • @Include = ‘All’, @Exclude = ‘DB%’ – Run all CheckDBs except those beginning with “DB”.

Exclude bit

In addition to the @Include and @Exclude parameters, Minion CheckDB also provides an “Exclude” bit in the primary settings table (Minion.CheckDBSettingsDB), which that allows you to exclude all operations for a specific database.
 
For example, if you wished to exclude all integrity check operations for database DB1, insert two rows (one for CheckDB and one for CheckTable) to the Minion.CheckDBSettingsDB table with Exclude = 1. From then on, DB1 will not be included in any scheduled operation. 
 
The following table outlines the interaction of the @Include parameter and the Exclude bit:
  Exclude=0 Exclude=1
@Include=’All’ or IS NULL Run all operations as specified (CheckDB or CheckTable) Run all operations, minus excluded databases’ CheckDB types
@Include=[Specific list] Run only specific includes Run only specific includes
IMPORTANT: The Exclude bit, like the @Exclude parameter, only applies for instances where @Include 
(or the column, “Include”) is NULL.  Whether @Include is Regex or is a specific list, an explicit 
@Include should be the final word. This is because we never want a scenario where a database simply 
cannot have CheckDB performed.

Table Include and Exclude Precedence

Minion CheckDB allows you to specify lists of tables to include in a DBCC CheckTable routine. 

Include Strings

One way to identify which tables should have their integrity checked, is with the Minion.CheckDBSettingsServer Schemas and Tables fields; or, for manual runs, the ExcMinion.CheckDBMaster @Schemas and @Tables parameters.  
 
Note: For the purposes of this discussion, we will refer to the @Schemas/@Tables parameters, but be aware that the same principles apply to the Schemas/Tables fields.
 
@Schemas and @Tables may each have one of two kinds of values: 
  • NULL (which means ‘All’)
  • An explicit, comma-delimited list of database names and LIKE expressions (e.g., @Schemas=’Sch1,Sch2%’).
Note: For this initial discussion, we are ignoring the existence of the Exclude bit in Minion.CheckDBSettingsTable, while we introduce the Schemas and Tables parameters. We’ll fold the Exclude bit concept back in at the end of the section.
 
The following table outlines the interaction of Schemas and Tables:
 
  @Tables IS NULL @Tables =[Specific list]
@Schemas IS NULL Run all CheckTables Run only specific tables
@Schemas=[Specific list] Run only specific schemas
Run all tables in schemas, plus specific tables
Note that @Schemas and @Tables do not limit each other. 
 
Let us look at a couple of scenarios, using this table: 
  • @Schemas IS NULL, @Tables IS NULL – Run all CheckTabless.
  • @Schemas = ‘MySchema’, @Tables = ‘DB%’ – Run all tables in “MySchema”, PLUS all tables beginning with DB. Note that the DB% tables will automatically receive the default schema defined in Minion.CheckDBSettingsDB, because there is no schema provided within the @Tables parameter.

Exclude Bit

Minion CheckDB provides an “Exclude” bit in the Minion.CheckDBSettingsTable table, which allows you to exclude CheckTables for a particular table. 
 
The following table outlines the interaction of the @Schemas / @Tables parameters, and the Exclude bit: 
  Exclude=0 Exclude=1
@Schemas IS NULL Run all CheckTables Run all CheckTables except those excluded
@Schemas=[Specific list] Run CheckTables only for tables in the listed schemas Run CheckTables for tables in the listed schemas, except those excluded
@Tables IS NULL Run all CheckDBs Run all CheckTables except those excluded
@Tables=[Specific list] Run Checktables only for the listed tables Run CheckTables only for the listed tables; ignores the Exclude bit in the settings table.
 
Let us look at a handful of scenarios, using this table:  
 
  • @Schemas=’Minion’, @Exclude = 1 for Minion.T1 – Run all CheckTables except Minion.T1 
  • @Tables IS NULL, Exclude bit=0 – Run all CheckTables. 
  • @Tables= ‘dbo.T1’, Exclude = 1 for DB2 (Minion.CheckDBSettingsDB) – Run CheckTable for dbo.T1. 
IMPORTANT: You will note that the Exclude bit is ignored in any case where Tables is not NULL.  An 
explicit @Tables should be the final word. The reason for this rule is that we never want a 
scenario where a table simply cannot have CheckTable performed.