Why is my Change Auditor database so "YUGE" (huge)?

Here are some of the questions I get about the Change Auditor database when visiting customers:

  1. Should the size of the database be relative to the size of the environment?
  2. Should the size of the database be relative to the amount of activity in my environment?
  3. Should the size of the database be relative to the company’s retention policy?
  4. Should the size of the database be relative to the Change Auditor modules running?
  5. Should the size of the database be relative to the types of events enabled?

I'm sure I've been asked other questions similar to the questions above but you get the point. The answer to all of the questions above is, it depends. Not necessarily what you want to hear but it's the truth. Just for the record, the largest Change Auditor database I’ve come across was 6TB in size.

The bottom line is this, the size of the database will depend on many variables but a large database is not necessarily a bad thing, if your Change Auditor environment is able to handle it.

Let’s start with the Change Auditor for AD module. Larger environments obviously have more AD user accounts and therefore could potentially end up with a very large database but that’s not always the case. I’ve seen small and midsize businesses with “yuge” Change Auditor databases compared to Change Auditor databases in very large environments. So what gives? Here’s my point, it all depends, just kidding, not really. Some customers, for whatever reason, whether it’s for compliance reasons, company policy or just because, will need to keep event data for a longer period of time compared to others.

Now let’s factor in the amount of activity. Have you survived a migration? Migrations produce a lot of activity. Do you have an Identity Management System that’s constantly provisioning, re-provisioning and de-provisioning accounts? Do you have a PowerShell script that’s making changes to AD automatically? All this activity can be the reason for a larger database.

Let’s talk about multi-module Change Auditor environments. I’ve seen environments with many Change Auditor modules running on a single Change Auditor instance. Some Change Auditor modules audit a lot more event data than others. Change Auditor is able to handle it all assuming the Change Auditor environment is sized accordingly. Another variable to throw into the mix is the enabled events.

By default, Change Auditor is configured with certain events disabled on a per module basis. For example, in Change Auditor for AD DNS events are disabled by default for good reason. One good reason is that they can produce lots of event data that may not be required. Another reason is that most customers don’t care to audit DNS activity. It doesn’t make sense to store event data in your database that you don’t necessarily care to keep. Don’t get me wrong. It may come in handy someday but enable and disable these events based on the need. A good rule of thumb when it comes to default disabled events is leave them alone. Do not enable them unless you need that type of activity. Remember, they’re disabled for good reason.

With all this said, the thing to remember is that the size of the database is not an issue if your environment can handle it. In most cases where I’ve seen a database get out control, the number one reason is an incorrectly or non-existing purge and/or archiving job. We highly recommend a purge/archive job of some sort get configured in your Change Auditor environment. I have visited customers that didn’t know the database was out growing their environment.

Please check out my next blog which will cover tips and tricks on managing your Change Auditor database.

Related Content