Configuring a Separate Management History Database

I always recommend having separate databases, for several reasons.

With Active Roles, the Management History database isn't just a static reporting database. It is actually the execution database for the product. We write to the database as we perform tasks, and then run reports by querying the actual work which was performed. In very busy environments, or environments were the Change History retention period has been increased beyond the default 30 days, this can mean that the performance of the SQL instance hosting the Management History database can actually be a performance bottleneck for the product. Having the databases separated makes it easier to migrate the more resource-intensive Management History database to new hardware or a cluster if necessary.

In addition, since the Management History database is read from and written to much more often, it is more likely to suffer from malformation, since software is a mutable medium. This can sometimes mean that the Management History database needs to be archived, a new database created, and the data recovered using the Management History Transfer Wizard or the Active Roles Configuration Center. This is a resource which I created for help with those rare circumstances:

This process is much easier if the databases are separate.

Terrance, you've made some very good points and I'm now leaning towards the separate database.

I'll leave this thread open a little longer to allow for other feedback (hey, it could happen!).

Thanks for the quick and detailed reply.
-Steve
p.s. On a side note, what did you name your database(s)? I'm always aiming for best practices and real-world feedback.  :-)

For a naming scheme, I recommend NOT including the version number in the database name. This can cause confusion in the case of updates, where the database might be named "ARS67Config" but it has actually been upgraded to ActiveRoles Server 6.9, for example.

Personally, I don't like hyphens or any non-alphanumeric characters, for the odd time that you need to dive into a command prompt.

In the case of longer names, humpbackNotationIsYourFriend

Configuration and Management History (Change History) databases should be clearly labelled as such. ie. ARConfig and ARHistory

While I agree that going forward it makes sense to avoid version numbers in the database name (because the upgrade process is simpler as of version 7.x), historically customers often included the version info because it was often necessary to create a new database to support a version upgrade.  At the time, it made it easier to tell the "old" and "new" versions apart.

These comments are in the context of the name of the Configuration Database.  For, Management History too tend to stay away from version numbers.  And yes, it has been best practice for the 10 years I've worked with ARS to keep Management History separate.

Hmmm. I find I'm suddenly lost and somewhat confused (in my defense, I've not spent a lot of time yet on 7.0)...

I just initiated a clean install of v7.0 using the wizard.

After the software installs, the Configuration Center launches (at my request). At the "Database Options" I select "New...":

Upon the next wizard step:

The next wizard steps are creating the encryption keys and then the configuration begins.

Where/How exactly do I configure separate databases? Is it done outside of the Configuration Center?

Thanks again.

With Active Roles 7.0, it's done post-install.

In the Active Roles Configuration Center, on the Dashboard, "Manage Settings" | Change | Store Management History data in a separate database (advanced)

I see that option now, Terrance. To confirm, it can only be done after the initial configuration?

Confirmed. I'm not sure exactly why this functional change was implemented. I am looking into the possibility of changing this for a future release of the product.

I think I'm all set now. Thanks for all the information and quick feedback.