Building SQL ConstantCare®: Warning You About New Large Tables & Indexes

SQL ConstantCareWhen I’m doing a SQL Server health check, one of the things I like showing clients is a list of their top tables by size.

Inevitably, there are a bunch of tables that:

  • Tables whose names start with “temp” or “backup” or “just_in_case”
  • Tables with no clustered index that were clearly created with a select-into, and then forgotten about
  • Tables that haven’t been accessed in months or years

We have some chuckles, make a quick calculation, and realize that our database is 10%-20% larger than it needs to be. That means our backups are taking 10-20% longer, corruption checking, restore testing, backup space, disaster recovery test time, you name it – it’s all 10-20% higher.

So now if SQL ConstantCare® sees a new table with at least a million rows, we give you a heads-up in your daily email:

The first table it found on the first day

This is such a good example of what SQL ConstantCare® is all about: giving you practical insight, not just raw metrics.

Previous Post
The 4 Presentations I’m Proudest Of, and What Inspired Them
Next Post
Announcing a New Class: Fundamentals of Columnstore

3 Comments. Leave new

  • I would like to be able to use ConstantCare but our servers live in a secure environment.
    Is supporting that market segment on your radar?

  • I am using a similar approach for a number of years already and based on what I experienced I also include in my checks schema names like tmp,temp, delete, trash, etc. I also include table names that include dates, like dbo.customers_20100101.


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.