We made Minion Enterprise as intuitive as possible. But like any system, ME has its own structure, rules and philosophies. This section provides you that absolutely vital information.

Purpose

Minion Enterprise is a SQL Server management solution. We built it to automate and simplify some of the biggest and most difficult aspects of administering databases. Even more, we created ME to bring medium and large enterprises down to a manageable size. The centralized data collection, storage, etc. makes it possible to manage 5,000 servers as easily as 5, and to manage 5 as easily as one.

Architecture

Minion Enterprise is made up of SQL Server stored procedures, tables, jobs, executables, and configuration (“config”) files:

• Tables store configuration and log information.
• Stored procedures and executables perform various operations.
• Config files provide information to executables.
• Jobs execute those operations on a schedule.

Note: The Minion Enterprise installer creates a Minion database, and installs ME in that new database.

The Minion Enterprise repository groups database objects logically into schemas. Some of the most common schemas you’ll see are:

• Alert – The Alert schema includes alert-related stored procedures, and tables that control alert thresholds and deferments.
• Archive – The Archive schema includes tables and stored procedures related to Minion Enterprise’s self-cleanup. For example, the Archive.Config table determines how many days’ worth of data to keep for each of the tables in the Minion database. Be sure to look at the archival settings in this table to customize your data retention.
• Collector – Tables in the Collector schema hold collected data from managed instances. As you might suspect, Collector stored procedures play a part in the actual data collection.
• dbo – Data in the dbo schema tables tends to be more static than in other schemas – for example, the data in dbo.Servers will change as servers are added, removed, and upgraded, but the frequency of server changes is far less than data collections or alerts.
• History – Alert details are saved to tables in the History schema, before those alerts are emailed. For example, one row in the table History.Backups represents one detected missed backup. This allows you to (among other things) report on databases that have frequent trouble with backups.
• Setup – The Setup schema denotes stored procedures that allow you to set up various deferments, exceptions, and thresholds (e.g., Setup.DiskSpaceThreshold allows you to create or alter a disk space alert threshold). In the future this may expand to additional setup stored procedures.

Inheritance in ME

Global Default – Any time you see InstanceID = 0 in Minion Enterprise, it represents a global default. Example: dbo.BackupReport InstanceID = 0, DBName = MinionDefault – this row represents the default backup reporting configurations for the entire system. By default, any instance that does not have its own row in this table, will default to the configuration values in this default row.

Instance Default – Any time you see DBName = MinionDefault, it represents a global default for all databases on the given InstanceID. Example: dbo.BackupReport InstanceID = 7, DBName = MinionDefault – this row represents the default backup reporting configurations for all databases on that particular instance. An instance-specific row with DBName = MinionDefault overrides the global default “InstanceID = 0” row. Any database on this instance that does not have its own row in this table, will default to the configuration values in this default row.

IsActive – Many tables have an IsActive column. This allows you to “turn off” that particular row, temporarily or permanently, without deleting the row. This is useful in a myriad of situations. For example, you could deactivate a server in the dbo.Servers table (by setting isActive = 0) during a planned outage, so collections would not attempt to collect from that server, and alerts would not run.

Service Levels

Each managed server in Minion Enterprise must be assigned a Service Levels – a simple label for the level of the server’s importance. (You assign a service level to a server in the dbo.Servers table, ServiceLevel column.) By default, Minion Enterprise handles three specific service levels:

• Gold – Highest importance. ME automatically scripts out the objects of gold level servers, and runs collection and alert jobs the most frequently, for Gold level servers.
• Silver – Second highest importance. ME runs collection and alert jobs less frequently for Silver servers. And as of this release, Silver server objects are not scripted; and are not included in the table column collection.
• Bronze – Lowest importance. ME runs collection and alert jobs less frequently for Bronze servers; and, Bronze servers are excluded from some collections by default (including the database list, OS details, service properties, and table columns).

Data Archiving

This section describes the Minion Enterprise data archive process. The tables in Minion hold collection data from all the servers in your network. This data ages out and becomes too large to handle reasonably, so it’s necessary for Minion to clean up after itself. Therefore, we’ve implemented an archival process for the collector data, and any other data that needs archiving. The elements of the process are described below.

Tables:

• Archive.Config – This table holds the metadata for the tables that will be archived.
  • SchemaName – The schema of the table.
  • TableName – The name of the table
  • ArchiveDays – How many days you want to keep in the table.
  • RowsInBatch – How many rows you want to delete in a single batch.
• Archive.ConfigLog – Holds log info when the tables get archived. This holds how many records were deleted from each table, and how long it took. This is just for troubleshooting purposes should you experience any performance issues during the archive process.

Stored Procedures:

• Archive.Data – Cycles through the tables in the Archive.Config table and deletes rows based on the data therein.

Jobs:

• ArchiveData – Runs the Archive.Data stored procedure.

Custom Objects

MinionWare encourages you to create stored procedures and views as you find you need them. ME is meant to be customized. Even with the huge amount of time and experience we have dedicated to creating this management software, there is no way to anticipate every alert or query your organization will need. Feel free to create your own alerts, reports, views, and so on. You can even create your own collections to merge with the data we collect for you to fully customize your environment.

We further recommend you create your own schemas to organize these custom objects. For example, if your company name is ABC, you might create the schemas ABCAlert and ABCReport.

As long as you do not modify existing Minion Enterprise objects, there should be no ill effects. And, Minion Enterprise upgrades will not remove or modify your custom objects and schemas.