A baseline run of Minion CheckDB operates like this:

1. “Master” SP: The job MinionCheckDB-AUTO runs and calls the Minion.CheckDBMaster procedure, without parameters.
2. Schedule from SettingsServer: Minion.CheckDBMaster then consults the Minion.CheckDBSettingsServer table to determine what operation is currently scheduled. Let’s say this run of the job sees a “User CHECKDB” operation is in order.
3. Settings from SettingsDB and SettingsTable: The Master procedure then checks the table Minion.CheckDBSettingsDB to work out which databases (if any) should be excluded from the run, and what settings to apply. (Note that a CHECKTABLE operation consults both the Minion.CheckDBSettingsDB table and Minion.CheckDBSettingsTable).

That’s a default, no-special-configurations run of Minion CheckDB. Other options configurable in the product add additional steps, but these base steps remain the same.

Those other options include (but of course, may not be limited to):

• Dynamic thresholds, which let MC determine whether to run a CheckDB or a CheckTable (based on your configured criteria). Related table: Minion.CheckDBSettingsAutoThresholds.
• Remote CheckDB, which allows you to configure CheckDB operations on remote servers. Related table: Minion.CheckDBSettings.RemoteThresholds.
• CheckTable rotations (“rotational scheduling”), which allow you to define a rotation scenario for your operations. Related table: Minion.CheckDBSettingsRotation.
• CheckDB rotations (“rotational scheduling”), which allow you to define a rotation scenario for your operations. Related table: Minion.CheckDBSettingsRotation.
• Custom snapshots, which allow you to set the location (and, for CheckTable operations, the snapshot frequency) of custom snapshots. Related table: Minion.CheckDBSettingsSnapshot and Minion.CheckDBSnapshotPath.
• Inline Tokens, which allows you use defined patterns to create dynamic names. Related table: Minion.DBMaintInlineTokens.

CHECKTABLE operations

In step 3 above, we noted that a CHECKTABLE operation consults both the Minion.CheckDBSettingsDB table and Minion.CheckDBSettingsTable.

For CHECKTABLE operations, Minion CheckDB uses settings as appropriate from Minion.CheckDBSettingsDB where OpName=’CHECKTABLE’. Then, if there are table-level settings in Minion.CheckDBSettingsTable, those settings take precedence for those tables.

For example: In this example, we have the following settings in Minion.CheckDBSettingsDB:

And the following settings in Minion.CheckDBSettingsTable:

With these settings in place:

• A CHECKDB run will use settings from Minion.CheckDBSettingsDB, either row 3 (for database DB1) or row 1 (for any other database).
• A CHECKTABLE run for DB5 will use settings from Minion.CheckDBSettingsDB, row 2.
• A CHECKTABLE run for DB1 will use settings from Minion.CheckDBSettingsDB, row 3; EXCEPT for tables “MyTable” and “OtherTable”.
• A CHECKTABLE run for DB2 will use settings from Minion.CheckDBSettingsDB, row 3; EXCEPT for table “ASDF”.

Complex scenarios

It’s useful for you to know how different features of Minion CheckDB play together. In this section, we’ll look at the logical ordering and interplay between features. This section will be expanded in future updates to the documentation.

To demonstrate how it all fits together, let’s say you have a very complex scenario for DB1, with the following settings configured:

• Weekly AUTO schedule
• Auto Threshold set at 100 GB
• Remote Threshold set at 50 GB
• Custom snapshot
• CheckTable rotation
• CheckDB rotation

Database is under the auto threshold and remote threshold: Right now, DB1 is 40GB. So, the logical order of operations for this scenario is:

1. A run of the MC job determines that it’s time to run the AUTO schedule.
2. It checks the DB size, and finds it under the auto threshold of 100; so, it’s assigned a CheckDB operation.
3. DB1 is also under the remote threshold, so the operation will be local.
4. DB1 is on an edition of SQL Server that supports custom snapshots, so the custom snapshot settings apply.
5. MC figures out which databases to run next in the CheckDB rotation, and runs them. (Note that as this is a CheckDB operation, CheckTable rotation isn’t in play.)

Database is under the auto threshold, but over the remote threshold: DB1 has grown to 65 GB. The logical order of operations for this scenario is:

1. A run of the MC job determines that it’s time to run the AUTO schedule.
2. It checks the DB size, and finds it under the auto threshold of 100; so, it’s assigned a CheckDB operation.
3. DB1 is OVER the remote threshold, so the operation will be remote.
4. The remote server supports custom snapshots, AND remote CheckDB is set to “Disconnected” mode, AND custom snapshots are configured on the remote server. So the custom snapshot settings apply there. (For more on Disconnected and Connected modes, see the discussion below, “Minion.CheckDBSettingsDB”, “About: Remote CheckDB”, and “How to: Set up CheckDB on a Remote Server”.)
5. MC continues with the next database in the CheckDB rotation, and runs it using the same decision making process. (Note that as this is a CheckDB operation, CheckTable rotation isn’t in play.)

Database is over both the auto threshold and the remote threshold: DB1 has grown to 110 GB. The logical order of operations for this scenario is:

1. A run of the MC job determines that it’s time to run the AUTO schedule.
2. It checks the DB size, and finds it OVER the auto threshold of 100; so, it’s assigned a CheckTable operation. (CheckTable operations are not eligible for remote integrity checks.)
3. The local server supports custom snapshots, AND custom snapshots are configured on the server for CheckTable operations. So the custom snapshot settings apply here.
4. MC determines which tables to run next in the CheckTable rotation, and runs them.
5. When DB1 is completed, MC continues with the next database in the rotation (whether that’s the next database in the CheckTable rotation, or the next database which might have either CheckDB or CheckTable), and runs it using the same decision making process.

Again, this example isn’t a recommendation, but simply a demonstration of how different features of MC work around one other.

Discussion: Disconnected mode

In the second scenario above, remote CheckDB was set to Disconnected mode, and so the remote server’s custom snapshot settings came into play. Connected mode, however, just runs the DBCC CheckDB commands generated from the local server, on the remote server. Connected mode does not consult the custom snapshot settings at all; by default, it will use an internal snapshot. However, you could force a “custom snapshot” in connected mode, by:

1. restoring the database in question to the remote server (outside of the MC process; you’d have to use RemoteRestoreMode=NONE),
2. creating your own custom snapshot (outside of the MC process), and
3. pointing the PreferredDBName at that snapshot.