A quick glance behind, and ahead
So, you’re a few days into your 30 day Minion Enterprise trial! (Remember, the actual countdown doesn’t start until you install the thing, but we’ll pretend you did that on day 1.)
This time we’ll look at the module that collects database file data, and the Script Schemas module (which scripts out all of your ‘Gold’ servers’ database objects automatically!)
The Database Files Module
The Database Files module collects database file information from managed servers. This gives you a record of all databases files – and their settings and sizes – for the entire enterprise, and allows you to track files as they come and go, grow, and shrink.
NOTE: We tend to say “repository” a lot, and by that we always mean the Minion Enterprise database, named Minion.
Let’s look at the associated objects, and then a quick example.
Objects in the Database Files Module
- DBFileProperties – Stores the collections of database file data.
- DBFilePropertiesCurrent – Provides the most recent collection of database file data.
- DBFilePropertiesPrevious – Provides the next-to-latest collection of database file data.
NOTE: In a future release of Minion Enterprise, the Database Files module will allow you to centrally set database file properties from a single place. For example, you will be able to standardize growth rates across all databases on all instances. What’s more, the Database Files process will monitor the settings you configure, to ensure that they are not changed.
The Script Schemas Module
This module generates the code for all of your database objects, on all of your “Gold” level servers, on a daily basis. That includes tables, indexes, triggers, stored procedures, views, and functions.
This is a massively useful feature, as a safeguard against schema level mistakes – such as an incorrectly modified view, or a mistakenly dropped index, or almost any schema object that is modified or dropped.
By default, schema are scripted out to C:\MinionByMidnightDBA\DBScriptBackups\. To change this location, see the section titled “Change the Default Location for Scripted Objects” in the Minion Enterprise Introduction document.
Examples: Script to files, tables, or both
As of Minion Enterprise version 2.2, you have the option of scripting your objects to files, to a table, or both! To change the Script Schemas behavior, edit the script call in the “CollectorDBScript-GOLD” job; the first parameter is always the service level; the second parameter is the Save to SQL bit; and the third parameter is the Save to File bit.
- To script object schemas to files, edit the script call in the job “CollectorDBScript-GOLD”: C:\MinionByMidnightDBA\Collector\DBScript.exe Gold 0 1
- To script object schemas to tables, edit the script call in the job “CollectorDBScript-GOLD”: C:\MinionByMidnightDBA\Collector\DBScript.exe Gold 1 0
- To script object schemas to files and tables, edit the script call in the job “CollectorDBScript-GOLD”: C:\MinionByMidnightDBA\Collector\DBScript.exe Gold 1 1
IMPORTANT: Be sure to use spaces between your parameters in the script call; do not use commas or other delimiters!
To disable object scripting, disable the “CollectorDBScript-GOLD” job.
Example: Do not script just one Gold level server
Minion Enterprise gives you the ability to say, “I know that Svr1 is a Gold level server, but I don’t want any scripts generated for it!” To do this, insert a row to the dbo.CollectionExceptionsServer table.
The dbo.CollectionExceptionsServer table is specifically for opting out of a particular collection, for a particular server. In our case, we would get the InstanceID for Svr1 from dbo.Servers, and insert a row to make the exception:
INSERT INTO dbo.CollectionExceptionsServer ( InstanceID, CollectionName )
VALUES ( 99 , 'DBScript' );
Now, InstanceID 99 (which is Svr1) will no longer be a part of the Script Schemas collection!
So there we are, two modules for a single newsletter! Write us with questions and comments any time at https://minionware.desk.com/, and get more information on our Minion Enterprise YouTube playlist.
Next time, we’ll talk about the Logins module and the Clone Users utility.