A quick glance behind, and ahead
So last time, we introduced the Databases module, and whether you should write your own custom objects.
This time we’ll look at the Database Properties module, and talk a bit about autogrow.
The Database Properties Module
For each database, the Database Properties module collects a significant amount of data, including:
- the database owner
- date of the last full, log, or diff backup
- which databases have auto-shrink enabled
- database collations
- case sensitivity
- database size on disk
- and, more
What can we do with this? Audit your database owners (exactly how many databases are owned by our ex-DBA, anyway?) Alert on missing backups. Track database size on disk (or in use, or index size, etc.) over time. Find ALL of the autoshrink enabled DBs across your enterprise. Determine which databases are on a nonstandard collation. Check recovery model on all Gold servers. See which databases are offline, or suspect. And so on, and on, and on.
Objects in the Database Properties Module
- Collector.DBProperties– Stores the collections of database property data.
- Collector.DBPropertiesCurrent – Provides the most recent collection of database property data.
- Collector.DBPropertiesPrevious – Provides the next-to-most recent collection of database property data.
To Autogrow or Not?
I just got this question in the user group and thought I’d write a blog instead of just answering a sub-set of users who could benefit from it. The question was:
I have customized the values of the Auto growth according to the size of the database and the rate at which it grows. I have noticed that Auto growth kicks in about every 3 months – 6 months on an average. Is that OK? I have read articles where the advice on it ranges from “Auto growth is OK” to “Auto growth should kick in only during emergency”.
This is one of those topics that comes up again and again, unlike AutoShrink which I hope is settled by now. I suspect it keeps coming up because there’s no real solid answer.
Ok, so whether or not to AutoGrow your files. I’m going to talk about both data and log files together unless there’s a difference. So unless I call one out over the other, I’m talking about them both.
Yes. And, no.
You should definitely use AutoGrow. And you should definitely NOT use AutoGrow. That’s my way of getting around saying “it depends”.
It depends on a few factors really.
- What you’re going to do with the files.
- How big your environment is.
- How many other files are on the drive.
- How much activity is on the files.
- Monitoring method
Maybe there’s more, but that’s all I can think of right this second, but you get the idea. Ok, so let’s go through them one at a time….
You can read the rest of this article here: http://www.midnightsql.com/tech-corner-to-autogrow-or-not/
And there we have Database Properties, and an op-ed on autogrow. 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 Objects, Tables, and Columns, and the top 20 features in Minion Enterprise